[Dump-users] Patch to -C option making corruption more obvious

[Steve B. <fb7...@sn...>]

I've been wrestling with some data corruption from my cheap LSI Logic RAID5
controller (Dell PERC 5/i).  Using "restore -C" has been a great way to
identify which files are mangled so I don't need to run a full restore,
possibly overwriting files that were intentionally changed.  However, it
was fairly difficult to tell from the existing output of "restore" which
files were intentionally changed and which files had been unintentionally
changed.  I was working on a script to review all the changed files and
look for mtime/ctime discrepancies when I realized that there was an even
better way-- the restore program itself could do what I wanted with only a
little tweaking.  (Thank you, Open Source!)

If any of you are interested in this new feature, I've uploaded the patch
to Sourceforge here:

https://sourceforge.net/tracker/?func=detail&aid=3531220&group_id=1306&atid=301306

The only change to default operation is this warning when the file on disk
has changed but has the same mtime as the dump:

fprintf(stderr,"%s: file contents differ but mtime does not.  File may be
corrupted.\n", name);

I added a couple other changes that are only visible when using "-v", these
are:

1) Print an informational description if the file contents differ and so
does the mtime:

Vprintf(stdout, "%s: file contents and mtime both differ.  This was
probably an intentional change. (file: %ld, dump: %ld)\n", name,
sb.st_mtime, timep[1].tv_sec );

2) Change the "comparing %s" line to also print atime/ctime/mtime in case I
want to run an external analysis of the times.  Since this is only printed
when the user has specifically requested verbose output, I didn't see the
harm in making it truly verbose.

Vprintf(stdout, "comparing %s (size: %lld, mode: 0%o, atime: %ld, ctime:
%ld, mtime: %ld)\n", name,
  (long long)sb.st_size, mode, sb.st_atime, sb.st_ctime, sb.st_mtime );

I don't see any harm in adding these features to the mainstream "restore",
but I'd also like for someone to review the patch for bonehead C
programming errors first.  :-)

  -- Steve Bonds