Re: `touch' broken on GNU

[Ben Asselstine]

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 <tschwinge@gnu.org> wrote:
> On Thu, Jul 20, 2006 at 08:41:02AM -0700, Paul Eggert wrote:
> > Thomas Schwinge <tschwinge@gnu.org> 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.
>
>
> > > thomas@leibniz:/var/tmp/coreutils/build $ src/touch foo
> > > thomas@leibniz:/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