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, rhkra...@gmail.com wrote: > On Tuesday, June 09, 2020 12:30:24 PM Robert Nichols wrote: >> On 6/9/20 9:44 AM, rhkra...@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. >