Skip to content
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

Unable to anchor a file pattern in filter.List(). #834

Closed
middelink opened this issue Mar 2, 2017 · 2 comments
Closed

Unable to anchor a file pattern in filter.List(). #834

middelink opened this issue Mar 2, 2017 · 2 comments

Comments

@middelink
Copy link
Member

I have a daily "-x / /boot" backup from my rp3, it contains (among other files) /bin/uncompress and /bin/gunzip which are hardlinked to eachother. To test if this works I wanted to restore them, so I ran:
$ mkdir z
$ restic -r ... restore --include bin/uncompress --include bin/gunzip -t z
And to my surprise I ended up with
z/bin/gunzip
z/bin/uncompress
z/usr/lib/klibc/bin/gunzip

Prefixing the include with a / wont work as the repo does not seem to contain the root prefix when calling the selectFilter(), so it won't match anything. filter.List also does not seem to have any anchoring characters. Seeing it defines ** to match multiple directories, I would guess the intent was to have Match anchor the pattern at the beginning of the string. E.g. it showing behavior of me having typed --include **/bin/gunzip

Output of restic version

restic 0.4.0 (v0.4.0-76-g4f5e9e9-dirty)
compiled with go1.8 on linux/amd64

Expected behavior

Two files:
z/bin/gunzip
z/bin/uncompress

Actual behavior

Three files appear:
z/bin/gunzip
z/bin/uncompress
z/usr/lib/klibc/bin/gunzip

Steps to reproduce the behavior

have a repository, backed up from / with both say
/bin/fileA
/usr/bin/fileA
$ restic -r ... restore --include bin/fileA -t z
you end up with both files under z/

@fd0
Copy link
Member

fd0 commented Mar 2, 2017

Interesting, thanks for opening this issue. It may indeed be a bug.

@fd0 fd0 added the type: bug label Mar 2, 2017
fd0 added a commit that referenced this issue Mar 2, 2017
Before, the restorer called the filter function with a relative path,
this prevented anchoring absolute patterns (which just never matched).
Now call the restore function with an absolute virtual path, starting at
the filepath separator.

Closes #834
@fd0
Copy link
Member

fd0 commented Mar 2, 2017

Ha, this is actually an old bug that I haven't gotten around to fixing (#374), thanks for reminding me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants