Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build

[Paul Eggert]

Jamie Lokier <address@hidden> writes:

>> Do you mean for mtime versus atime (versus ctime)?  Yes, in that case
>> getxattr etc. would be a better choice.
>
> No, I mean that they currently call fstat().  In future they'd need to
> call fstat()+getxattr().

Coreutils currently assumes that the time stamp resolution is a
per-filesystem quantity, and it keeps track of all the filesystems
that it's seen, so the number of extra calls to getxattr for this
purpose would be quite small.  This is all assuming that other
programs aren't mutating the file system mounts while 'cp' is running,
but that assumption is already hardwired in several other places.

> With that in mind, we'd need to be clear that the resolution actually
> stored may exceed the resolution advertised.  I don't know whether
> that breaks coreutils' assumption.

I think it'd be good enough for coreutils.

What's the next step to get this sort of thing running?  (I haven't
had much luck getting my (rare) Linux patches accepted....)

PS.  While we're on the subject, I'd like to add a utimens system
call, which behaves like utime/utimes except that it specifies a
nanosecond-resolution time stamp.  This will allow programs like 'cp
-p', 'mv', and 'tar' to copy timestamps correctly; currently they lose
the low order part of the time stamps when copying.