On 20 January 2015 at 22:15, Colin Percival <[email protected]> wrote: > > If you run -tv, do you see different timestamps on the files? Your > process of > copying data around sounds like it would have changed the file modification > times, which would result in entirely new tar archive headers. 8.8 MB is > around 17000 tar headers; is that how many files you have? >
Thanks for the analysis Colin. I had a backup of this archive from Jan 16 before I had the filesystem corruption and I just created a new archive (today, Jan 21.) I've done a diff of the "-t -v" output between the two archives. >From looking at the first character of the output, there are ~278330 files, 63887 directories, 2637 symbolic links, 22 links, and 4 named pipes in each archive. The latter contains a few extra emails (~80kb) over the former, hence the "~278330". I had to write a script to process the output in order to be able to do a diff. In the archive from Jan 16, according to the "-t -v" output, most files have a link count of 1, but those same files in the Jan 21 archive have a link count of 0. Everything else -- mode, owner, group, size and mtime -- is identical in the two listings. The files on the drive itself are readable and have a link count of 1 when I do an "ls -l" in OS X, with the drive mounted, and I can also restore files from the Jan 21 tarsnap archive without error. When I did the original data restore from the broken drive I used "rsync -aHv" to copy data off the read-only FS, and "rsync -aHv" to copy it back to the newly reformatted drive, so perhaps that accounts for the 8.8MB snapshot size? Can you think of another reason why the Jan 21 files have a zero link count? It's also fine if you don't -- at this stage I'm happy that my data is safe, and hasn't been corrupted! Thanks! <3 tarsnap! Ed
