This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug#202243: glibc utimes glitch with coreutils 'touch'


GOTO Masanori <gotom@debian.or.jp> writes:

> "Historically, utimes truncated when it couldn't store the
> microseconds" is BSD's original implementation?

Yes.  I don't know where that phrase in the standard about "rounding"
came from.  Quite possibly it's just a glitch in the standard, and
"truncating" was intended.

Historically, time-related code has always truncated.  For example,
the time() system call, "ls -l", and "date" all truncate.  There are
good reasons for preferring truncation to rounding in timestamps,
despite the greater numeric error.  For example, truncating makes it
easier to answer the question "Was that file modified before
midnight?" when you are looking at lower-resolution timestamps.  And
double-truncation is exact, whereas double-rounding can introduce
extra errors.

When 'utimes()' rounds, it can break applications like 'cp -p' and
'make', because it can cause file timestamps to be in the future
when the timestamps are copied from just-created files.

The current coreutils CVS works around this problem by avoiding
'utimes' if it detects that 'utimes' rounds.  This is unfortunate,
because it disables support for sub-second timestamps in 'cp -p' under
glibc; but at least it doesn't break 'make'.

Please fix this problem by applying the patch in
<http://sources.redhat.com/ml/libc-alpha/2003-08/msg00062.html>.
That will enable coreutils 'cp' to support sub-second timestamps.

Thanks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]