Re: Any way to allow clobbering empty files when noclobber is set?

[Roman Perepelitsa <roman.perepelitsa@xxxxxxxxx>]

On Sat, Jun 6, 2020 at 6:56 AM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>
> > On Thu, Jun 4, 2020 at 9:39 PM Roman Perepelitsa <roman.perepelitsa@xxxxxxxxx> 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 <schaefer@xxxxxxxxxxxxxxxx> 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.