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

  

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.