From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nBO0GVXN018514 for ; Wed, 23 Dec 2009 18:16:31 -0600 Received: from mail-iw0-f183.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5BBEF1350236 for ; Wed, 23 Dec 2009 16:17:11 -0800 (PST) Received: from mail-iw0-f183.google.com (mail-iw0-f183.google.com [209.85.223.183]) by cuda.sgi.com with ESMTP id fm9Rjd2a2AnO6uXD for ; Wed, 23 Dec 2009 16:17:11 -0800 (PST) Received: by iwn13 with SMTP id 13so5288145iwn.20 for ; Wed, 23 Dec 2009 16:17:10 -0800 (PST) Message-ID: <4B32B303.6070807@gmail.com> Date: Wed, 23 Dec 2009 17:17:07 -0700 From: ctrn3e8 MIME-Version: 1.0 Subject: Re: [fuse-devel] utimensat fails to update ctime References: <4B2B156D.9040604@byu.net> <87aaxclr4q.fsf@devron.myhome.or.jp> <4B2F7421.10005@byu.net> <4B2F7A95.3010708@byu.net> <87hbrkjrk8.fsf@devron.myhome.or.jp> <4B304D04.6040501@byu.net> <87d427jscr.fsf@devron.myhome.or.jp> <4B3097C4.3060803@wanadoo.fr> <874onjjnln.fsf@devron.myhome.or.jp> <4B30B67A.7080703@wanadoo.fr> <87ljgvi1an.fsf@devron.myhome.or.jp> <4B30F0C9.2020702@wanadoo.fr> <87my1aevro.fsf@devron.myhome.or.jp> <4B3212ED.4090208@byu.net> In-Reply-To: <4B3212ED.4090208@byu.net> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0037169429948719136==" Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Eric Blake Cc: =?ISO-8859-1?Q?Jean-Pie?=@oss.sgi.com, Miklos Szeredi , fuse-devel@lists.sourceforge.net, bug-coreutils , =?ISO-8859-1?Q?rre_Andr=E9?= , Linux Kernel Mailing List , xfs@oss.sgi.com, Christoph Hellwig , OGAWA Hirofumi --===============0037169429948719136== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/23/2009 05:54 AM, Eric Blake wrote:

-----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-----

I'm okay testing any changes on my ntfs-3g volume. Also have an XFS volume. Just send me a patch.

Okay, I don't have the source code in front of me and really do not know all that is going on, and I am sure I am totally wrong about this and it will bug everyone, but I do have a stupid question.

The strace has the following function call (and it may be because I am looking at the trace rather than the actual source):

utimensat(0, NULL, {UTIME_OMIT, UTIME_NOW}, 0) = 0

The third parameter in the call appears to be a struct consisting of (let's assume 32 bit) two longs, so it will layout in memory as:

{
32bits  UTIME_OMIT
32bits  UTIME_NOW
}

The function definition for utimensat is:

int utimensat(int dirfd, const char *pathname,
                     const struct timespec times[2], int flags);

Note that the third parameter of the definition is an timespec array of 2 elements.

timespec is defined by :

struct timespec {
               time_t tv_sec;        /* seconds */
               long   tv_nsec;       /* nanoseconds */
           };


or consists of two  32 bit longs.

Thus the function expects the following layout in memory for the 3rd parameter:

{
32bits atime seconds
32bits atime nsec
32bits mtime seconds
32bits mtime nsec
}

The two don't seem to match.  Is this just because of the way the trace is printed? Am I missing something?


Also found : http://linux-man-pages.blogspot.com/2008/06/whats-wrong-with-kernel-userland_30.html which has the statement:  "Currently, Linux supports nanosecond timestamps on XFS, JFS, and ext4.". No mention of ntfs-3g support for nanosecond time stamping.

--===============0037169429948719136== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs --===============0037169429948719136==--