<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
On 12/23/2009 05:54 AM, Eric Blake wrote:
<blockquote cite="mid:4B3212ED.4090208@byu.net" type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to OGAWA Hirofumi on 12/22/2009 10:58 AM:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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 ?
</pre>
</blockquote>
<pre wrap="">
Thanks. Sounds good. I'm not using ntfs-3g actually, I just bridged the
bug report on lkml to others. Eric?
</pre>
</blockquote>
<pre wrap="">
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 <a class="moz-txt-link-abbreviated" href="mailto:ebb9@byu.net">ebb9@byu.net</a>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a>
iEYEARECAAYFAksyEu0ACgkQ84KuGfSFAYCrzACgirIjqmS7vFOBcI8xau6jHEa0
4L0AnAjJkje+tSMF/FZkTbkohg/fhQ+i
=ngx0
-----END PGP SIGNATURE-----
</pre>
</blockquote>
<font face="Arial">I'm okay testing any changes on my ntfs-3g volume.
Also have an XFS volume. Just send me a patch.<br>
<br>
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. <br>
<br>
The strace has the following function call (and it may be because I am
looking at the trace rather than the actual source):<br>
<br>
</font>
<pre wrap="">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:
<b>int</b> <b>utimensat(int</b> <i>dirfd</i><b>,</b> <b>const</b> <b>char</b> <b>*</b><i>pathname</i><b>,</b>
<b>const</b> <b>struct</b> <b>timespec</b> <i>times</i><b>[2],</b> <b>int</b> <i>flags</i><b>);
</b>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 : <a class="moz-txt-link-freetext" href="http://linux-man-pages.blogspot.com/2008/06/whats-wrong-with-kernel-userland_30.html">http://linux-man-pages.blogspot.com/2008/06/whats-wrong-with-kernel-userland_30.html</a> which has the statement: "Currently, Linux supports nanosecond timestamps on XFS, JFS, and ext4.". No mention of ntfs-3g support for nanosecond time stamping.
</pre>
<br>
<font face="Arial"><br>
<br>
</font>
</body>
</html>