[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.
- Re: touch, Eric Blake, 2009/12/22
- Re: touch,
Jim Meyering <=