On 12/21/22 11:04 AM, Patrik Dufresne wrote:
I'm Forwarding your conversation to rdiff-backup mailing list.
From Bob Nichol's answer (yesterday) I understand that restoring a given
version of a file is by a reverse mechanism, that is, rdiff-backup starts
with the latest (most recent) version of a file and then goes backwards
until it finds the desired version.
It might not be totally true. I know rdiff-backup also generates a snapshot
of the files. I don't know exactly the mechanic about those. Possible Eric
Zolf may have more detail about when those snapshot get used in the restore
process.
Indeed, when a file is deleted from the source, in the next rdiff-backup run the
"increment" that gets stored will be a snapshot of the most recent version of the file.
When working backward through the increments during a restore, encountering a snapshot just means,
"Throw away whatever you have built up thus far and use this."
When restoring a file that does not exist in the current mirror, the first
increment encountered (working backward) _must_ be a snapshot, else a fatal
error is flagged and you see a lengthy Python backtrace with an obscure
reference to the cause buried inside. (Don't you just _love_ those backtraces?
Python encourages using backtraces as a principal means of reporting exceptions
to the end user. Personally, I feel that any backtrace presented to the user
should be considered a bug in the code.)
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
