[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
From: |
Jamie Lokier |
Subject: |
Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build |
Date: |
Fri, 2 Apr 2004 17:23:38 +0100 |
User-agent: |
Mutt/1.4.1i |
Paul Eggert wrote:
> > 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.
pathconf() and fpathconf() are the obvious POSIXy interfaces for it.
Other possibilities are getxattr(), lgetxattr() and fgetxattr().
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. I
see no way around that, though. At least the attribute approach would
allow all three (different) delta values to be read in one call (listxattr).
Is there a de facto standard interface used by another OS for this?
> 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.
I didn't know that, thanks.
> 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.
Nice!
-- Jamie
Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build, James H. Cloos Jr., 2004/04/02
Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build, Andrew Pimlott, 2004/04/03