[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.021 / U:27.136 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site