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

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