All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <ebb9@byu.net>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Christoph Hellwig <hch@lst.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	xfs@oss.sgi.com
Subject: Re: utimensat fails to update ctime
Date: Mon, 21 Dec 2009 21:37:24 -0700	[thread overview]
Message-ID: <4B304D04.6040501@byu.net> (raw)
In-Reply-To: <87hbrkjrk8.fsf@devron.myhome.or.jp>

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@byu.net

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <ebb9@byu.net>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	xfs@oss.sgi.com, Christoph Hellwig <hch@lst.de>
Subject: Re: utimensat fails to update ctime
Date: Mon, 21 Dec 2009 21:37:24 -0700	[thread overview]
Message-ID: <4B304D04.6040501@byu.net> (raw)
In-Reply-To: <87hbrkjrk8.fsf@devron.myhome.or.jp>

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@byu.net

  reply	other threads:[~2009-12-22  4:36 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18  5:38 utimensat fails to update ctime Eric Blake
2009-12-21  7:31 ` OGAWA Hirofumi
2009-12-21 13:12   ` Eric Blake
2009-12-21 13:39     ` Eric Blake
2009-12-21 15:05       ` OGAWA Hirofumi
2009-12-21 15:05         ` OGAWA Hirofumi
2009-12-22  4:37         ` Eric Blake [this message]
2009-12-22  4:37           ` Eric Blake
2009-12-22  9:00           ` OGAWA Hirofumi
2009-12-22  9:00             ` OGAWA Hirofumi
2009-12-22  9:56             ` [fuse-devel] " Jean-Pierre André
2009-12-22  9:56               ` Jean-Pierre André
2009-12-22 10:43               ` OGAWA Hirofumi
2009-12-22 10:43                 ` OGAWA Hirofumi
2009-12-22 12:07                 ` Jean-Pierre André
2009-12-22 12:07                   ` Jean-Pierre André
2009-12-22 13:00                   ` Miklos Szeredi
2009-12-22 13:00                     ` Miklos Szeredi
2009-12-22 13:30                   ` OGAWA Hirofumi
2009-12-22 13:30                     ` OGAWA Hirofumi
2009-12-22 16:16                     ` Jean-Pierre André
2009-12-22 16:16                       ` Jean-Pierre André
2009-12-22 17:58                       ` OGAWA Hirofumi
2009-12-22 17:58                         ` OGAWA Hirofumi
2009-12-23  9:43                         ` Jean-Pierre André
2009-12-23  9:43                           ` Jean-Pierre André
2009-12-23 11:08                           ` OGAWA Hirofumi
2009-12-23 11:08                             ` OGAWA Hirofumi
2009-12-23 12:54                         ` Eric Blake
2009-12-23 12:54                           ` Eric Blake
2009-12-23 19:23                           ` OGAWA Hirofumi
2009-12-23 19:23                             ` OGAWA Hirofumi
2009-12-24  0:17                           ` ctrn3e8
2009-12-24  0:50                             ` Eric Blake
2009-12-24  0:50                               ` Eric Blake
2009-12-23 14:28                         ` Jean-Pierre André
2009-12-23 14:28                           ` Jean-Pierre André
2009-12-22 12:34           ` Dave Chinner
2009-12-22 12:34             ` Dave Chinner
2009-12-22 12:42             ` Eric Blake
2009-12-22 12:42               ` Eric Blake
2009-12-23  7:53               ` Christoph Hellwig
2009-12-23  7:53                 ` Christoph Hellwig
2009-12-22 17:45         ` Christoph Hellwig
2009-12-22 17:45           ` Christoph Hellwig
2009-12-22 19:06           ` OGAWA Hirofumi
2009-12-22 19:06             ` OGAWA Hirofumi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B304D04.6040501@byu.net \
    --to=ebb9@byu.net \
    --cc=hch@lst.de \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.