Increase timestamp precision?

[Bruce Evans]

On Sat, 11 Feb 2012, Sergey Kandaurov wrote:

> On 11 February 2012 06:10, Bruce Evans <brde at optusnet.com.au> wrote:
>> - touch(1) normally uses gettimeofday() and utimes().  Thus it normally
>> ...
>
> In POSIX-2008 touch description mentions now that touch shall perform
> actions equivalent to futimens() or utimensat() (see below) depending
> on whether the specified file exists. It also introduces the concept of
> finegrained timestamps - a fractional part of second like:
> touch -d "2007-11-12 10:15:30.002Z"
> -d is a new way to specify your own time but in ISO 8601:2000 format

I saw a little of this on the POSIX mailing list.  POSIX has to specify
what happens when unrepresentable times are requested to be set or used,
not just for file times but also for timeouts.  I'm not sure how far it
has got.

>
>> Timstamping bugs not so near here:
>> ...
>> - POSIX is apparently inventing futimesat().  This only sets timevals.
>>  POSIX is apparently still failing to invent an interface to set its
>>  own timespecs.  Any utime()-like interface invented after timespecs
>>  should support timespecs, with setting timevals only supported by
>>  compatibility cruft in this interface.[...]  futimesat() is unfortunately being
>>  standardized[..]
>
> POSIX.1-2008 invented two *utimes() syscalls since then which both operate
> on timespecs.
> I implemented them a year ago, but failed to commit yet for some reason,
> particularity because of overcomplicated utimes(2) man page.

Do you mean that the FreeBSD man page is already overcomplicated, and that
adding to it work make it more so?  It certainly has long descrptions of
the possible errors.  The following seem to be wrong:

% ERRORS
%      The utimes() and lutimes() system calls will fail if:
% ...
%      [EPERM]            The times argument is not NULL and the calling
%                         process's effective user ID does not match the owner
%                         of the file and is not the super-user.
% 
%      [EPERM]            The named file has its immutable or append-only flag
%                         set, see the chflags(2) manual page for more informa-
%                         tion.

Bad grammar (comma splice).  This error can happen for almost all vfs
syscalls, and man pages shouldn't be made even more verbose with pointers
to chflags(2) for it.  They aren't similarly verbose for other attributes,
and the flags attribute is now 20 years old, so it should be as familiar
as the others.

% 
%      [EROFS]            The file system containing the file is mounted read-
%                         only.

These 3 should apply to all the utimes syscalls, since they are related to
writing the results to the underlying file system's inode and not related
to the pathname used to access the file.
% 
%      In addition to the errors returned by the utimes(), the futimesat() may
%      fail if:

"may fail"?  This weasel for "this standard is broken, so that broken but
influential systems can conform to it".

> - futimens() is like our futimes() but works with timespec();
> - utimensat() is like our futimesat(). It is "ours" because it was never
> standardized. Our manpage for futimesat() only mentions that it "follows
> The Open Group Extended API Set 2 specification."
> Linux manpage provides somewhat better history:
> This system call is nonstandard.  It was implemented from a specification that
> was proposed for POSIX.1, but that specification was replaced by the one for
> utimensat(2).

Hmm, I just noticed that at least old-POSIX doesn't have futimes() either.
futimesns() wouldn't be missed so much in portable code that had to
avoid futimes().  I wonder if FreeBSD doesn't need futimes(2) either,
since it can try using utimes() on "/dev/stdin" after swapping the fd
with 0 in case /dev/fd/<fd> is not present.

> utimensat() diverges from futimesat() by enabling usage of timespec and
> addition of the optional flag with only one existing bit that follows other
> *at() family convention:
>     AT_SYMLINK_NOFOLLOW
>             If path names a symbolic link, the symbolic link's dates are
>             changed.

Sounds like POSIX did the right thing, except for not implementing
futimens(), but futimens() can easily be implemented as part of
utimesnsat() by putting another flag somewhere to indicate that the
fd is the thing to be changed and that the string is not used.

Bruce