But I think the behaviour would be very intuitive. If you look at how it is
used below in the example from the Windows FileSet I think it is fairly
obvious. I also think it is much clearer and easier to maintain than the
corresponding regex would be. The code change was minimal and didn't
require any modification of the buffers themselves. Here is the diff for
WildFile:
} else {
for (k=0; k<fo->wildfile.size(); k++) {
- if (fnmatch((char *)fo->wildfile.get(k), ff->fname, fnmode|ic)
== 0) {
+ const char *pattern = (const char *)fo->wildfile.get(k);
+ const char *fname;
+
+ if (strchr(pattern, '/') != NULL || (fname = strrchr(ff->fname,
'/')) == NULL)
+ fname = ff->fname;
+ else
+ fname++;
+
+ if (fnmatch(pattern, fname, fnmode|ic) == 0) {
if (ff->flags & FO_EXCLUDE) {
-----Original Message-----
From: Kern Sibbald [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 16, 2006 1:18 AM
To: Robert Nelson
Cc: 'Martin Simmons'; [EMAIL PROTECTED];
bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-devel] Surprise bug + Scratch pool algorithm
On Sunday 16 April 2006 00:21, Robert Nelson wrote:
> 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"
That is an interesting idea, but probably not something I would do, because
it makes matching more complicated by altering the input data (filenames)
depending on the pattern.
Tar has a similar feature, and I doubt that many on this list know about it
or that anyone on this list can explain exactly how it works.
Since wild-cards are terribly incomplete, the solution to the limitations
users will have with wild-cards is to use Bacula's regular expressions,
which are now implemented (experimentally) in Win32 in version 1.38.8. The
only problem with the Win32 regex is that it is untested and it does not
have an "ignore case", which I will probably add in a future version.
>
>
>
> -----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=1216
> 42 _______________________________________________
> Bacula-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
--
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-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
