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