-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to ctrn3e8 on 12/21/2009 9:07 PM: > On 12/21/2009 05:55 AM, Eric Blake wrote: > [please keep the list in the loop]
I repeat this plea. Don't send to just me - there are others trying to follow this discussion. > Okay, it is starting to get wierd. I should have known. Programmers > hate to test, but they do at least do a sanity check and you would have > to assume whoever changed things at least made sure the thing basically > worked before checking it in. Here is where you might start rolling > your eyes with a little with disbelief, but I still think there is > something here...(keep reading to the end!). Yesterday touch -m (using > the 8.2 version) did not work on my "home"(~) ext4 volume. It now > works on my ext4 volume. What changed I do not now. However, it > continues not to work on my ntfs-3g volume. The ouput (ntfs-3g case) is > provided below. So the question is, what did I change on the ext4 > volume?. The answer is, I haven't a clue. I did keep moving back and > forth between coreutils 8.2 and coretutils 7.6. Rebooting is not an > issue...I did try rebooting numerous times with the buggy behavior still > evident. Both volumes are on the same hard disk and I suppose there > could be a hardware issue...but the 7.6 version always works > consistently while the 8.2 seems to be hit or miss. See also this post on lkml: http://lkml.org/lkml/2009/12/21/118 In other words, it is very likely that there are fs-specific bugs in utimensat, and the kernel folks are working on the issue. Are you comfortable joining in on that thread, to provide your observations, since your report of ntfs-3g is a new instance of a bug report? But one thing is for certain - the bug is ONLY triggered when using UTIME_OMIT/UTIME_NOW; it is not triggered when explicit times are requested. Coreutils 7.6 always requested specific times, we didn't start using UTIME_OMIT until 8.1. So you won't see the problem with 7.6; and on 8.1 or newer, whether you see the bug will depend on whether the kernel is buggy for your particular fs. > Anyway the shell ouput for doing it on the ntfs-3g volume follows: > ________ > scit...@scitrin:~/P_Drive/testTouch$ stat file1 > File: `file1' > Size: 0 Blocks: 0 IO Block: 4096 regular > empty file > Device: 809h/2057d Inode: 6239 Links: > 1 > Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ > root) > Access: 2009-12-21 20:25:48.000000000 > -0700 > Modify: 2009-12-21 20:25:48.000000000 > -0700 > Change: 2009-12-21 20:28:38.000000000 > -0700 > scit...@scitrin:~/P_Drive/testTouch$ strace touch -m > file1 > execve("/bin/touch", ["touch", "-m", "file1"], [/* 57 vars */]) = > 0 > brk(0) = > 0x9cf2000 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0xb788a000 > access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.cache", O_RDONLY) = > 6 > fstat64(6, {st_mode=S_IFREG|0644, st_size=195491, ...}) = > 0 > mmap2(NULL, 195491, PROT_READ, MAP_PRIVATE, 6, 0) = > 0xb785a000 > close(6) = > 0 > open("/lib/librt.so.1", O_RDONLY) = > 6 > read(6, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\30\0\0004\0\0\0"..., > 512) = 512 > fstat64(6, {st_mode=S_IFREG|0755, st_size=38520, ...}) = > 0 > mmap2(NULL, 33364, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) > = 0xb7851000 > mmap2(0xb7858000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x6) = 0xb7858000 > close(6) = > 0 > open("/lib/libc.so.6", O_RDONLY) = > 6 > read(6, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340l\1\0004\0\0\0"..., > 512) = 512 > fstat64(6, {st_mode=S_IFREG|0755, st_size=1540581, ...}) = > 0 > mmap2(NULL, 1337608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, > 0) = 0xb770a000 > mmap2(0xb784b000, 12288, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x141) = 0xb784b000 > mmap2(0xb784e000, 10504, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb784e000 > close(6) = > 0 > open("/lib/libpthread.so.0", O_RDONLY) = > 6 > read(6, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360I\0\0004\0\0\0"..., > 512) = 512 > fstat64(6, {st_mode=S_IFREG|0755, st_size=117014, ...}) = > 0 > mmap2(NULL, 98784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) > = 0xb76f1000 > mmap2(0xb7706000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x14) = 0xb7706000 > mmap2(0xb7708000, 4576, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7708000 > close(6) = > 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0xb76f0000 > set_thread_area({entry_number:-1 -> 6, base_addr:0xb76f0ac0, > limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, > limit_in_pages:1, seg_not_present:0, useable:1}) = 0 > mprotect(0xb7706000, 4096, PROT_READ) = 0 > mprotect(0xb784b000, 8192, PROT_READ) = 0 > mprotect(0xb7858000, 4096, PROT_READ) = 0 > mprotect(0xb78a8000, 4096, PROT_READ) = 0 > munmap(0xb785a000, 195491) = 0 > set_tid_address(0xb76f0b28) = 14454 > set_robust_list(0xb76f0b30, 0xc) = 0 > futex(0xbfa2c3c0, FUTEX_WAKE_PRIVATE, 1) = 0 > futex(0xbfa2c3c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, > NULL, bfa2c3d0) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigaction(SIGRTMIN, {0xb76f53f0, [], SA_SIGINFO}, NULL, 8) = 0 > rt_sigaction(SIGRT_1, {0xb76f58c0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 > getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 > uname({sys="Linux", node="scitrin", ...}) = 0 > brk(0) = 0x9cf2000 > brk(0x9d13000) = 0x9d13000 > open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 6 > fstat64(6, {st_mode=S_IFREG|0644, st_size=1772320, ...}) = 0 > mmap2(NULL, 1772320, PROT_READ, MAP_PRIVATE, 6, 0) = 0xb753f000 > close(6) = 0 > open("file1", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_LARGEFILE, 0666) = 6 > dup2(6, 0) = 0 > close(6) = 0 > utimensat(0, NULL, {UTIME_OMIT, UTIME_NOW}, 0) = 0 > close(0) = 0 > close(1) = 0 > close(2) = 0 > exit_group(0) = ? > scit...@scitrin:~/P_Drive/testTouch$ stat file1 > File: `file1' > Size: 0 Blocks: 0 IO Block: 4096 regular > empty file > Device: 809h/2057d Inode: 6239 Links: 1 > Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2009-12-21 20:25:48.000000000 -0700 > Modify: 2009-12-21 20:25:48.000000000 -0700 > Change: 2009-12-21 20:28:38.000000000 -0700 Yep - it is indeed an example of the mtime (and ctime) failing to update, even though utimensat claimed success. > scit...@scitrin:~/P_Drive/testTouch$ > ___________ > Note: (here is where I probably don't know what I am talking > about...just a wild guess) There is a "close(6)" call before the > "utimenstat(...)" call. I don't have the source code, but I am > wondering if the 6 in close(6) is a file handle created in the > "open("file1......) = 6" call and whether the file is being closed and > thus "locked" before the "utimenstat(...)" call which appears to > actually be the function which modifies the time stamp.... Almost. The close(6) occurs right after dup2(6,0) - in other words, we are copying fd 6 over to fd 0, then calling utimensat on fd 0. Yes, utimensat is the syscall that changes (well, is supposed to change) the timestamp. > (or am i > totaly off on this?) This might explain why it could possibly work in > ext4 and not ntfs-3g, since ext4 has asynchronous lazy writes, while > ntfs-3g is probably synchronous. Fd 0 was the only thing open on the file during the utimensat call. But beyond that, it is the kernel/fs experts who will have to answer what is going on. It also means that my recent workaround in coreutils.git to work around an mtime of UTIME_OMIT may need to be expanded to also cover an atime of UTIME_OMIT to deal with your fs, before we release coreutils 8.3. > The coreutils package was not built on my machine, but was provided > (binary) by Archlinux. The package is 3.9Mb (and contains the > binaries). I will send you it in a separate email. That was probably not necessary. A URL to your binary tarball would have been sufficient, if I had even needed it in the first place, rather than filling my inbox. - -- 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/ iEYEARECAAYFAkswTEcACgkQ84KuGfSFAYBvNQCeJv6m3mPRT4NHrQCb5PAPj2g0 +c0AnjucE/Ky+R0japZ9VLv6Qkf6Aulp =WmCy -----END PGP SIGNATURE-----