Couldn't you handle both cases transparently.  If the pattern has a "/" in
it then pass the full name, otherwise just pass the basename to fnmatch().
That way you get both behaviours without breaking existing examples and
configs.

Ironically the Windows example FileSet in the manual expects the above
behaviour since it has both

        WildFile = "[A-Z]:/WINNT/system32/dhcp/tmp.edb"
And
        WildFile = "*.tmp"



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kern Sibbald
Sent: Monday, April 10, 2006 5:09 AM
To: Martin Simmons
Cc: [EMAIL PROTECTED]; bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-devel] Surprise bug + Scratch pool algorithm

On Monday 10 April 2006 13:15, Martin Simmons wrote:
> >>>>> On Mon, 10 Apr 2006 12:22:59 +0200, Kern Sibbald 
> >>>>> <[EMAIL PROTECTED]>
> >>>>> said:
> >
> > Hello,
> >
> > It seems that it is becoming more frequent (probably because of the 
> > increasing number of Bacula users) that users submit support 
> > questions to the bugs database.  This morning a user submitted a bug 
> > stating that the WildFile option was broken. Normally, I would have 
> > dismissed this as a support problem because most of us realize that 
> > wild-cards and regexes are awfully tricky.
> >
> > However, this user presented a *really* simple case with debug 
> > output, so I took a look at it, and surprise both WildFile and 
> > RegexFile are broken because they match against the full path and 
> > filename rather than just the filename.
> >
> > I wonder how many users have torn out their hair trying to figure 
> > out why WildFile or RegexFile didn't work :-(
>
> Are you really sure that is a bug?  I think the word "filename" in the 
> documentation is ambiguous, but when it says "No directories will be 
> matched by this directive" it does not mean that the matching is 
> performed only on the basename part.
>
> The examples in "A Windows Example FileSet" are also written to assume 
> that WildFile compares the whole name.
>
> The current behaviour is very useful because it allows files in 
> selected directories to be matched, without accidentally matching 
> subdirectories (as Wild will do).
>

After a little more thought about this, I'm not so sure I should change the
behavior. It is not what I had originally intended (I didn't program it),
but to change it now, given all the examples in the doc would create a
number of problems.

I think the best solution is to ensure that the documentation is extremely
clear, then if there is really a demand, implement a new option such as
WildFilename that matches against only the filename (basename).

--
Best regards,

Kern

  (">
  /\
  V_V


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bacula-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/bacula-devel





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to