🚀 go-pugleaf

<p53cy6n8dj.fsf@lemming.engeast.baynetworks.com> divulged:

>Obviously struct stat's st_mtime, etc. is not going to do it, since it
>stores times as time_t which is defined by the ISO C standard to be an
>integral value containing "seconds since the epoch" and so certainly
>cannot store any sub-second value.

iso c just says it represents a time and that it's an arithmetic type.
it's posix/sus that says it's the number of seconds since the epoch, which
causes people to use arithmetic directly (t1-t0) rather than using the
standard routine to obtain difference in seconds and (potentially) sub-
seconds (difftime(t1,t0)).

>However, all is not well.  Although there is a way to _read_ sub-second
>timestamps (at least an ad hoc standard; I don't believe, although I'm
>not sure, that this has been blessed by POSIX or anyone else; it doesn't
>even seem to be in the SUv2 spec), 

since the current posix and susv2 spec's are the same it isn't too much of
a surprise that they agree.  you are correct, they don't require any
timespec fields, though that doesn't stop an implementation from supplying
them (as you've noted).

>there is no way to _set_ sub-second timestamps.  That means that commands
>like touch, "cp -p", etc. cannot preserve these timestamps.

this need not be true.  on systems that supply timespec (or long long)
fields it is possible for tools (e.g, cp or touch) to use them.  granted
most tools don't even look for them, so it's still something of a catch-22.

>Combined with the fact that many utilities that store timestamps
>internally (like ar(1) or tar(1), for example) don't provide any way to
>store them, and that at least older versions of NFS for example couldn't
>communicate them, this makes their use problematic still.

agreed.  pax extended headers can store sub-second values for the times,
which logic could be adopted by other systems, but so far this has not been
done to any useful degree.

-- 
bringing you boring signatures for 17 years