xfs
[Top] [All Lists]

Re: [fuse-devel] utimensat fails to update ctime

To: Eric Blake <ebb9@xxxxxxx>
Subject: Re: [fuse-devel] utimensat fails to update ctime
From: ctrn3e8 <ctrn3e8@xxxxxxxxx>
Date: Wed, 23 Dec 2009 17:17:07 -0700
Cc: OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>, Jean-Pierre André <jean-pierre.andre@xxxxxxxxxx>, fuse-devel@xxxxxxxxxxxxxxxxxxxxx, Miklos Szeredi <miklos@xxxxxxxxxx>, Christoph Hellwig <hch@xxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, bug-coreutils <bug-coreutils@xxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=CFlLKj+cf55V2+29+mjB5BH9swXEAlVQIepjahpX10Q=; b=oPMn3LYeML+w7ffZ2hn4f1+tPX3lnrz9Cjr0bmgF8et3M6nPsFz5iS6Y0CGoM1hk3A 2BFTk2kW+BWMvj5w6BlL75eC79wHcY7ypCa6G+oDks288mOE+Z36i94Xwr82Fa9pq/U/ awH9ArGtwtPnaKJ0C2jdZ2aqEZvxzXxp1QGJE=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Ofo/btZg8rMCFSPJr75Z6hNB6uLhcpGhSpKxsTj5SQ1HZTf915NuI18qP5kf9u8LgE awiAvjQuNAysvTe+jF05JbalHTONI+/0Sp2my0QO6vg7BD2HKQqxW6iXGpmeOS1C0KP8 npuX7GlGontge+SzTb218WeDhsjXijSg+OcBM=
In-reply-to: <4B3212ED.4090208@xxxxxxx>
References: <4B2B156D.9040604@xxxxxxx> <87aaxclr4q.fsf@xxxxxxxxxxxxxxxxxxx> <4B2F7421.10005@xxxxxxx> <4B2F7A95.3010708@xxxxxxx> <87hbrkjrk8.fsf@xxxxxxxxxxxxxxxxxxx> <4B304D04.6040501@xxxxxxx> <87d427jscr.fsf@xxxxxxxxxxxxxxxxxxx> <4B3097C4.3060803@xxxxxxxxxx> <874onjjnln.fsf@xxxxxxxxxxxxxxxxxxx> <4B30B67A.7080703@xxxxxxxxxx> <87ljgvi1an.fsf@xxxxxxxxxxxxxxxxxxx> <4B30F0C9.2020702@xxxxxxxxxx> <87my1aevro.fsf@xxxxxxxxxxxxxxxxxxx> <4B3212ED.4090208@xxxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091215 Shredder/3.0
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@xxxxxxx
-----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.






<Prev in Thread] Current Thread [Next in Thread>