At 13:13 9/11/2014 -0700, Paul Eggert wrote: >> If the patch is of interest I'm willing >> to improve it by having the feature >> present conditionally on the appearance of >> HAVE_WORKING_O_NOATIME >> in 'config.h'. > >Thanks, but there's no need for that; just >have 'grep' complain if the option is used >and O_NOATIME == 0.
Sure, that is a better approach. >I'm of two minds about this suggestion. On >the one hand we don't want to add an option >like this to every utility that reads >files. On the other hand grep is used soooo >often that it may be justifiable. What do >other people think? I don't feel a compulsion to utilize O_NOATIME all over the place--it really seems like a specific use case to me which is where one cares about and refers to ATIME with something like 'ls -otru' and one frequently runs find * -type f -print | xargs egrep somestring while trying to find code fragments. For years it has annoyed me that the 'find/grep' nukes ATIME values for the entire tree one is working on. >If we add it, it should not have a >single-letter option, though, and the long >option should be called "--atime-preserve" >for compatibility with tar, I specifically chose to not use the 'tar' option because it has two variants: a) =replace and b) =system in order to avoid semantic confusion. The 'tar' default is --atime-preserve=restore which nukes CTIME values and is evil in my opinion. But I don't feel strongly about the naming choice here. However I do feel strongly that a short option should be defined. If one embraces the feature it would be typed often. >and the patch >should also use FTS_NOATIME to avoid updating >atime on directories with grep -r, and it >should be documented properly in grep.texi >and in 'grep --help' output and in NEWS (plus >maybe write a test case or two....). I can do the above if a decision is taken to adopt the feature.
