Very Computer

I've realized the current implementation is throwing away any sub-second
resolution in the last-modified time. Some platforms store both seconds
and microseconds (or nanoseconds in the case of Solaris), but the
st_mtime member retrieved by stat() only has the seconds part.

So I'm looking for two things: (1) the most portable/standard way of
getting the micro/nano second part from the stat structure and (2) the
best way to set that metadata back onto the newly restored file.

For the 'get' part, it looks like there's no standard API. Looks like a
bunch of ugly ifdefs are required. Does anyone have a sample piece of
code that handles the major platforms or just shows the way?

The 'set' part raises a question about the intention of SUS. The utime()
function is in the standard but is explicitly limited to seconds (SUSv3:
"The times in the structure utimbuf are measured in seconds since the
Epoch."). The utimes() function is also in SUS and allows microsecond
resolution ("The times in the timeval structure are measured in seconds
and microseconds since the Epoch"), but this interface is marked LEGACY
with a usage note indicating "For applications portability, the utime()
function should be used instead of utimes()". I don't get it - why would
the more capable interface be retired in favor of a dumber one? Is there
a non-legacy interface that supersedes utimes() and support setting
sub-second timestamps?

--
Thanks,
M.Biswas

Quote:> For the 'get' part, it looks like there's no standard API. Looks like a
> bunch of ugly ifdefs are required. Does anyone have a sample piece of
> code that handles the major platforms or just shows the way?

It's interesting that there's an almost irrelevant reference to the
possibility that the timespec structure may be defined as in <times.h> in
the SUSv3 stat() page.  That suggests that e.g. something like what Sun
does is permitted but not required.  The absence of any way to tell being
described suggests that there's no standard way to tell, meaning that
anything you come up with won't be standards-based, but will at best
work for now on the platforms you target.

Quote:> The 'set' part raises a question about the intention of SUS. The utime()
> function is in the standard but is explicitly limited to seconds (SUSv3:
> "The times in the structure utimbuf are measured in seconds since the
> Epoch."). The utimes() function is also in SUS and allows microsecond
> resolution ("The times in the timeval structure are measured in seconds
> and microseconds since the Epoch"), but this interface is marked LEGACY
> with a usage note indicating "For applications portability, the utime()
> function should be used instead of utimes()". I don't get it - why would
> the more capable interface be retired in favor of a dumber one? Is there
> a non-legacy interface that supersedes utimes() and support setting
> sub-second timestamps?

At one time, utimes() was an extension feature rather than a base feature.

They simply reserved the option to remove it ("may be withdrawn") later,
perhaps if there's not enough interest in keeping it.

Looks to me like coding for sub-second timestamps simply isn't maximally
portable.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"