Re: [PATCH] Apply pattern-matching immediately beneath the stow directory.

[Sergiu Ivanov]

Hello,

On Mon, Sep 07, 2009 at 02:33:30AM +0200, olafBuddenhagen@gmx.net wrote:
> On Mon, Aug 31, 2009 at 11:32:12PM +0300, Sergiu Ivanov wrote:
> 
> > This patch makes unionfs try the pattern against the directories
> > immediately beneath stow/ , instead of doing it in the original way.
> > 
> > Please note, however, that "*/bin" will not work anyways, because
> > unionfs checks the patterns only against the first-level
> > subdirectories of stow/ .
> 
> This is not acceptable.
> 
> If you change the behaviour in such a way that the main use case -- and
> probably the only relevant one at that -- doesn't work anymore, you
> could just as well rip it out alltogether...

Well, I'm still not really aware what the *main* use case is.
Gianluca said something about the GNU Package Manager, but I didn't
fully understand whether this use-case is still in focus or not.
 
> > To make this pattern work, unionfs would have to traverse all
> > subdirectories of stow/ , interpreting the pattern in a smart way and
> > consuming much more time than it does now.
> 
> Well, not knowing how this stuff is handled, I can't tell: is it really
> not possible to implement proper wildcard matching of more than the
> first component efficiently? It's hard to imagine why an explicit '*'
> should be so much more troublesome than the implied one in the original
> implementation...

unionfs needs to explicitly enumerate the contents of a directory to
do pattern matching in it.  I cannot envision a way to do
multi-component pattern matching without iterating all subdirectories
of stow/ .  Well, okay, there could be done some optimization (like
counting the number of components in the pattern and not going deeper
than that), but it does not change the concept considerably.

BTW, the implied asterisk in the original implementation is achieved
by explicitly going down to the second level under stow/ , i.e. it is
hard-coded in the algorithm, not some patterns, filenames or anything
else.  Since this implementation didn't care about multi-component
pattern, I chose not to think of them either.

Do you have some general idea of how multi-component pattern matching
could be implemented more efficiently than that?  Some vague pointer
should suffice for me to adapt the idea to unionfs.

Regards,
scolobb