Ian Turner <[EMAIL PROTECTED]> writes: > Because of these limitations, and because of the very different > side-effects, I have added a new option --no-atime,
Thanks for bringing this to our attention. It would be very nice to add this sort of thing to GNU tar. > 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? > --no-atime does not at present interact with --preserve-atime > (though you can use them both); it might be useful to do the "best > thing" if the user specifies both, 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? > but at present it is impossible to know if O_NOATIME is actually > working, at least under certain circumstances. 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. 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). > +AC_CHECK_DECL(O_NOATIME, Is the Autoconf stuff necessary? Why not just use "#ifdef O_NOATIME"? 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? _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
