Re: [rdiff-backup-users] Suggestion for documentation change

[Andrew Ferguson]

dean gaudet wrote:
> On Sat, 18 Nov 2006, Andrew Ferguson wrote:
> 
>> dean gaudet wrote:
>> > sounds like the bug is that rdiff-backup decides there's a metadata change 
>> > and stores an almost-empty .diff.gz file even though it's not required.  
>> > even though the metadata change is innocuous...
>> 
>> I think there could be a reason for the almost-empty .diff.gz file, but
>> it depends on whether we view metadata changes as true changes to a
>> file. That is, do we truly want to see that a file 'changed' at a
>> specific backup time, or do we just want that implicit in the metadata?
>> 
>> This is connected to the fact that you can do restores with rdiff-backup
>> of the form:
>> 
>> rdiff-backup
>> /backup/rdiff-backup-data/increments/path/to/file.<time>.diff.gz
>> /path/to/file
>> 
>> If we stop creating the .diff.gz files for metadata-only changes, we
>> break this behavior for the case when you want to restore on one side or
>> the the other of a metadata-only change.
>> 
>> Does this make sense?
> 
> yep -- but we could store an actual 0-length file instead... so we're not 
> wasting an entire disk block on many filesystems.  better to name it 
> .nodiff or something else so we can distinguish between an incompletely 
> written .diff.gz and a file with no differences.

Examining the .diff that gets written, it consists of only a few bytes:
- the magic number
- a copy command
- the byte to start the copy from (0)
- the length of the copy (here, equal to the length of the file)
- null byte end code

So, either rdiff-backup can check for .diff files of this type, or we
can change how it checks for file differences that trigger calls to the
rsync lib. Dean, any thoughts on this one?

Andrew

-- 
Andrew Ferguson - address@hidden