-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 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. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkswwlMACgkQ84KuGfSFAYCFrQCgv2szEmTV8ZKNQLGKwkB2T1Po IVoAn2SEMKqZqgETYZ/5bRTPg2E6MUgA =8dha -----END PGP SIGNATURE-----