Re: Discussion about file format for the future

[Eric L. Zolf]

Hi,

to close this discussion, I've created an enhancement request #399 but
don't hold your breath, it's not yet on the priority list.

KR, Eric

https://github.com/rdiff-backup/rdiff-backup/issues/399

On 09/06/2020 22:51, rhkramer@gmail.com wrote:
> On Tuesday, June 09, 2020 12:30:24 PM Robert Nichols wrote:
>> On 6/9/20 9:44 AM, rhkramer@gmail.com wrote:
>>> In the case of rdiff-back, it wouldn't surprise me that diffs (deltas)
>>> are stored as forward deltas, and, in removing old deltas, a new "base"
>>> must be created before deleting the deltas.  (My words probably aren't
>>> exactly correct, I hope they are correct enough to explain my point.)
>>
>> That's not how rdiff-backup works. The diffs are _reverse_ diffs, working
>> back from the current state. 
> 
> Ahh, ok, thanks!  (Now I know something about rdiff-back ;-)
> 
>> Any metadata or increments file with a date
>> stamp older than the cutoff date can be simply deleted. I suspect that the
>> problem is the time spent parsing all of the file names in the _huge_
>> increments directory tree and comparing the date code.
>>
>> Speaking the the huge increments tree, a pet peeve of mine is that changes
>> that do not affect file content cause a "zero diff" file to be generated.
>> These can be changes to permissions and ownership, or even just a change
>> to the hard link count. The files are typically compressed empty files,
>> and are not empty themselves (there is at least a gzip header). I run an
>> audit to get rid of most of these at the end of each day, after all
>> clients have completed their backups. The first time I ran it, the count
>> was well into the millions.
>