Holger Parplies wrote at about 17:54:05 +0200 on Thursday, October 6, 2011:
 > Hi,
 > 
 > Tim Fletcher wrote on 2011-10-06 10:17:03 +0100 [Re: [BackupPC-users] Bad 
 > md5sums due to zero size (uncompressed) cpool files - WEIRD BUG]:
 > > On Wed, 2011-10-05 at 21:35 -0400, Jeffrey J. Kosowsky wrote:
 > > > Finally, remember it's possible that many people are having this
 > > > problem but just don't know it,
 > 
 > perfectly possible. I was just saying what possible cause came to my mind 
 > (any
 > many people *could* be running with an almost full disk). As you (Jeffrey)
 > said, the fact that the errors appeared only within a small time frame may or
 > may not be significant. I guess I don't need to ask whether you are *sure*
 > that the disk wasn't almost full back then.

Disk was *less* full then...

 > To be honest, I would *hope* that only you had these issues and everyone
 > else's backups are fine, i.e. that your hardware and not the BackupPC 
 > software
 > was the trigger (though it would probably need some sort of software bug to
 > come up with the exact symptoms).
 > 
 > > > since the only way one would know would be if one actually computed the
 > > > partial file md5sums of all the pool files and/or restored & tested ones
 > > > backups.
 > 
 > Almost.
 > 
 > > > Since the error affects only 71 out of 1.1 million files it's possible
 > > > that no one has ever noticed...
 > 
 > Well, let's think about that for a moment. We *have* had multiple issues that
 > *sounded* like corrupt attrib files. What would happen, if you had an attrib
 > file that decompresses to "" in the reference backup?
 > 
 > > > It would be interesting if other people would run a test on their
 > > > pools to see if they have similar such issues (remember I only tested
 > > > my pool in response to the recent thread of the guy who was having
 > > > issues with his pool)...
 > > 
 > > Do you have a script or series of commands to do this check with?
 > 
 > Actually, what I would propose in response to what you have found would be to
 > test for pool files that decompress to zero length. That should be
 > computationally less expensive than computing hashes - in particular, you can
 > stop decompressing once you have decompressed any content at all.

Actually this could be made even faster since there seem to be 2
cases:
1. Files of length 8 bytes with first byte = 78 [no rsync checksums]
2. Files of length 57 bytes with first byte = d7 [rsync checksums]

So, all you need to do is to stat the size and then test the
first-byte

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/