| To: | OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: utimensat fails to update ctime |
| From: | Eric Blake <ebb9@xxxxxxx> |
| Date: | Mon, 21 Dec 2009 21:37:24 -0700 |
| Cc: | Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxx> |
| In-reply-to: | <87hbrkjrk8.fsf@xxxxxxxxxxxxxxxxxxx> |
| References: | <4B2B156D.9040604@xxxxxxx> <87aaxclr4q.fsf@xxxxxxxxxxxxxxxxxxx> <4B2F7421.10005@xxxxxxx> <4B2F7A95.3010708@xxxxxxx> <87hbrkjrk8.fsf@xxxxxxxxxxxxxxxxxxx> |
| 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 |
According to OGAWA Hirofumi on 12/21/2009 8:05 AM: >> It may also be file-system dependent. On the machine where I saw the >> original failure: >>> $ uname -a >>> Linux fencepost 2.6.26-2-xen-amd64 #1 SMP Thu Nov 5 04:27:12 UTC 2009 >>> x86_64 GNU/Linux >> $ df -T . >> Filesystem Type 1K-blocks Used Available Use% Mounted on >> /dev/sdb1 xfs 419299328 269018656 150280672 65% /srv/data > > Thanks. > > This is good point. This would be xfs issue or design. xfs seems to have > own special handling of ctime. Here's another report, this time about an mtime update not happening on ntfs-3g. http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/19336 -- Don't work too hard, make some time for fun as well! Eric Blake ebb9@xxxxxxx |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 1/2] add lpath_to_handle to libhandle, Bill Kendall |
|---|---|
| Next by Date: | Re: utimensat fails to update ctime, OGAWA Hirofumi |
| Previous by Thread: | Re: utimensat fails to update ctime, OGAWA Hirofumi |
| Next by Thread: | Re: utimensat fails to update ctime, OGAWA Hirofumi |
| Indexes: | [Date] [Thread] [Top] [All Lists] |