Re: [rdiff-backup-users] atomic increment files?

[Andrew Ferguson]

On Mar 9, 2009, at 9:21 PM, Marcel (Felix) Giannelia wrote:
> But when you're storing something that you *know* is going to be  
> read-only and will never need to be modified again, then it makes  
> more sense to store a nice index at the front (which is why CD's do  
> that). Aside from unrecommended fiddling, people generally don't  
> modify rdiff-backup's increment files so I think that would be a  
> good application of a nice indexed archive.


Except for --remote-older-than ...


Also, let's consider the case where rdiff-backup fails partway through  
a backup operation, due to say, network-link drop. In the current  
setup, on the next run, rdiff-backup will use each of the written  
increment files to roll-back the repository to how it looked before  
the failed backup operation. It can do this because the increment  
files were written individually and completely (atomicly even!) to  
disk, before changes were made to the repository.

However, with the change you propose, how could rdiff-backup always  
recover? Would the TOC of the increment file be corrupt? Without using  
*file* primitives like rename(), it would be hard to guarantee  
atomicity of the pieces inside the increment file, so how would you do  
that?


Andrew