From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4882 invoked from network); 6 Jun 2020 04:56:20 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2020 04:56:20 -0000 Received: (qmail 27826 invoked by alias); 6 Jun 2020 04:56:10 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45995 Received: (qmail 345 invoked by uid 1010); 6 Jun 2020 04:56:10 -0000 X-Qmail-Scanner-Diagnostics: from wout4-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25828. spamassassin: 3.4.4. Clear:RC:0(64.147.123.20):SA:0(-2.6/5.0):. Processed in 1.437527 secs); 06 Jun 2020 04:56:10 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeggedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfgjfhfogggtgfesthejtddtredtvdenucfhrhhomhepffgrnhhi vghlucfuhhgrhhgrfhcuoegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvgeqne cuggftrfgrthhtvghrnhepfeduteegveehvdfhteevtedvudeludeijeeuudeujeejtdet uedtjefhtdfgieetnecukfhppeejledrudejiedrfeelrdeileenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhh rghhrghfrdhnrghmvg X-ME-Proxy: Date: Sat, 6 Jun 2020 04:55:31 +0000 From: Daniel Shahaf To: Bart Schaefer Cc: "zsh-workers@zsh.org" , Martin Tournoij Subject: Re: Any way to allow clobbering empty files when noclobber is set? Message-ID: <20200606045531.4b506c8e@tarpaulin.shahaf.local2> In-Reply-To: References: <89aed74d-db7b-47ad-b218-8158838049e9@www.fastmail.com> <94e73ebcf39d4d3f9c7ae257b1d75d16@CAMSVWEXC01.scsc.local> <20200605020748.635b9bb3@tarpaulin.shahaf.local2> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bart Schaefer wrote on Fri, 05 Jun 2020 18:41 -0700: > On Thu, Jun 4, 2020 at 9:39 PM Roman Perepelitsa > wrote: > > > > write() print -rn -- $1 > > rm -f foo > > write hello >foo & > > write bye >foo & > > wait > > > > With regular no_clobber it has the following guarantees: > > > > 1. `write` is executed exactly once > > 2. once `wait` completes, `foo` contains either "hello" or "bye" > > I don't think that's the intended typical usage of noclobber. It's > not set by default, and it can't have any effect outside the local > shell. It's meant to keep you from making silly mistakes when > interacting with the interpreter, not as a concurrent programming > tool. NO_CLOBBER causes open() to be called with the O_EXCL bit, which does affect other processes as well. > Nevertheless: > > > Is there a way to provide these guarantees with clobber_empty? > I don't understand the question, really. If you can get these semantics with NO_CLOBBER, why does it matter whether or not CLOBBER_EMPTY can provide them or not? You can always leave it off (or locally unset it). Or use mkdir without the -p flag as a poor man's mutex. > With clobber, you have #2, but not #1, Doesn't O_EXCL achieve #1? > so I think we should focus on > whether clobber_empty can guarantee #2. If you want #1, there are > other ways (but I suspect it arises from the implementation of #2 even > so). > > I think the answer is that #2 can be guaranteed if and only if > fcntl()-based locking can be applied, or some equivalent kernel > mechanism such that no more than closing of the (last dup of the) > descriptor is necessary to release the lock. The steps would have to > be: > > 1. Open the file for write without truncate. > 2. Attempt lock, non-blocking, and immediately close/fail if not locked. > 3. Check for zero size, and immediately unlock/close/fail when nonzero. > 4. Return the locked descriptor. Cheers, Daniel