I finally had time to track this down, and it's not the fault of rdiff-backup.
Somehow (and I have no idea how) I managed to delete _all_ of the empty
directories in the mirror. This goes undetected until one of those empty
directories is deleted in the source. That causes the next backup
Right now I have a repeatable test case that I'm trying to trim down to
something that does not involve 20GB of data.
I'm doing the testing and seeing the failure with a local filesystem copy on
the 2.1.3b3 server -- no remote access involved.
--
Bob Nichols "NOSPAM" is really part of my
OK, I'll do that. Unfortunately, the problem is not 100% repeatable. After
reverting the archive to the previous state (it had verified OK prior to this
failing session), a re-run of this same backup completed successfully. This
isn't the first time I've encountered this error, and it seems
Hi Robert,
could be a regression indeed. Do you mind creating an issue with the
exact call you used?
Thanks, Eric
PS: Fedora, good distro choice :-)
On 29/10/2022 17:28, Robert Nichols wrote:
Can someone please make sense of this traceback from a rdiff-backup
2.0.5 client backing up to a
