Re: touch: why try utimesat when open already failed with EACCESS?

[Bernhard Voelker]

On 12/09/2011 04:06 PM, Eric Blake wrote:
> On 12/09/2011 05:34 AM, Bernhard Voelker wrote:
>> Why does touch try to set the time when fd_open already failed
>> with with EACCESS?
>>
>> Run as a normal user:
>>
>> strace touch /x
>> ...
>> open("/x", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = -1 EACCES 
>> (Permission denied)
>> utimensat(AT_FDCWD, "/x", NULL, 0)      = -1 ENOENT (No such file or 
>> directory)
>>
>> Is there a chance on any system that setting the time succeeds
>> after the EACCESS?
> 
> Probably not, but...
> 
>> Or is this just to keep the function flow
>> simpler by having the diagnostic centrally afterwards?
> 
> This is certainly true.  After all,
> 
> $ touch a
> $ chmod a-w a
> $ touch a
> 
> succeeds at updating the timestamp on 'a', even though the
> open(O_WRONLY) failed, because there are cases where utimensat can
> succeed where open failed.  The function prefers to use futimens rather
> than utimensat, which is why we attempt open in the first place.
> 
> If you think it's worth enumerating which errno values are worth the
> utimensat attempt, vs. those that guarantee failure, then feel free to
> submit a patch that skips the intermediate processing between the
> setting and reading of open_errno in touch.c:touch().

Thanks.
I think the error message is pretty good for both cases:
  touch: cannot touch `/x': Permission denied

Therefore I agree with the comment in touch.c:touch():
  I think it's not worth trying to distinguish them.

Have a nice day,
Berny