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=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20493 invoked from network); 6 Jun 2020 12:49:13 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2020 12:49:13 -0000 Received: (qmail 29940 invoked by alias); 6 Jun 2020 12:49:03 -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: 46007 Received: (qmail 7302 invoked by uid 1010); 6 Jun 2020 12:49:03 -0000 X-Qmail-Scanner-Diagnostics: from mail-il1-f170.google.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(209.85.166.170):SA:0(-2.0/5.0):. Processed in 2.615077 secs); 06 Jun 2020 12:49:03 -0000 X-Envelope-From: roman.perepelitsa@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.170 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lszS29/HHivV0yuXDK6yn0DxtGjufldvJRg4iQIgw6s=; b=XnHaKEGOXqA6YhuRtoNxtK5srfvdDIYVnTw6vEvoDNxA4Lx+m5KCQVrVRe3OE7AoBP oFiPGCIYNT7ilzNd/NKr7B1oLuVJOyJ6neAMj+NRdSQ0mAyBDZF9RtCOYWld4qjL7hDt IZxn877W34A5SM3SCNS4KL1a8mRSaNpy0cia+3M6RiKyVHSg6QJ2riKFGYoU/lrfRX1W AsFNwE+Hopc50zz3k0dCVklMFXdchMjskfA3IfstKBvPGWmWDVQVEIc4P7pOBCEB9IBi KWba2P2cStwtz1uFeEigCetAxXbjVFUr5QgYZoBGf+anqy3wLiPs9eA/8TJBrfbx87mZ mTTQ== X-Gm-Message-State: AOAM533tJBZ1YB6G2qrCaNsOpDHv3218K4IrZrcqE/aVlXOGpI5n6sZp 3vXHqyTv/piCV7Sf+EiNyvZ8nY3Aj8c0O8WxagPxrlqg X-Google-Smtp-Source: ABdhPJznTK4imfyYWcV2AYKdwtajYre+U5Fdcr4tTYviwU2iPGMHXiDIXbiQk/5eMvH1FheuWIfJBH5hWPgooV8Ro0k= X-Received: by 2002:a05:6e02:584:: with SMTP id c4mr12786669ils.304.1591447706882; Sat, 06 Jun 2020 05:48:26 -0700 (PDT) MIME-Version: 1.0 References: <89aed74d-db7b-47ad-b218-8158838049e9@www.fastmail.com> <94e73ebcf39d4d3f9c7ae257b1d75d16@CAMSVWEXC01.scsc.local> <20200605020748.635b9bb3@tarpaulin.shahaf.local2> <1941572212.466119.1591360860372@mail2.virginmedia.com> <13acd486e6457c1f708304026c3e1b59521ad328.camel@ntlworld.com> In-Reply-To: <13acd486e6457c1f708304026c3e1b59521ad328.camel@ntlworld.com> From: Roman Perepelitsa Date: Sat, 6 Jun 2020 14:48:15 +0200 Message-ID: Subject: Re: Any way to allow clobbering empty files when noclobber is set? To: Peter Stephenson Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Sat, Jun 6, 2020 at 1:58 PM Peter Stephenson wrote: > > My understanding of the semantics (feel free to put me right, of > course), is that as any use of fstat() would be on a non-clobbering > open, you can't stop anyone else writing to the file (the same file, > rahter than a newly created one with the same one) at any point. Worse, > you're now claiming you've clobbered that open file, and you haven't. > So now you have Roman's nightmare scneario where you're claiming you've > opened a new file because the old one was empty, but actually two > processes have written to it. Not only have you not fixed a race, > you've created a new one. Yep. Having unspecified file content that is the result of interleaved writes seems pretty bad. > Assuming both processes are actually doing clobbering opens (O_CREAT | > O_EXCL), you can't get into that position. You can't guarantee that > someone else hasn't written to a file of that name, but you can > guarantee that two so-called clobbering opens actually are that. Let me put this in code: { print hello >file } & hello_pid=$! { print bye >file } & bye_pid=$! { print -n >file } & empty_pid=$! wait $hello_pid print "print hello => $?" wait $bye_pid print "print bye => $?" wait $empty_pid print "print -n => $?" print "file => $( 0 print bye => 0 This output implies that one command has overwritten the output of another and the user has received no indication to this effect. In addition, no implementation restricted to POSIX C API can guarantee that the last line of the output is one of these: file => hello file => bye Different implementations will violate this expectation in different ways. Some will allow abominations such as "byelo" or "hellobye". If I understand Peter's point correctly, his preferred implementation will guarantee that the file exists and contains either "hello", "bye" or "" (empty). The possibility of an empty file is unfortunate. In addition, this implementation requires unlinking files (when the file exists prior to a write and is empty), which may be prohibited while writes to the file are allowed. Unlinking also introduces the possibility of losing files, together with their permissions and ownership, which could've been informative. This happens when one of the writes gets interrupted or fails to create a file after unlinking. All these issues can be fixed through the use of advisory locks on systems that support them. Roman.