Re: touch

[Eric Blake]

-----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-----