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.
