Comment 3 for bug 296955

Revision history for this message
Derick Eddington (derick-eddington) wrote : Re: [Bug 296955] [NEW] file-ctime and file-mtime giving wrong value

On Tue, 2008-11-11 at 21:56 +0000, Abdulaziz Ghuloum wrote:
> On Nov 11, 2008, at 4:22 PM, Derick Eddington wrote:
>
> > Also, is there some POSIX facility to get finer-than-second resolution
> > of files' ctime and mtime that file-ctime and file-mtime are being
> > left
> > open to supporting in the future, and that's why these values are
> > multiplied by #e1e9?
>
> What do I know! Looks like there is a nanosecond field for stat.
>
> In /usr/include/sys/stat.h under Darwin:

Ah, cool. Also just discovered the same under Linux (manpage for stat):

NOTES
   Linux Notes
       Since kernel 2.5.48, the stat structure supports nanosecond resolution for the
       three file timestamp fields. Glibc exposes the nanosecond component of each
       field using names either of the form st_atim.tv_nsec, if the _BSD_SOURCE or
       _SVID_SOURCE feature test macro is defined, or of the form st_atimensec, if nei‐
       ther of these macros is defined. On file systems that do not support sub-second
       timestamps, these nanosecond fields are returned with the value 0.

I was using the POSIX docs earlier, and these fields aren't in POSIX
(though it seems to leave it open so the standard fields could be any
resolution), but I bet it'd be relatively easy to #ifdef them portably.