Sergey Poznyakoff wrote:
Matthew Woehlke wrote:
...any news here? I'm not anxious to upgrade tar when it fails half of
its test suite.
Yes, there are. Of 28 failed tests 18 failed because time stamps on your
NFS mounted directory are out of sync with the machine where the test
was run. In this case tar issues these warning messages on its stderror:
tar: directory/file: time stamp 2007-03-07 09:57:12 is 157.337963 s in the
future
tar: directory: time stamp 2007-03-07 09:57:12 is 157.337416 s in the future
which the testsuite does not expect to see.
Sigh. Ok, my NFS server recently decided to start drifting, so having
matching timestamps is currently impossible (I've already requested
several times to get NTP running on our machines :-(). I do NOT want to
trust running the tests on not-NFS because most use of tar will be on
NFS volumes; I want to know that tar works in these cases. Is it
possible to make the tests more robust against this sort of failure? (Is
it even a failure, or just a warning? If the latter, it shouldn't be
causing the test to fail...)
Anyway, thanks for the reply (and sorry for the delay in responding).
The tests related to incremental backups (9 tests) and fail due to the same
reason (each created file becomes `new' or `changed' for the next tar run).
That's interesting... can you explain more specifically what is going
on? Offhand it sounds like this should be proof against the file system
clock being out of sync; where is the system clock (as opposed to the
file times) being used?
--
Matthew
<insert bad pun... on second thought, better not>
