From: Eric Blake <ebb9@byu.net>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: "Miklos Szeredi" <miklos@szeredi.hu>,
fuse-devel@lists.sourceforge.net,
bug-coreutils <bug-coreutils@gnu.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, ctrn3e8 <ctrn3e8@gmail.com>,
"Jean-Pierre André" <jean-pierre.andre@wanadoo.fr>,
"Christoph Hellwig" <hch@lst.de>
Subject: Re: [fuse-devel] utimensat fails to update ctime
Date: Wed, 23 Dec 2009 05:54:05 -0700 [thread overview]
Message-ID: <4B3212ED.4090208@byu.net> (raw)
In-Reply-To: <87my1aevro.fsf@devron.myhome.or.jp>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to OGAWA Hirofumi on 12/22/2009 10:58 AM:
>> I suggest I port Miklos patch to fuse-lite soon,
>> and delay the low-level case (and microsecond
>> precision) until January. Does that suit your needs ?
>
> Thanks. Sounds good. I'm not using ntfs-3g actually, I just bridged the
> bug report on lkml to others. Eric?
I'm also bridging the report from a coreutils user (now cc'd). Since I
also don't use ntfs-3g, I'm hoping that ctrn3e8 will be able to help test
whether the latest patch to ntfs-3g makes a difference in properly setting
times. To me, delaying precision while fixing UTIME_OMIT semantics is a
reasonable approach.
By the way, is there any reliable way, other than uname() and checking for
a minimum kernel version, to tell if all file systems will properly
support UTIME_OMIT? For coreutils 8.3, we will be inserting a workaround
where instead of using UTIME_OMIT, we call fstatat() in advance of
utimensat() and pass the original timestamp down. But it would be nice to
avoid the penalty of the extra stat if there were a reliable way to ensure
that, regardless of file system, the use of UTIME_OMIT will be honored.
After all, coreutils wants touch(1) to work regardless of how old the
user's kernel and file system drivers are.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksyEu0ACgkQ84KuGfSFAYCrzACgirIjqmS7vFOBcI8xau6jHEa0
4L0AnAjJkje+tSMF/FZkTbkohg/fhQ+i
=ngx0
-----END PGP SIGNATURE-----
_______________________________________________
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: "Jean-Pierre André" <jean-pierre.andre@wanadoo.fr>,
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, ctrn3e8 <ctrn3e8@gmail.com>,
bug-coreutils <bug-coreutils@gnu.org>
Subject: Re: [fuse-devel] utimensat fails to update ctime
Date: Wed, 23 Dec 2009 05:54:05 -0700 [thread overview]
Message-ID: <4B3212ED.4090208@byu.net> (raw)
In-Reply-To: <87my1aevro.fsf@devron.myhome.or.jp>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to OGAWA Hirofumi on 12/22/2009 10:58 AM:
>> I suggest I port Miklos patch to fuse-lite soon,
>> and delay the low-level case (and microsecond
>> precision) until January. Does that suit your needs ?
>
> Thanks. Sounds good. I'm not using ntfs-3g actually, I just bridged the
> bug report on lkml to others. Eric?
I'm also bridging the report from a coreutils user (now cc'd). Since I
also don't use ntfs-3g, I'm hoping that ctrn3e8 will be able to help test
whether the latest patch to ntfs-3g makes a difference in properly setting
times. To me, delaying precision while fixing UTIME_OMIT semantics is a
reasonable approach.
By the way, is there any reliable way, other than uname() and checking for
a minimum kernel version, to tell if all file systems will properly
support UTIME_OMIT? For coreutils 8.3, we will be inserting a workaround
where instead of using UTIME_OMIT, we call fstatat() in advance of
utimensat() and pass the original timestamp down. But it would be nice to
avoid the penalty of the extra stat if there were a reliable way to ensure
that, regardless of file system, the use of UTIME_OMIT will be honored.
After all, coreutils wants touch(1) to work regardless of how old the
user's kernel and file system drivers are.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksyEu0ACgkQ84KuGfSFAYCrzACgirIjqmS7vFOBcI8xau6jHEa0
4L0AnAjJkje+tSMF/FZkTbkohg/fhQ+i
=ngx0
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-12-23 12:52 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
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 [this message]
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=4B3212ED.4090208@byu.net \
--to=ebb9@byu.net \
--cc=bug-coreutils@gnu.org \
--cc=ctrn3e8@gmail.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=hch@lst.de \
--cc=hirofumi@mail.parknet.co.jp \
--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 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.