From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Eric Blake <ebb9@byu.net>
Cc: fuse-devel@lists.sourceforge.net,
Miklos Szeredi <miklos@szeredi.hu>,
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: Tue, 22 Dec 2009 18:00:36 +0900 [thread overview]
Message-ID: <87d427jscr.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <4B304D04.6040501@byu.net> (Eric Blake's message of "Mon, 21 Dec 2009 21:37:24 -0700")
Eric Blake <ebb9@byu.net> writes:
> 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
It is likely the issue of libfuse or ntfs-3g. I don't know about ntfs-3g
people at all. So, for now, just Cc: to fuse people.
> utimensat(0, NULL, {UTIME_OMIT, UTIME_NOW}, 0) = 0
>From this, "ia_valid" will have "ATTR_CTIME | ATTR_MTIME". And the
request would pass to userland via fuse of kernel part, then it will be
handled by libfuse.
>From quick grep of libfuse and ntfs-3g (would not be latest), ntfs-3g is
using "struct fuse_operations", not "struct fuse_lowlevel_ops".
So, fuse_lib_setattr() would be the handler for it in libfuse. And, from
the following part, it seems to require the both of MTIME and ATIME to
call ntfs-3g's ->utime handler.
I don't know whether it is limitation or bug in fuse_operations.
Any ideas?
if (!err &&
(valid & (FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME)) ==
(FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME)) {
struct timespec tv[2];
tv[0].tv_sec = attr->st_atime;
tv[0].tv_nsec = ST_ATIM_NSEC(attr);
tv[1].tv_sec = attr->st_mtime;
tv[1].tv_nsec = ST_MTIM_NSEC(attr);
err = fuse_fs_utimens(f->fs, path, tv);
}
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Eric Blake <ebb9@byu.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, Christoph Hellwig <hch@lst.de>,
Miklos Szeredi <miklos@szeredi.hu>,
fuse-devel@lists.sourceforge.net
Subject: Re: utimensat fails to update ctime
Date: Tue, 22 Dec 2009 18:00:36 +0900 [thread overview]
Message-ID: <87d427jscr.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <4B304D04.6040501@byu.net> (Eric Blake's message of "Mon, 21 Dec 2009 21:37:24 -0700")
Eric Blake <ebb9@byu.net> writes:
> 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
It is likely the issue of libfuse or ntfs-3g. I don't know about ntfs-3g
people at all. So, for now, just Cc: to fuse people.
> utimensat(0, NULL, {UTIME_OMIT, UTIME_NOW}, 0) = 0
>From this, "ia_valid" will have "ATTR_CTIME | ATTR_MTIME". And the
request would pass to userland via fuse of kernel part, then it will be
handled by libfuse.
>From quick grep of libfuse and ntfs-3g (would not be latest), ntfs-3g is
using "struct fuse_operations", not "struct fuse_lowlevel_ops".
So, fuse_lib_setattr() would be the handler for it in libfuse. And, from
the following part, it seems to require the both of MTIME and ATIME to
call ntfs-3g's ->utime handler.
I don't know whether it is limitation or bug in fuse_operations.
Any ideas?
if (!err &&
(valid & (FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME)) ==
(FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME)) {
struct timespec tv[2];
tv[0].tv_sec = attr->st_atime;
tv[0].tv_nsec = ST_ATIM_NSEC(attr);
tv[1].tv_sec = attr->st_mtime;
tv[1].tv_nsec = ST_MTIM_NSEC(attr);
err = fuse_fs_utimens(f->fs, path, tv);
}
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
next prev parent reply other threads:[~2009-12-22 9:00 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
2009-12-22 4:37 ` Eric Blake
2009-12-22 9:00 ` OGAWA Hirofumi [this message]
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=87d427jscr.fsf@devron.myhome.or.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=ebb9@byu.net \
--cc=fuse-devel@lists.sourceforge.net \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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.