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
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-688338940-1328957270=:2344 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE 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(). =A0Thus it normall= y >> ... > > 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(). =A0This only sets timevals. >> =A0POSIX is apparently still failing to invent an interface to set its >> =A0own timespecs. =A0Any utime()-like interface invented after timespecs >> =A0should support timespecs, with setting timevals only supported by >> =A0compatibility cruft in this interface.[...] =A0futimesat() is unfortu= nately being >> =A0standardized[..] > > POSIX.1-2008 invented two *utimes() syscalls since then which both operat= e > 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 ow= ner % of the file and is not the super-user. %=20 % [EPERM] The named file has its immutable or append-only f= lag % set, see the chflags(2) manual page for more info= rma- % 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. %=20 % [EROFS] The file system containing the file is mounted re= ad- % 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. %=20 % 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 oth= er > *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 --0-688338940-1328957270=:2344--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120211204120.N2344>