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

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Fri, 05 Jun 2020 18:07 -0700:
> (Martin, if you are no longer interested in these side discussions, we
> can stop Cc'ing you.)
> 
> On Thu, Jun 4, 2020 at 8:10 PM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > Bart Schaefer wrote on Wed, 03 Jun 2020 22:00 -0700:  
> > > Fair enough, although (silly example) "false > empty" would remove the
> > > file?  
> >
> > Depends on whether ./empty was created by the redirection or not.  
> 
> Hm.  That means that the following must all be preserved (in the
> parent shell, so fails for "exec command > file") all the way from the
> redirection event to the completion of the command:
>  - whether the descriptor resulted from redirection
>  - what kind of redirection operator was used
>  - whether the appropriate clobber-related option was set at the time
>  - 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?

For the last bullet, I suppose we could save the inode number (and
device number), but as I wrote in workers/45977, I don't see a way to
avoid a race condition.

> And what happens in the case of rename?

If the file has been renamed before we get around to unlink it, then we
won't unlink it.  We won't have a choice.

> > Besides, if the redirection failed — I assume you mean the open(2)
> > failed — then isn't the unlink likely to fail as well?  
> 
> 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.

> > Okay.  Is there a case where leaving around an empty file is worse than
> > removing it?  
> 
> IMO your examples are all too specific to warrant a generalized change
> in behavior of redirections.

Fair enough.  As I said, just brainstorming.

Cheers,

Daniel