[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: touch

From: Jim Meyering
Subject: Re: touch
Date: Tue, 22 Dec 2009 14:20:16 +0100

Eric Blake wrote:
> According to Jim Meyering on 12/22/2009 3:21 AM:
>> Eric Blake wrote:
>>> Yep - it is indeed an example of the mtime (and ctime) failing to update,
>>> even though utimensat claimed success.
>> Here's an interesting glibc change from just a few hours ago:
>> http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4286fa41edc33da4cfbc56c2c5902920a52e3184
> Hmm.  Uli used my patch:
> http://sourceware.org/ml/libc-alpha/2009-10/msg00017.html
> but committed it in his name.  Oh well.  And he never acknowledged my bug
> report about the issue, either - I had to manually close it:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=10992

Odd.  I assume Uli did not even see your report.

> That fixes the outstanding issue with futimens that was independent of
> kernel or fs version.  However, it does not fix the fact that the kernel
> folks have now proven that using UTIME_OMIT is file-system dependent on
> whether it will succeed.  At least they have confirmed that xfs, fuse, and
> ntfs-3g have bugs:
> http://lkml.org/lkml/2009/12/22/45
> http://lkml.org/lkml/2009/12/22/90
> Unfortunately, that means that the gnulib workaround is insufficient -
> there is no way that a single bit of information can cache whether
> utimensat will require an extra stat() call; it requires a per-device
> cache of whether the given device will operate correctly.  But the
> overhead of maintaining a per-device cache of whether utimensat works
> seems painful.  Maybe it is better to just bite the bullet and always call
> stat() on Linux for another year or two, even on file systems where
> UTIME_OMIT would have worked.

Ouch.  I don't see a reasonable compromise.  I too think that
utimensat is too low-level to endure the per-device-cache overhead.

reply via email to

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