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

[Eric Blake]

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().

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature