Re: [rdiff-backup-users] one more bug in rdiff-backup-1.1.16

[Andrew Ferguson]

On Jun 30, 2008, at 11:38 AM, Farkas Levente wrote:

> Andrew Ferguson wrote:
> > On Jun 30, 2008, at 3:01 AM, Farkas Levente wrote:
> > > of course just a after a few minutes later...
> > > so why it takes so long?:
> > > --------------[ Session statistics ]--------------
> > > StartTime 1214746406.00 (Sun Jun 29 15:33:26 2008)
> > > EndTime 1214773343.87 (Sun Jun 29 23:02:23 2008)
> > > ElapsedTime 26937.87 (7 hours 28 minutes 57.87 seconds)
> > > SourceFiles 3
> > > SourceFileSize 0 (0 bytes)
> > > MirrorFiles 85490
> > > MirrorFileSize 87746670098 (81.7 GB)
> > > NewFiles 0
> > > NewFileSize 0 (0 bytes)
> > > DeletedFiles 85487
> > > DeletedFileSize 87746670098 (81.7 GB)
> > > ChangedFiles 3
> > > ChangedSourceSize 0 (0 bytes)
> > > ChangedMirrorSize 0 (0 bytes)
> > > IncrementFiles 85490
> > > IncrementFileSize 57065001065 (53.1 GB)
> > > TotalDestinationSizeChange -30681669033 (-28.6 GB)
> > > Errors 5
> > > --------------------------------------------------
> > > because it's delete all my backups!!!
> > No arguing with that report. It clearly did. :-(
> > I think the fact that it updated every single file is an  
> > interesting clue. That suggests that I look at a part of the code  
> > that I didn't consider before.
>
> but did you see the strange line!:
> SourceFiles 3
> why?
> and as i wrote earlier like mnt/windows/f/proc. there is no such  
> file! so imho rdiff-backup get lost somehow in the filesystem.


Hi,

This bug is fixed in CVS. I was finally able to reproduce it using my  
test systems. The problem hinged on the way the Extended Attributes  
calls were failing.

best,
Andrew