[Bug-tar] Re: [patch] O_NOATIME support

[Ian Turner]

> > a sysctl could be added to ask this question to a future kernel, so
> > that we would only need to use uname() for, say, kernels 2.6.8 -
> > 2.6.14.
>
> That's a better idea, but wouldn't it be better yet to make it an
> fpathconf query?  It's a per-file-system issue, after all.  (While
> we're on the subject, I'd also like to see an fpathconf query to give
> me the resolution of the file system's time stamps in nanoseconds.)

Sure. That can be done. Why don't we put a patch now for 
--preserve-atime=system, and we can add --preserve-atime=heuristic when 
kernel support exists, since that might take some time?

> Or -- better yet -- why not have open(...O_NOATIME) fail with errno ==
> EINVAL when invoked on a file system that does not support O_NOATIME?
> That would be similar to how open(...O_SYNC) is supposed to behave, so
> it makes a lot of sense to do it that way.

I'd agree that that makes sense, except that O_NOATIME is a GNU extension, and 
the GNU interface does not specify the possibility of EINVAL. And we have 
kernels out there already that silently ignore O_NOATIME.

Cheers,

--Ian