Eric Blake wrote: > According to Jim Meyering on 12/22/2009 3:21 AM: >> Eric Blake wrote: >>> Yep - it is indeed an example of the mtime (and ctime) failing to update, >>> even though utimensat claimed success. >> >> Here's an interesting glibc change from just a few hours ago: >> >> http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4286fa41edc33da4cfbc56c2c5902920a52e3184 > > Hmm. Uli used my patch: > http://sourceware.org/ml/libc-alpha/2009-10/msg00017.html > but committed it in his name. Oh well. And he never acknowledged my bug > report about the issue, either - I had to manually close it: > http://sources.redhat.com/bugzilla/show_bug.cgi?id=10992
Odd. I assume Uli did not even see your report. > That fixes the outstanding issue with futimens that was independent of > kernel or fs version. However, it does not fix the fact that the kernel > folks have now proven that using UTIME_OMIT is file-system dependent on > whether it will succeed. At least they have confirmed that xfs, fuse, and > ntfs-3g have bugs: > http://lkml.org/lkml/2009/12/22/45 > http://lkml.org/lkml/2009/12/22/90 > > Unfortunately, that means that the gnulib workaround is insufficient - > there is no way that a single bit of information can cache whether > utimensat will require an extra stat() call; it requires a per-device > cache of whether the given device will operate correctly. But the > overhead of maintaining a per-device cache of whether utimensat works > seems painful. Maybe it is better to just bite the bullet and always call > stat() on Linux for another year or two, even on file systems where > UTIME_OMIT would have worked. Ouch. I don't see a reasonable compromise. I too think that utimensat is too low-level to endure the per-device-cache overhead.
