> > 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 _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
