This is the mail archive of the
overseers@sourceware.org
mailing list for the Sourceware project.
Re: ongoing sourceware.org recovery from disk corruption
On Tue, 15 Aug 2017, Joseph Myers wrote:
> Suggested general comparison methodology (for the whole backup against
> live data, not just areas we know to be broken, and with due disregard of
> any areas we are confident have been safely fixed now - and of course any
> areas of old files that shouldn't change at all can just be restored with
> rsync -c without such comparisons needed):
>
> * If the file contents have changed but the timestamp hasn't, it's almost
> certainly corruption (especially if the changes involve blocks of NUL
> bytes) and restoring the old version makes sense.
To be clear: by timestamp I'm referring to the *seconds* part of the
timestamp, not the nanoseconds (whereas e.g. Python stat returns float
values for timestamps including nanoseconds by default). Whatever
comparison is used needs to compare seconds only. E.g., for one case of a
corrupted file I noticed updating an old src checkout:
-r--r--r--. 1 corinna src 106630 2015-01-14 09:56:02.000000000 +0000 /sourceware2/projects/src-home/cvsfiles/src/libgloss/or1k/include/or1k-sprs.h,v
-r--r--r--. 1 corinna src 106630 2015-01-14 09:56:02.398317319 +0000 /sourceware/projects/src-home/cvsfiles/src/libgloss/or1k/include/or1k-sprs.h,v
(apparently the /sourceware2 backup process didn't preserve nanoseconds; I
think rsync may not support them).
--
Joseph S. Myers
joseph@codesourcery.com