An easier-to-use interface for btrfs-restore?

[Alex Elsayed <eternaleye+usenet@gmail.com>]

In using btrfs-restore, I've found that much of the time the interface is a 
poor match for what I'm trying to do. It works fine in the simplest cases 
where you want to extract everything, but wanting to extract a subset of the 
files in a directory is more difficult, and it gets more complicated from 
there.

My solutions was to hack up (not very well) a btrfs-list-files program, feed 
it to a Perl script to pick out the files I wanted and turn them into 
(sanitized) regexes, and feed the results to btrfs-restore in a loop.

I think that, while my implementation of this was subpar, the idea deserves 
wider consideration.

The idea is to split the restore utility into two components:

A 'find'-style listing utility
    Supports various matching operations such as -name, -regex, etc.
    Supports -print and -print0
    Does not support -exec, -execdir, -delete, etc.

An extraction tool
    Accepts a list of files in argv[] or on STDIN
        STDIN supports both newline- and null-terminated operation
    Does simple string matching
    Extracts the named files

Benefits:
    Simplicity:
        The find utility only needs to care about walking dentries and 
matching patterns
        The extraction utility just needs to compare strings and extract 
data on success
    Usability:
        Find has a reasonably well-known and well-understood interface
        A simple extractor you just feed a list of files and directories to 
is easier to grok for a new user.
        Eliminate the annoying way the current interface requires splitting 
up the path components of files into alternations
    Efficiency:
        The extractor can build up a trie of files to be matched
        A near-arbitrary-size list of files can be extracted in two passes 
(find names, extract files) without undue complexity, negating the need to 
either build truly horrendous regexes or extract in a loop and take the 
performance hit.