Hi,

Jeffrey J. Kosowsky wrote on 2011-10-06 22:54:44 -0400 [Re: [BackupPC-users] 
Bad md5sums due to zero size (uncompressed) cpool?files - WEIRD BUG]:
> OK... this is a little weird maybe...
> [...]
> On all (saved) backups, up to backup 82, the file (and the
> corresponding cpool file e/f/0/ef0bd9db744f651b9640ea170b07225a) is
> zero length decompressed.
> 
> My next saved backup is #110 which is non-zero length and has the
> correct contents. This is true for all subsequent saved backups.
> [...]
> BUT WHAT IS INTERESTING is that both pool files have the same
> modification time of: 2011-04-27 03:05
> which according to the logs is during the time at which backup #110
> was backing up the relevant share.

you'll hate me asking this, but: do any of your repair scripts touch the
modification time?

Also: can you give a better resolution on the mod times, i.e. which one is
older?

> Why would PoolWrite.pm change the mod time of a pool file that is not
> in the actual backup?

PoolWrite normally wouldn't, unless something is going wrong somewhere (and it
probably wouldn't use utime() but rather open the file for writing).

This is an rsync backup, right?

> Could it be that this backup somehow destroyed the data in the file?
> (but even so, what would cause this to happen)

Hmm, let's see ... a bug?

> Also, the XferLOG entry for both backups #82 and #110 have the line:
>  pool     644       0/0         252 
> usr/share/FlightGear/Timezone/America/Port-au-Prince
> 
> But this doesn't make sense since if the new pool file was created as
> part of backup #110, shouldn't it say 'create' and not 'pool'?

Considering the mtime, yes. If it's rsync, an *identical* file should be
'same', if it's tar, an identical file would be 'pool'. Could this be an
indication that it wasn't BackupPC that clobbered the file?

> None of this makes sense to me but somehow I suspect that herein may be a
> clue to the problem...

Xfer::Rsync opening the reference file?

So far, *none* of my 1.1 million pool files (875000 checked so far) seem to be
empty. I'm using a different BackupPC version (2.1.2), but others seem to be
checking their pools, too. I'd still like to know whether this has happened
*anywhere* else, and if yes, what those BackupPC setups have in common with
yours.

Regards,
Holger

P.S.: If anyone wants a copy of the "quick" pool check - I've named it
      BackupPC_jeffrey for lack of a better idea - please ask. It's mainly
      a modified copy of BackupPC_verifyPool, hacked together in a few
      minutes. I *have* used "open FILE, '<', ...", so I'm fairly sure I'm
      not clobbering all 57-byte-files in the pool, but I can't say I did
      much testing, and I was already tired when writing it, so you might
      prefer to wait a day ;-). I might even add IO::Dirent support ...

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
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/