On Monday 19 September 2005 22:36, Paul Eggert wrote: > Thanks for bringing this to our attention. It would be very nice to > add this sort of thing to GNU tar.
My pleasure. > > rather than extend the existing --preserve-atime option. The option > > exists (as a no-op), even if configure did not find required system > > headers. > > Does that sound wise? If 'tar' can't implement --no-atime correctly, > wouldn't it be better to reject the option? The problem is that there is no relaible way to detect if we can actually do --no-atime correctly or not. Sometimes we know for sure, but I feel that if the option is sometimes rejected, the implication is that it will work if not rejected, which is not the case. > Could you elaborate on this a bit? It will confuse users to have both > options. Can't we just implement --preserve-atime with O_NOATIME if > O_NOATIME works, and document it that way? Except that the side-effects of --atime-preserve may make it unsuitable as a failover; In general, I would rather have no atime preservation than the kind that changes the ctime. For example, --no-atime is OK with incrementals, but --atime-preserve is not. Perhaps it would be better to have --atime-preserve=system, for O_NOATIME only, --atime-preserve=legacy, for utimes(), or --atime-preserve=best (or just --atime-preserve) to guess what's best. > Can't tar fstat the file and see whether its last access time is > changed, after reading the file? If it hasn't changed, O_NOATIME is > probably working. Nope. Consider the case where some other process is also reading the file. It introduces a race condition. Also, on some filesystems, the atime might not change right away, introducing a second race condition. > Presumably O_NOATIME is something that works (or doesn't) on a > per-filesystem basis. (Am I right?) Is there some way this can be > queried, e.g., with stat or fpathconf? If not, perhaps there should > be. And at any rate, the O_NOATIME-works info could be cached by tar > (regardless of whether it can be queried directly). Yes, in Linux this is a per-filesystem feature. Note, however, that the interface comes from the GNU folks, not the linux folks, so you may see O_NOATIME on other operating systems that use glibc. There's no guarantee from glibc that O_NOATIME will work/not work only on a particular filesystem. No, there is no definitive way to check if a filesystem supports this. The best I can think of is to create a temporary file, delete it, fstat it, read it, and fstat it again. That assumes write permission in some directory of the filesystem, of course. Probably the best guess we can do would be to statfs(), and decide if this filesystem is one of the ones we know is supported. But then we would have to keep track of kernel improvements in this area. > > +AC_CHECK_DECL(O_NOATIME, > > Is the Autoconf stuff necessary? Why not just use "#ifdef O_NOATIME"? Mostly because it's used both in create.c and compare.c; it seemed to me better to have the check all in one place. Doubly so if the flag is to be disabled if the macro's not there. > Also, would you be willing to assign the copyright to your changes to > the Free Software Foundation, so that we could install it in tar? Yes. I hereby transfer all title and ownership of this patch to the Free Software Foundation, under the sole condition that it be licensed at least under the terms of version 2 the GNU General Public License, as published by the Free Software Foundation. If need be, I can get a similar transfer from my employer. Cheers, --Ian _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
