Bug 66911 - btrfs-progs: btrfs-restore: an option to exclude paths by a pattern
Summary: btrfs-progs: btrfs-restore: an option to exclude paths by a pattern
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: btrfs (show other bugs)
Hardware: All Linux
: P1 enhancement
Assignee: Josef Bacik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-12 08:48 UTC by Ivan Zakharyaschev
Modified: 2022-10-03 13:28 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.12
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Ivan Zakharyaschev 2013-12-12 08:48:08 UTC
(I've also described this wish at https://btrfs.wiki.kernel.org/index.php/Talk:Restore#How_to_exclude_some_paths_matching_a_pattern .)

I'm thinking how to exclude paths like .Trash from restoring with a regex.

Reading the commit https://github.com/josefbacik/btrfs-progs/commit/2f0c2a29ab13b17ae1cc21effcf532f2447b7c8c introducing this feature to find out the regex syntax used in this feature, and its possibilities... it must be the regex syntax from <regex.h>, with flags: REG_EXTENDED | REG_NOSUB | REG_NEWLINE.

So, POSIX Extended Regular Expressions are used here... -- http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions

The simplest solution must be to patch the C code to implement an option like grep's -v (or --invert-match): "Invert the sense of matching, to select non-matching lines." (But "-v" has already been taken as an option of btrfs-restore...) Combining inclusion and exclusion patterns is more complex; which one should take precedence is not a clear thing; ideally, a language like that of "find" should be implemented for matching, but that's too much work. (As for me personally, I'm simply interested in excluding trash directories, and that's achievable with the simplest inversion option.)


Another convenient way to selectively try to restore files can be to interactively ask the user for each new upcoming path: whether to try to restore it, or skip, or add another inclusion or exclusion pattern effective for all future paths (so that no question is asked if the path matches one of the patterns).

Note You need to log in before you can comment on or make changes to this bug.