On Fri, 2006-03-03 at 15:44, Paul Eggert wrote:
> yyyy@xxxxxxxxxx writes:
>
> > posix_utimens_at - set file access and modification times
>
> As it happens I today proposed something quite similar, though
> simpler. In my 20060303a Aardvark for ExtAPI_2.1_CR, I proposed that
> the 'struct timeval' of futimesat be changed to 'struct timespec'.
While discussing this in Ottawa with Ulrich Drepper and Don Cragun, the
problem is that there is existing practice (in Solaris 10) for
futimesat() with timeval rather than timespec.
>
> The only real difference between the two proposals is the name of the
> functions. I prefer to avoid the "posix_" prefix here, since it
> doesn't fit in well with the naming convention of other functions like
> openat, fstatat, etc. I realize that there's been some concern about
> the leading 'f' of these functions' names, but whatever naming convention
> is decided should also apply to the new futimensat (or whatever) function.
>
The general rules is "if the committee is inventing it, then the posix_
prefix should be used; if it is existing practice, follow the existing
practice". Of course, there is a heavy pushback against committee
invention, but here is a case where it seems justifiable to me.
>
> > time_t st_atime Time of last access, seconds part
> > time_t st_mtime Time of last data modification, seconds part
> > time_t st_ctime Time of last status change, seconds part
> > long st_atime_nsec Time of last access, nanoseconds part
> > long st_mtime_nsec Time of last data modification, nanoseconds
>part
> > long st_ctime_nsec Time of last status change, nanoseconds part
>
> This proposal makes it inconvenient to write application code, since
> the time stamps are not in 'struct timespec' format. For example, if
> I want to copy the last access and data modification times of one file
> to another, I'll have to grab four scalar fields rather than two
> structured fields. I can work around the problem by using functions
> like this:
>
> static inline struct timespec
> get_stat_mtime (struct stat const *st)
> {
> struct timespec t;
> t.tv_sec = st->st_mtime;
> t.tv_nsec = st->st_mtime_nsec;
> return t;
> }
>
> and then use "get_stat_mtime (&st)" all over the place, but this is
> awkward.
>
> I suggest that instead, the fields be described like this:
>
> struct timespec st_atim Time of last access.
> struct timespec st_mtim Time of last data modification.
> struct timespec st_ctim Time of last status change.
>
> This is common existing practice (e.g., Solaris, GNU/Linux) and other
> operating systems typically have a similar solution under different
> names. The existing st_atime etc. fields can overlap the new fields.
> There may be a few older systems that put the timestamp parts in
> wildly separate parts of struct stat for backwards-compatibility
> purposes, but they can be upgraded with the usual linker magic.
I agree. I was concerned about existing system that have the space in
the structure, but permitting them to add the nanosecond fields at other
spots. But in reality, you're right ... everyone has done it this way
anyway, so lets standardize it!
--
Nick Stoughton USENIX Standards Liaison
yyyy@xxxxxxxxxx (510) 388 1413
|