All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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.