Here are some issues/questions for the proposed
futimesat/posix_utimesat/utimesat function (under whatever name is
chosen for it). These issues have to do with invalid time stamps,
time stamp precision, and time stamps out of range.
1. What should utimesat do if tv_usec is out of range (i.e., if (! (0
<= tv_usec && tv_usec < 1000000000))? I propose that it shall fail
with errno==EINVAL; this is for consistency with clock_settime. (I
don't know what common practice is.)
2. What should utimesat do when the file system time stamp resolution
is not as good as 1 nanosecond? POSIX isn't clear on this subject,
but I guess it assumes that file time stamp resolution is at least as
good as POSIX time stamp resolution. As a practical matter this is
not the case on some older file systems. Should POSIX continue to
make this assumption (and so we just say "don't use those older file
systems if you want your platform to conform to POSIX")? If so, this
should be written down in the utimesat rationale. If not, then common
practice is for utimes to truncate towards minus infinity (i.e.,
substitute the greatest supported time stamp that is not greater than
the requested time stamp), and I propose that this be put into the
standard for utimesat.
3. What should utimesat do when the file system time stamp range
cannot represent the requested time stamp, due to overflow? E.g.,
suppose time_t is 64 bits but the file system has only a signed 32-bit
quantity, and we try to set the time past 2038 (2**31 seconds after
the epoch). Again, the POSIX tradition is to not worry about these
things, I guess under the assumption that all time stamps are the same
width. If we want to continue doing things this way, it should be
noted in the rationale, and if not, then I propose that utimesat fail
with errno==EOVERFLOW in cases like this. (I don't know what the
common practice is.)
4. If POSIX does not assume that file time stamp resolution equals
struct timespec resolution, then there should be a way for an
application to inquire a file system's time stamp resolution.
Otherwise, for example, applications like 'make' might incorrectly
think that a file is out of date, even though it is as up-to-date as
the file system allows. There is no existing implementation practice
for queries like this, but this lack causes problems in real-world
applications like GNU 'make' and GNU 'cp', which currently deal with
the problem by approximation heuristics. For example, GNU 'cp' infers
the time stamp resolution by inspecting the low order bits of time
stamps of sample files on the destination file system, which obviously
isn't precise in general, and is a bit hairy to boot. (Please see
<http://cvs.sv.gnu.org/viewcvs/gnulib/lib/utimecmp.c?root=gnulib&view=markup>
for why it takes 300 lines of non-thread-safe C code (!) to compare
two file's time stamps efficiently in this situation.)
I propose that we add a flag _PC_TIME_STAMP_RESOLUTION to <unistd.h>,
so that fpathconf and pathconf can be used to query the time stamp
resolution for a file, measured in nanoseconds. This flag is not
existing practice, but it would make it possible to write applications
like 'make' in the presence of different file systems with different
time stamp resolutions.
5. I suppose there could also be a way for an application to query
the file system's time stamp range (e.g., _PC_TIME_STAMP_SECONDS_BITS,
with the results typically being either 32 or 64), though I've never
needed this in an application so I view this as lower priority.
|