Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build

[Jamie Lokier <jamie@shareable.org>]

Paul Eggert wrote:
> Jamie Lokier <jamie@shareable.org> writes:
> > The only thing I don't like is that some cacheing algorithms will need
> > to make 2 system calls for each file being checked, instead of 1.
> 
> 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().

If it's a per-filesystem quantity, then of course fstat() is all they
need.  So that would be great.

> Coreutils CVS assumes that the time stamp resolution is the same for
> all files within the same file system.  Is this a safe assumption
> under Linux?  I now worry that some NFS implementations might violate
> that assumption, if a remote host is exporting several native file
> systems, with different native resolutions, to the local host under a
> single mount point.  On the other hand, NFSv3 and NFSv4 clearly state
> that the time stamp resolution is a per-filesystem concept, so perhaps
> we should just consider that to be a buggy NFS server configuration.

Buugy, perhaps, but quite useful sometimes.  It's not a problem, if
we're clear that it's a per-filesystem quantity.  That kind of NFS
server configuration can advertise the coarsest timestamp resolution
of all the underlying filesystems.

NFS is not the only remote filesystem, and some like Samba can
certainly span multiple underlying filesystems without violating any
specificaiton.

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.

-- Jamie