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 15473 invoked from network); 4 Jun 2020 12:21:29 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 4 Jun 2020 12:21:29 -0000 Received: (qmail 12038 invoked by alias); 4 Jun 2020 12:21:22 -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: 45969 Received: (qmail 13918 invoked by uid 1010); 4 Jun 2020 12:21:22 -0000 X-Qmail-Scanner-Diagnostics: from mail-io1-f54.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.54):SA:0(-2.0/5.0):. Processed in 0.743259 secs); 04 Jun 2020 12:21:22 -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.54 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=kbXaCIoM0AL4IHmMoF4YukkHFtY+C9C/Ocly0JDW2Rg=; b=bN6mM0NI2OJ4kBsG65KGp8lzAxHvTylkfr6J0bOwBgPo2he7a/5sxx4d+11KFrbHiG +fd6wGQqAo5wiHHq61KjyRqnmFmNxDa/zxZDi+4ABEF9aIsNYp1Gbzr13qVsyg40tfaD EwMEXnuBUhy0PNg2oMO9merGei4mbG3SBbNLUVbgsWymybTjeQbhmmJUsXmMVS2RVRLu qrlfEe+AcdED0xhRxnyERL+Z4yZjd/u6G4J1BkSzavCdq1Tp0flG/APr78wFT9Gl+J4X UOQjDNdFV4XsX+GPfqoMTxpfbs3VLHmtaryjwsp7uw3RJ5wDCKJnnUdn5GQQkeUnZNYz SqeQ== X-Gm-Message-State: AOAM531AyPaY6/TvSsh+j9gc0ftLaOfigCwmahbUdIfR1R2PYRNImU7H +jgsr8bZVA52enH/dqOVaiPlvokoi1VCWzkRqNw= X-Google-Smtp-Source: ABdhPJxmcTT68e8VO1b/392gKTkGYC6uHT6cYIte7kGZ04FENm3gSR4Taj/PaQwfHZoRFIXPKPM/m79HEoSCSebRKlM= X-Received: by 2002:a5d:81d7:: with SMTP id t23mr3854025iol.142.1591273248654; Thu, 04 Jun 2020 05:20:48 -0700 (PDT) MIME-Version: 1.0 References: <89aed74d-db7b-47ad-b218-8158838049e9@www.fastmail.com> <94e73ebcf39d4d3f9c7ae257b1d75d16@CAMSVWEXC01.scsc.local> <483300941.422089.1591263753638@mail2.virginmedia.com> In-Reply-To: <483300941.422089.1591263753638@mail2.virginmedia.com> From: Roman Perepelitsa Date: Thu, 4 Jun 2020 14:20:40 +0200 Message-ID: Subject: Re: Any way to allow clobbering empty files when noclobber is set? To: Peter Stephenson Cc: Zsh hackers list , Martin Tournoij Content-Type: text/plain; charset="UTF-8" On Thu, Jun 4, 2020 at 11:43 AM Peter Stephenson wrote: > At the least we'd need to open the existing file without > truncating (then either close it or leave it open for writing > if it was already empty). If you mean opening the file with O_APPEND, this could result in unexpected file content. Suppose N processes concurrently write "hello world" to /foo/bar with the new no_clobber_non_empty option. The final content of the file can be up to N * strlen("hello world") bytes long with mangled content. If writing were done with the regular no_clobber, there would be a guarantee that at any point readers of the file would either not see the file, or would see content that is a prefix of "hello world". I should also note that the existing no_clobber option can be used to implement file locks. emulate zsh -o no_clobber if ! print -n >/var/lock; then print -ru2 'cannot acquire lock' exit 1 fi do_exclusive_stuff unlink /var/lock Regardless of what gets decided w.r.t. no-clobber extensions, I hope this would keep working. Roman.