[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: touch
From: |
Eric Blake |
Subject: |
Re: touch |
Date: |
Mon, 21 Dec 2009 21:34:15 -0700 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 |
-----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:
> ________
> address@hidden:~/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
> address@hidden:~/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) = ?
> address@hidden:~/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.
> address@hidden:~/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 address@hidden
-----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-----
- touch, ctrn3e8, 2009/12/20
- Re: touch, Eric Blake, 2009/12/20
- Message not available
- Re: touch, Eric Blake, 2009/12/21
- Message not available
- Re: touch,
Eric Blake <=
- Re: touch, Jim Meyering, 2009/12/22
- Re: touch, Eric Blake, 2009/12/22
- Re: touch, Jim Meyering, 2009/12/22
Message not available
- Re: touch, Eric Blake, 2009/12/28
- Re: touch, ctrn3e8, 2009/12/29
- Re: touch, Eric Blake, 2009/12/29
- Re: touch, ctrn3e8, 2009/12/30
- Re: touch, Eric Blake, 2009/12/30
- Re: touch, Eric Blake, 2009/12/30
- Re: touch, Eric Blake, 2009/12/30