To reproduce the bug:
$ touch foo
$ ls -l foo
-rw-r--r-- 1 bing root 0 Jan 1 1970 foo
Debugging using rpctrace:
$ rpctrace ./touch foo
.
.
154->file_utimes ({16887847 16887048} {45872 0}) = 0
.
.
$ stat -c%X foo [show atime as time_t]
16887847
$ stat -c%Y foo [show mtime as time_t]
45872
Mental backtrace:
coreutils touch (lib/utimens.c:futimens)
glibc (sysdeps/mach/hurd/futimes.c:futimes)
libdiskfs (libdiskfs/file-utimes.c:diskfs_S_file_utimes)
fs interface (hurd/fs.defs:file_utimes)
Intent of the code:
touch wants to call futimes with NULL, so that the file will have the
current time for atime and mtime.
futimes wants to call diskfs_S_file_utimes with -1 in the microseconds
of new_atime and new_mtime (again to show that we want the current
time).
diskfs_S_file_utimes wants to set atime and mtime flags
which libdiskfs/node-times.c:diskfs_set_node_times will eventually
set with the node's atime and mtime with the current time.
What's going wrong:
file_utimes is not getting -1 in the microseconds fields.
file_utimes gets the following from glibc's futimes() call:
new_atime.seconds == 16887847
new_atime.microseconds == 16887048
new_mtime.seconds == 45872
new_mtime.microseconds == 0
rpctrace shows this, and the stat reaffirms the values.
This would point to glibc's futimes() call as the problem, but i'll be
darned if I can spot the problem.
Incidentally after waiting a while, and re-running the test, rpctrace
showed that the new_mtime.microseconds value had changed from 0 to 1.
regards,
Ben
On 7/20/06, Thomas Schwinge <[EMAIL PROTECTED]> wrote:
On Thu, Jul 20, 2006 at 08:41:02AM -0700, Paul Eggert wrote:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
>
> > Before I start digging deeper: can someone imaging offhand why `touch'
> > broke?
>
> Thanks for the report. Which version of 'touch'? The email didn't
> say. Is this CVS coreutils or some other version?
Sorry, yes, that's cvs's HEAD, but has also been seen with 5.9x.
> > [EMAIL PROTECTED]:/var/tmp/coreutils/build $ src/touch foo
> > [EMAIL PROTECTED]:/var/tmp/coreutils/build $ ls -l foo
> > -rw-r--r-- 1 thomas users 0 Jan 1 1970 foo
>
> It may be a problem in the Hurd's implementation of futimesat and/or
> futimes.
That may indeed very well be. People are currently looking into this
issue.
> Perhaps you can strace or truss or do whatever the Hurd
> equivalent is
rpctrace.
Regards,
Thomas
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
