bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: timestamp resolution


From: James Youngman
Subject: Re: timestamp resolution
Date: Thu, 3 May 2007 23:20:31 +0100

[ CC += address@hidden ]

On 5/3/07, Ulrich Drepper <address@hidden> wrote:
On today's call we agreed on the following proposal (names are negotiable):

1. add _PC_TIMESTAMP_RESOLUTION

[ for those recently joining, this would be a pathconf() configuration
option which returns the filesystem timestamp resolution for a given
file. ]

Is the assumption then that all filesystems record timestamps as
values of the form
(Epoch + N *  pathconf(_PC_TIMESTAMP_RESOLUTION)), where Epoch is the
Unix epoch?

I can't think offhand of an exception.  The difference between the
MS-DOS epoch and the Unix epoch is evenly divisible by 2 seconds (I
think; though there were 9 leap seconds in the 1970s, hmm...).  But
might there be an exception I can't immediately recall?  Quite
probably.

3. handle _PC_TIMESTAMP_RESOLUTION in pathconf() and fpathconf().
   The two functions return the timestamp resolution for the file
   system in nanoseconds.

What about rounding rules?  For an application to do the right thing
with the timestamp of two files, on different filesystems, it will
need to know how both filesystems handle timestamp rounding.  (hence,
CC: bug-make)

   We don't define network filesystems in POSIX but there should be a
   note that the underlying filesystems resolution is returned.

Presumably, -1 is returned if this cannot be determined?   (For
example imagine an NFS version Z server serving files from a umsdos
filesystem to a modern client, for small values of Z).

James.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]