From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: "Jean-Pierre André" <jean-pierre.andre@wanadoo.fr>
Cc: Eric Blake <ebb9@byu.net>, Miklos Szeredi <miklos@szeredi.hu>,
fuse-devel@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, Christoph Hellwig <hch@lst.de>
Subject: Re: [fuse-devel] utimensat fails to update ctime
Date: Tue, 22 Dec 2009 22:30:24 +0900 [thread overview]
Message-ID: <87ljgvi1an.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <4B30B67A.7080703@wanadoo.fr> ("Jean-Pierre André"'s message of "Tue, 22 Dec 2009 13:07:22 +0100")
Jean-Pierre André <jean-pierre.andre@wanadoo.fr> writes:
> Hi again,
Hi,
>> Well, the problem seems in fuse_lib_setattr() and ntfs_fuse_setattr()
>> (lowlevel op too).
>>
>> The both functions is requiring "ATIME | MTIME". Doesn't it mean the
>> ntfs-3g can't set only MTIME like above utimensat()?
>>
>
> With ntfs-3g this is not directly possible, because
> the interface does not provide flags telling which
> timestamps should be updated. The only way would
> be fuse feeding both values (even though unchanged)
> before calling ntfs-3g. This is true for all versions of
> ntfs-3g.
Yes, with fuse_operations. It is why I'm saying the issue is libfuse or
ntfs-3g.
But I noticed ntfs-3g is including libfuse-lite sources and use it with
static link (I might be wrong here, because I just looked ntfs-3g source
slightly). AFAIK, the fuse of kernel part is passing the flags of some
sort of detail always.
[BTW, the code of that part in kernel may be the following,
fs/fuse/dir.c:iattr_to_fattr(),
if (ivalid & ATTR_ATIME) {
arg->valid |= FATTR_ATIME;
arg->atime = iattr->ia_atime.tv_sec;
arg->atimensec = iattr->ia_atime.tv_nsec;
if (!(ivalid & ATTR_ATIME_SET))
arg->valid |= FATTR_ATIME_NOW;
}
if ((ivalid & ATTR_MTIME) && update_mtime(ivalid)) {
arg->valid |= FATTR_MTIME;
arg->mtime = iattr->ia_mtime.tv_sec;
arg->mtimensec = iattr->ia_mtime.tv_nsec;
if (!(ivalid & ATTR_MTIME_SET))
arg->valid |= FATTR_MTIME_NOW;
}
]
So, if libfuse-lite was fixed to supported that update request, it would
be able to do even if fuse_operations. I.e. in libfuse-lite, emulate
"ATIME | MTIME" request if "MTIME" only (pass unchanged original atime),
then call ->utime() callback. (or adds new utime2 callback with flags, or
something other solutions)
Or, if that request is known limitation of fuse_operations, I think it
would be clear state and ok. The fs needs to use lowlevel op to support
that.
> With lowntfs-3g (release candidate only), this could
> be possible.... but this is not implemented, as the
> case was never found up to now. I can provide you
> with a patch,... if fuse can feed in the flags selectively.
Yes. AFAIK, fuse of kernel part is passing FATTR_MTIME without
FATTR_ATIME to userland (i.e. FUSE_SET_ATTR_ATIME and
FUSE_SET_ATTR_MTIME in libfuse).
I think it's good to implement if it's not design decision of ntfs-3g.
[BTW, just my guess though, it would be good to use "if (vaild &
ATTR_XXX)" style, not "switch()" to support various combinations of
flags]
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-12-22 13:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4B2B156D.9040604@byu.net>
[not found] ` <87aaxclr4q.fsf@devron.myhome.or.jp>
[not found] ` <4B2F7421.10005@byu.net>
[not found] ` <4B2F7A95.3010708@byu.net>
2009-12-21 15:05 ` utimensat fails to update ctime OGAWA Hirofumi
2009-12-22 4:37 ` Eric Blake
2009-12-22 9:00 ` OGAWA Hirofumi
2009-12-22 9:56 ` [fuse-devel] " Jean-Pierre André
2009-12-22 10:43 ` OGAWA Hirofumi
2009-12-22 12:07 ` Jean-Pierre André
2009-12-22 13:00 ` Miklos Szeredi
2009-12-22 13:30 ` OGAWA Hirofumi [this message]
2009-12-22 16:16 ` Jean-Pierre André
2009-12-22 17:58 ` OGAWA Hirofumi
2009-12-23 9:43 ` Jean-Pierre André
2009-12-23 11:08 ` OGAWA Hirofumi
2009-12-23 12:54 ` Eric Blake
2009-12-23 19:23 ` OGAWA Hirofumi
2009-12-24 0:17 ` ctrn3e8
2009-12-24 0:50 ` Eric Blake
2009-12-23 14:28 ` Jean-Pierre André
2009-12-22 12:34 ` Dave Chinner
2009-12-22 12:42 ` Eric Blake
2009-12-23 7:53 ` Christoph Hellwig
2009-12-22 17:45 ` Christoph Hellwig
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=87ljgvi1an.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=jean-pierre.andre@wanadoo.fr \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox