Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build

[Paul Eggert]

Jamie Lokier <address@hidden> writes:

> All Linux filesystems - the nanoseconds field is retained on in-memory
> inodes by the generic VFS code.

It's OK to do that, so long as 'stat' and 'fstat' truncate the
user-visible time stamps to the resolution of the filesystem.  This
shouldn't cost much.

> AFAIK there is no way to determine the stored resolution using file
> operations alone.

Would it be easy to add one?  For example, we might extend pathconf so
that pathconf(filename, _PC_MTIME_DELTA) returns the file system's
mtime stamp resolution in nanoseconds.

I write "mtime" because I understand that some Microsoft file systems
use different resolutions for mtime versus ctime versus atime, and
mtime resolution is all that I need for now.  Also, the NFSv3 protocol
supports a delta quantity that tells the NFS client the mtime
resolution on the NFS server, so if you assume NFSv3 or better the
time stamp resolution is known for remote servers too.

> This behaviour was established in 2.5.48, 18th November 2002.
> The behaviour might not be restricted to Linux, because non-Linux NFS
> clients may be connected to a Linux NFS server which has this behaviour.

Ouch.  Then it sounds like there's no easy workaround for existing
systems.  Still it'd be nice to fix the bug for future systems.