Date: Sat, 11 Feb 2012 21:47:50 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Sergey Kandaurov <pluknet@gmail.com> Cc: Ed Schouten <ed@80386.nl>, fs@freebsd.org Subject: Re: Increase timestamp precision? Message-ID: <20120211204120.N2344@besplex.bde.org> In-Reply-To: <CAE-mSOKpYH1U4_h1W8d5acb6JnwRGbVmz9zYo6S5JcCmVoDf7g@mail.gmail.com> References: <20120210135527.GR1860@hoeg.nl> <CAE-mSOK2fo=PsvyQWW1Nz4XPqcr7fKDNCvVjHsUvR2uYmuqFMw@mail.gmail.com> <20120211042121.B3653@besplex.bde.org> <20120211121947.M903@besplex.bde.org> <CAE-mSOKpYH1U4_h1W8d5acb6JnwRGbVmz9zYo6S5JcCmVoDf7g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 11 Feb 2012, Sergey Kandaurov wrote: > On 11 February 2012 06:10, Bruce Evans <brde@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120211204120.N2344>