Re: [PATCH] fts: introduce FTS_NOATIME

[Jim Meyering]

Eric Blake wrote:
> On 07/08/2011 12:03 PM, Paul Eggert wrote:
>> On 07/08/11 10:27, Eric Blake wrote:
>>> if O_NOATIME is 0, --noatime should be rejected as an outright
>>> impossibility.
>>>
>>> if O_NOATIME is non-zero, --noatime should enable FTS_NOATIME, but only
>>> as a best-effort (that is, the option is silently ignored where the
>>> kernel is too old),
>>
>> If --noatime is silently ignored in the latter case,
>> shouldn't it also be silently ignored in the former?
>> That would be more consistent across platforms.
>
> I'm 50-50.  The thought that I had was that if we can easily detect that
> O_NOATIME is unsupported, then being explicit about the error might prod
> more systems into implementing it (I don't know if anyone else besides
> Linux has this extension yet; Cygwin has a non-zero O_NOATIME, but it is
> currently a no-op to allow source compatibility and not an actual impact
> on behavior).
>
> On the other hand, it's hard to tell if O_NOATIME is supported on Linux,
> or if cygwin ever fixes O_NOTIME to work, your argument for consistency
> to other platforms is tempting...
>
> Anyone else want to chime in and sway the decision?

Consistently ignoring lack of O_NOATIME support does seem better, now.

I was initially inclined to make the lack of support more obvious so that
folks on less-well-endowed systems (that are still being developed) would
know there's room for improvement, but we should design user interfaces
for the long term.  The people who are in a position to change things
don't need diagnostics from tools to be prodded about O_NOATIME.