[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, 28 Dec 2009 07:10:20 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

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             address@hidden
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/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]