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'.
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.
> 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.
|