bug#18406: O_NOATIME patch

[starlight . 2014q3]

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.