Hi,

Jeffrey J. Kosowsky wrote on 2011-10-07 01:08:03 -0400 [Re: [BackupPC-users] 
Bad md5sums due to zero size (uncompressed) cpool files - WEIRD BUG]:
> Holger Parplies wrote at about 05:46:36 +0200 on Friday, October 7, 2011:
>  > 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]:
>  > > [...]
>  > > Why would PoolWrite.pm change the mod time of a pool file that is not
>  > > in the actual backup?

ok, so by now we seem to have concluded that Xfer::Rsync *might* modify a file
in a previous backup. Without looking at the code, it's just speculation, and
I haven't currently got the time, considering the code is quite complex.

After some reflection, it *does* make sense to add checksums to a file in a
previous backup, even if the file is found to have changed in the current
backup, because the *previous* backup may still be the reference for a future
backup (also, the pool file might be reused).

>  > Also: can you give a better resolution on the mod times, i.e. which one is
>  > older?
> 
> OK...
> #82: Modify: 2011-04-27 03:05:04.551226502 -0400
> #110: Modify: 2011-04-27 03:05:19.813321479 -040
> 
> So #110 was modified 15 seconds after #82. Hmmm

Strange time zone on #110 ;-).
15 seconds seems to be *ages*, considering we're talking about small files
(right?). I agree with you: Hmmm.

> Note both of those files have rsync checksums.
> 
> When I looked at a couple of files without the rsync checksums, the
> mod times differed by a day.

Meaning they corresponded to the backup times?

> As an aside, I noticed that when I looked at version without the rsync
> checksum, that the corrected version also doesn't have an rsync
> checksum even after having being backed up many times subsequently --
> Now I thought that the rsync checksum should be added after the 2nd or
> 3rd time the file is read... This makes me wonder whether there is
> potentially an issue with the rsync checksum...

I had thought the same (2nd backup - for the 3rd they should be present and
give a speedup). This is another thing we could check - which files in our
backups have checksum caches. What makes *me* wonder is that this still only
seems to happen to you.

>  > > 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.

Or, put differently: no.

If the file *has* rsync checksums, they wouldn't have been added on the first
backup. mtime says they were added by #110, thus the file would have been in
the pool without checksums then. Or would it have been the *reference file* at
the time checksums were added!?

> And we know BackupPC *thinks* it's a new file since it creates a new
> pool file chain member. But what and why did the original file get
> clobbered just before the then?

No, we don't really know what the situation was then. We're trying to
reconstruct it from evidence, which we are having a hard time interpreting
(at least I am).

>  > > 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?
> 
> But what would cause it to truncate the data portion?

Use the force, read the source. I don't think it's *meant* to clobber the data
portion.

> Maybe it's something with rsync checksum caching/seeding when it tries
> to add a checksum?

There does seem to be a connection, though there are those 8-byte files
*without* checksum cache. Are these failed attempts of some sort, or are they
- like you first said - an indication that it's *not* checksum caching?

> I'm just guessing here...

So am I.

Regards,
Holger

------------------------------------------------------------------------------
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/