[lkml]   [2004]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
Jamie Lokier <> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:02    [W:0.072 / U:4.736 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site