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 17589 invoked from network); 6 Jun 2020 07:05:17 -0000
Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2)
  by inbox.vuxu.org with ESMTPUTF8; 6 Jun 2020 07:05:17 -0000
Received: (qmail 17276 invoked by alias); 6 Jun 2020 07:05:07 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
List-Unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
X-Seq: 45999
Received: (qmail 3329 invoked by uid 1010); 6 Jun 2020 07:05:07 -0000
X-Qmail-Scanner-Diagnostics: from mail-oi1-f174.google.com by f.primenet.com.au (envelope-from <schaefer@brasslantern.com>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.102.3/25828. spamassassin: 3.4.4.  
 Clear:RC:0(209.85.167.174):SA:0(-1.9/5.0):. 
 Processed in 1.981997 secs); 06 Jun 2020 07:05:07 -0000
X-Envelope-From: schaefer@brasslantern.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.167.174 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=zMjhaXWm3+1e2p21fDpiIX3qgwvlW006URYRymhNLCQ=;
        b=ejadfeTOIqU33jbIgEuCVIxoj0KwgG8zabUiCj0IFv3lgI+Lybcvg8uk9wDVZB1vtQ
         rpaQrfFa9PoDxkMi5YhuZ4yLuqb7fI2Rf7EPUfsMSuuPQQ3usGDbLDPQXPhoXQN5FPuW
         tfShY8UPztpLDYxtljyoeaBBRG0onjmdlqYrcNARDmjSM4niEF9s0p1JS/4siGGGvomR
         se2lgLsCuvb6FblD2tMrZWCLhA+8GGe9bzu+aTljSPmC9hPGeuaRDOr66V0ocoWbhYih
         VoL6pYDMbrtQhsKJZsg4l7Sd83QhblMn3K1AJge7HUCmxPLpMYYLvImJoFQmcIzQF/Nf
         /Ceg==
X-Gm-Message-State: AOAM531smVq98D0mYz1vbxuE/iDC/20xxlhW87EyhU1802becClRU3I5
	hPDTsFoJTjye1ftZ3UGFLH4A/ZyUo+dNlCEIdY7R8WEdiyA=
X-Google-Smtp-Source: ABdhPJzVBU5daMxOB8gzTHgKyi5WbsHj35f12JiyMO6lvEUE5Yg0+B3p07qGMz03V+n7s/0Jrh7F5v5gn/Di5befEvg=
X-Received: by 2002:aca:57d7:: with SMTP id l206mr4044342oib.84.1591427072207;
 Sat, 06 Jun 2020 00:04:32 -0700 (PDT)
MIME-Version: 1.0
References: <CGME20200603020919eucas1p13e26ebcbb335784d14bfb97b137f385a@eucas1p1.samsung.com>
 <89aed74d-db7b-47ad-b218-8158838049e9@www.fastmail.com> <94e73ebcf39d4d3f9c7ae257b1d75d16@CAMSVWEXC01.scsc.local>
 <20200604014850.52d241bd@tarpaulin.shahaf.local2> <CAH+w=7a0s5BhBWRHReD1oGkKLkxVt8rs+kZQu9Dg0-efaKuYtg@mail.gmail.com>
 <a36ec51a-6f76-454f-9a1a-327557de3223@www.fastmail.com> <CAH+w=7bwKvJ7F4JCu7CUuTVxivy8OScCFwN97DKnK9M9QXqVSA@mail.gmail.com>
 <20200605031013.16a36d31@tarpaulin.shahaf.local2> <CAH+w=7b9WP77s5cTBO+gszHS=WJDLXzjjQqvU-E1Jdwz_jRwQw@mail.gmail.com>
 <20200606044808.59509bdf@tarpaulin.shahaf.local2>
In-Reply-To: <20200606044808.59509bdf@tarpaulin.shahaf.local2>
From: Bart Schaefer <schaefer@brasslantern.com>
Date: Sat, 6 Jun 2020 00:04:21 -0700
Message-ID: <CAH+w=7YasiscfuHppDxcYYtcY025ORn0a_Tm9BGifukBDdDNQg@mail.gmail.com>
Subject: Re: Any way to allow clobbering empty files when noclobber is set?
To: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Cc: Martin Tournoij <martin@arp242.net>
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 5, 2020 at 9:48 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Bart Schaefer wrote on Fri, 05 Jun 2020 18:07 -0700:
> >  - how to identify the file we opened, in case something else renamed
> > or removed it, and created another one of the same name in the
> > meantime
> >
> > That seems at least impractical, especially the last one.
>
> It'll just be a couple of local variables on the C stack, won't it?

That would only work for jobs that run synchronously.  It has to be in
the fdtable or the job table or something for background jobs and
pipelines.

> > Open could fail because of file permissions.  Unlink depends only on
> > directory permissions.
>
> Well, yes, but usually, if you don't have permission to read a file,
> in practice you won't have permission to delete it either.

I think you mean "write" there, but actually you might be able to
write to an empty file that you can't delete, but not create a file
that you can't delete.