Re: [rdiff-backup-users] index already covered errors

[Dave Steinberg]

>>>>>> "DS" == Dave Steinberg <address@hidden>
>>>>>> wrote the following on Sun, 8 Jun 2003 01:01:24 -0400
> 
> DS> Error 'Index ('command', 'envdir') already covered, skipping'
> DS> processing command/envdir
> 
> I think the "already covered" error is caused when an rdiff-backup
> increment for the current time is already present in the increments
> directory.  So suppose from your
> dest_dir/rdiff-backup/current_mirror.<time>.snapshot file you see that
> the time is X.  If there is a file like
> 
> dest_dir/rdiff-backup/increments/command/envdir.<X time>.dir
> or
> dest_dir/rdiff-backup/increments/command.<X time>.dir
> 
> then rdiff-backup will skip the file since the increment it wanted to
> write was already there.  (Versions 0.11.x use a different system, but
> from recent messages it seems regressing can also fail..)  So anyway
> please check to see if this is the case?
> 
> It's strange though, becaule generally you should only see that error
> once, because the next time you backup the current_mirror time will be
> different, and then an increment can be written.

It seems that my increments directory (and everything I've looked at below
it) has a timestamp of 1969!  Note, my backup server is OpenBSD/sparc64 and
the clients are mostly OpenBSD/x86... So not only is there endianness going
on but also 64-32 bit-ness.  I'm scared.

Here are some directory listings:

# pwd
/backups/wave.geekisp.com/root/rdiff-backup-data
# ls
<snip>
hardlink_data.2003-05-31T03:30:08-04:00.data.gz
hardlink_data.2003-06-07T03:30:11-04:00.data.gz
hardlink_data.2003-06-14T03:30:08-04:00.data.gz
hardlink_data.2003-06-21T03:30:08-04:00.data.gz
increments
increments.1969-12-31T23:00:00-04:00.dir
session_statistics.2003-03-31T02:55:20-04:00.data
session_statistics.2003-04-27T00:17:05-04:00.data
session_statistics.2003-04-27T09:29:47-04:00.data
</snip>
# cd increments    
# ls -1
altroot
bin
command
command.1969-12-31T23:00:00-04:00.dir
etc
etc.1969-12-31T23:00:00-04:00.dir
mnt
package
package.1969-12-31T23:00:00-04:00.dir
root
root.1969-12-31T23:00:00-04:00.dir
sbin
service
service.1969-12-31T23:00:00-04:00.dir
stand
sys.1969-12-31T23:00:00-04:00.snapshot
# 

Actually, to tell the truth, I don't think there is any problem with
endianness nor 64-32 bitness because I see the same type of information for
this machine when it backs itself up.  That is, I have a /backups directory,
where I plop in the info for each of my machines.  2 are remote, one, the
sparc64, is local.  All exhibit the same behavior.

Ben, if you'd like your account on my machine reactivated, you're welcome to
log in and poke around.  Otherwise I will dutifully reply with whatever
information you (or others) might request.

Thanks for your help,

-- 
Dave Steinberg
http://www.geekisp.com