-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] restoring a subdirectory doesn't play well with include/exclude filters #463
Comments
Yeah, I'm not exactly happy about how exclude/include is implemented currently, because either I'm too stupid or it's too complex to oversee, so either I need to become smarter or the code needs to be simplified, so that I can fix properly such issues (it's not the first of the same kind), but it'll take a bit of time until I'll come to this. Thanks for the reproducer, it's always very helpful, and a good basis for a new test case. |
OK, looking into it, it's due to some sub-directory effect. The first restore command does not fail whereas the 2nd one does fail (and neither does the 3rd option fail).
Note that replacing |
I'm still not completely through with my analysis but basically the filtering is applied while recovering to both the source and the target, and the source filtering goes wrong because it mixes file index relative to the base directory of the repo (e.g. The removal of I need now to find a way to make the selection "more relative" without breaking other use cases... |
I've tried to fix this issue but it creates issues throughout the whole code, and would introduce the need for some behavior changes which I can't justify right now (see unfinished branch ericzolf-fix-restore-sub-cludes-463). I let it sink for now, but I might just close this issue with a new "known issues" document, with a documented workaround. |
DEV: get rid of unused RepoShadow.update_quoting function DEV: introduce properly reference path, index, inc and type (partially renamed from restore_....) FIX: restoring from sub-path while selecting is now forbidden to avoid data loss, workaround documented in FAQ, closes #463
DEV: get rid of unused RepoShadow.update_quoting function DEV: introduce properly reference path, index, inc and type (partially renamed from restore_....) FIX: restoring from sub-path while selecting is now forbidden to avoid data loss, workaround documented in FAQ, closes #463
DEV: get rid of unused RepoShadow.update_quoting function DEV: introduce properly reference path, index, inc and type (partially renamed from restore_....) FIX: restoring from sub-path while selecting is now forbidden to avoid data loss, workaround documented in FAQ, closes #463
DEV: get rid of unused RepoShadow.update_quoting function DEV: introduce properly reference path, index, inc and type (partially renamed from restore_....) FIX: restoring from sub-path while selecting is now forbidden to avoid data loss, workaround documented in FAQ, closes #463
Bug summary
rdiff-backup crashes due to a Python OSError exception while trying to restore a subdirectory if I specify include/exclude filters, and the files I'm trying to restore are completely gone from the destination directory.
Version, Python, Operating System
rdiff-backup 2.0.5, Python 3.8.5, Fedora 32
Call
rdiff-backup -v9
and paste the output between the backquotes below, repeat for each environment impacted:rdiff-backup call
I have a fully reproducible test case. First, let's create a few files and directories to play with:
Create our first backup in the empty backup directory, then overwrite a file with garbage and :
We can now try to selectively restore dir1:
What happened and what did you expect?
I expected
rdiff-backup
to restore thedir1/file1.txt
instead of crashing. Even worse,dir1/file2.txt
disappeared completely after the crash, but it can fortunately still be recovered from the backup directory:More information
Here's the
-v9
output:rdiff-backup.log
Possible workarounds:
rdiff-backup -r now --force backup/dir1 original/dir1
rdiff-backup -r now --force --include 'original/dir1/file2.txt' --exclude '**' backup original
rsync -a --include 'file2.txt' --exclude '**' backup/dir1/ original/dir1
The test case might seem contrived, since
rdiff-backup backup/dir1/file1.txt original/dir1/file1.txt
is easier, but I discovered this usingrdiff-backup
with a globbing filelist to restore several file in the/root
directory - it was a bit scary to see it tried to remove the/root
directory, running with root privileges.I've been using rdiff-backup since at least 2009, many thanks for reviving the project!
The text was updated successfully, but these errors were encountered: