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 13616 invoked from network); 6 Jun 2020 06:26:01 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2020 06:26:01 -0000 Received: (qmail 3725 invoked by alias); 6 Jun 2020 06:25:56 -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: 45997 Received: (qmail 25782 invoked by uid 1010); 6 Jun 2020 06:25:56 -0000 X-Qmail-Scanner-Diagnostics: from mail-io1-f66.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.66):SA:0(-2.0/5.0):. Processed in 1.138278 secs); 06 Jun 2020 06:25:56 -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.66 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=hWAYSgr+O+xuw6j4Fjxf4PLaBYLwUrg19jbJkcg/3l8=; b=f+IllxzCTfa8hUGajdfyJU6iF/j0y6gRVoJoEywRQR7Xb7EA5d/wMI1P6GyV6x3PPD lFosx6KhX9Avsbdr3B/pawNoOmNcT77W1qWnePIKaiEBJZGCFrMq1uIDG1dyXA18VN92 XsZvAoVHk1SWNVuyk0YnOjfO9b1Ko5b6vv0AiVgkG1Llo1Az5xd0SEpk0AwBOSpJoRdy 7AS7NSJh+RfbcCyO3NwzUVFEbfP1BFCvFQ8EgKoRmJBIfQkOiA2ea+NjKvgZ7bRHoTJZ sgnmalgFHkyt3WbXiRKelYd8INWHx8PYV0hkXiTGVBSP9ruwev5yo4OFvKgmOydnqmFn xpgA== X-Gm-Message-State: AOAM532jlJzjY+w1mwe7RW1/Y2e0Cab27JTZ+mR5X1hNG0zSSdiMC1V8 mDxUbCClaNOaAYX3PbGx0Smf3AlL7F2c/hI7Zw1H0w== X-Google-Smtp-Source: ABdhPJzNdVWRKXCxM51ujX/uYL26b8hSX3WaGHd+haSOZrc6Yq+oLPp84+iH/uHdgcrcITarnJsT5kBsOHkPvkOy/Pk= X-Received: by 2002:a5d:87c4:: with SMTP id q4mr11907778ios.169.1591424721870; Fri, 05 Jun 2020 23:25:21 -0700 (PDT) MIME-Version: 1.0 References: <89aed74d-db7b-47ad-b218-8158838049e9@www.fastmail.com> <94e73ebcf39d4d3f9c7ae257b1d75d16@CAMSVWEXC01.scsc.local> <20200605020748.635b9bb3@tarpaulin.shahaf.local2> <20200606045531.4b506c8e@tarpaulin.shahaf.local2> In-Reply-To: <20200606045531.4b506c8e@tarpaulin.shahaf.local2> From: Roman Perepelitsa Date: Sat, 6 Jun 2020 08:25:10 +0200 Message-ID: Subject: Re: Any way to allow clobbering empty files when noclobber is set? To: Daniel Shahaf Cc: Bart Schaefer , "zsh-workers@zsh.org" , Martin Tournoij Content-Type: text/plain; charset="UTF-8" On Sat, Jun 6, 2020 at 6:56 AM Daniel Shahaf wrote: > > > On Thu, Jun 4, 2020 at 9:39 PM Roman Perepelitsa wrote: > > > > Is there a way to provide these guarantees with clobber_empty? > > I don't understand the question, really. If someone writes "hello" and "bye" to the same file with no_clobber and clobber_empty, and no error occurs (apart from no_clobber kicking in and refusing to clobber), what can be the content of the file in a conformant zsh implementation? I think providing an answer to this question is important. Without it it's unclear what no_clobber with clobber_empty means. If writes happen sequentially, the file will contain either "hello" or "bye". It cannot contain anything else. If the same guarantee could be provided for concurrent writes, that would be ideal. I don't think it's possible on all systems that zsh targets but maybe I'm wrong. On some systems there might be no better answer than "the content of the file is unspecified". This can be counterintuitive. Seeing "byelo" or "hellobye" in the file one could reasonably assume that "hello" was clobbered by "bye" despite options that on the surface disallow clobbering non-empty files. On Sat, Jun 6, 2020 at 3:42 AM Bart Schaefer wrote: > 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. Nod. It would also guarantee #1. Roman.