-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to ctrn3e8 on 12/20/2009 10:04 PM: >>>> touch -m no longer seems to modify the file modification date. >>>> Archlinux, >>>> coreutils-8.2 (package coreutils-8.2-1-i686). Works if use >>>> coreutils-7.6. >>>> > What kernel version on which architecture (uname -a)? Can you send an > strace? We recently fixed a bug with kernel 2.6.32 failing to change > ctime when you use 'touch -a'; I wonder if there is another kernel bug we > need to be aware of. > > execve("/bin/touch", ["touch", "-m", "startTimidity"], [/* 56 vars */]) = 0 > utimensat(0, NULL, {UTIME_OMIT, UTIME_NOW}, 0) = 0
It now appears from lkml traffic that this issue has been fixed for most file systems in concert with kernel 2.6.32 or newer, if you are running a bleeding-edge ntfs-3g file system. However, gnulib should keep a workaround for the next couple years or so, until we can be reasonably sure that it is easier to tell people to update their file systems than to keep the workaround that (slightly) penalizes working file systems (the lkml list pointed out that our most common use of the utimensat syscall is via the futimens interface, where the kernel already has the file metadata in cache because of the open() and/or fstat()). But I still need a couple more pieces of information, before I know whether the workaround requires a gettime() or whether it is cheaper and only requires fstat(). We have proven the bug you reported against ntfs-3g occurs with UTIME_OMIT/UTIME_NOW. Does your unpatched ntfs-3g file system also exhibit the bug with UTIME_OMIT/valid (test this by using 'touch --ref file1 -m file2', and report whether file2 changed mtime and ctime). Also, does the bug occur with valid/UTIME_NOW (this is harder to test; touch does not expose that interface. I'm not even sure that the gnulib test exercised this; but you could at least report the results of 'make -k check' from your coreutils source directory, if you have built from source. If you need help writing a simple C program that tests this, let me know). - -- 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/ iEYEARECAAYFAks4vEwACgkQ84KuGfSFAYBa7gCfU26IT2jOfaePsoBloh6frkWV O4QAnigOmxpz7ytPxef561Fn+RXkIfFv =1L7L -----END PGP SIGNATURE-----