Nick,
I was having problems getting through firewalls from Ottawa to
get at my source. Solaris Release 10's stat struct contains structures
with seconds and nanoseconds underlying the three st_[acm]time fields
with lots of magic to comply with various standards' namespace
requirements. A future Solaris release conforming to the next revision
of the standard can provide st_atime, st_ctime, and st_mtime as fields
of type struct timespec without breaking binary compatibility.
Cheers,
Don
>Date: Fri, 03 Mar 2006 16:12:48 -0800
>From: Nick Stoughton <yyyy@xxxxxxxxxx>
>X-Mailing-List: austin-review-l:archive/latest/2028
>
>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
|