On Monday 17 April 2006 16:12, Robert Nelson wrote: > It seems from this discussion the manual needs changing anyways. > > FNM_FILE_NAME is GNU specific, posix uses FNM_PATHNAME, behaviour is the > same. I just used FNM_FILE_NAME because that is what you already use in > some places in the source. So I don't believe there is any portability > issue, particularly since you have a copy of that routine in the source and > aren't using the platform version anyhow.
As far as I know, FNM_FILE_NAME is not used in Bacula source. It is indeed in fnmatch.h and fnmatch.c, but neither of those routines are used by any Bacula code unless fnmatch doesn't exist in the host machine libraries, which to the best of my knowledge is never the case. If Bacula code were to use FNM_FILE_NAME, in the source, there would be some platform (e.g. Solaris) where the compile would fail. > > I offered to put this and the other changes I've suggested under an option > like EnhancedWild or AlternateWild, but it doesn't seem you are open to any > suggestions so I'll just fix my version and not bother you with any more > suggestions. I missed the above suggestion. I am not and have noot been opposed to someone adding an additional directive, though, I think the exact name should be openly discussed on the list ... > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kern Sibbald > Sent: Monday, April 17, 2006 5:41 AM > To: Robert Nelson > Cc: 'Martin Simmons'; [EMAIL PROTECTED]; > bacula-users@lists.sourceforge.net > Subject: [Bacula-devel] fnmatch > > Hello, > > I'm sorry, I'm not interested in changing how WildFile currently works. I > thought about it a long time, and IMO changing it would create lots of > problems with current users, not to mention require changing the manual. > > In addition, I am not interested in FNM_FILE_NAME, because unless POSIX has > added something new, it is a GNU extention, which means it is not portable. > > I consider this a non-problem and have already provided a resonable > solution for the few users who really care. > > On Monday 17 April 2006 10:21, Robert Nelson wrote: > > At first I was somewhat confused about what the current behaviour is, > > both by this thread, the documentation and my experience with file > > matching algorithms used by other programs such as the various shells. > > > > Judging from your example below I believe you may be confused about > > the current behaviour as well. > > > > The current code allows "*" to match any character INCLUDING the "/". > > > > This means, given the pattern "*kern", and using WildFile, the > > following files would match: > > > > /xxx/kern > > /xxx/abc_kern > > /xxx/yyy/kern > > > > But the following would not unless an asterisk is added to the end of > > the pattern or WildDir or Wild was used. > > > > /xxx/kern/yyy > > /xxx/abc_kern/yyy > > > > If you wanted "*kern" to match as part of the path or as a file then > > you would have to use Wild rather than WildFile. This will be matched > > when that directory is processed as the tree is descended. > > > > Perhaps most worrisome of all is that the following would match the > > pattern "/test*.dat" > > > > /test/archive/important/file1.dat > > > > Or given the pattern "/xxx/yyy/*.c" the following would match > > > > /xxx/yyy/abc.c > > /xxx/yyy/backup_copy/abc.c > > > > This is how the code works today. I think these last two cases are > > counter-intuitive and likely to cause someone problems at some point. > > Off the top of my head, I can't think of a case where it would be > > desirable behaviour. > > > > With this understanding of the current behaviour I believe it is > > important to make FNM_FILE_NAME work properly and specify it. This > > would just require adding one missing check for a "/" in fnmatch() > > when FNM_FILE_NAME is set. There isn't much difference in the current > > code when this flag is specified. It certainly doesn't behave the way > > it is documented in GNU or POSIX. > > > > However fixing this "bug" would mean that the pattern "*.tmp" would no > > longer match anything since absolute paths are always supplied. Thus > > the origins of my original suggestion. While you could add a new > > keyword for matching against just the base name you would either have > > to not fix the above behaviour or break existing configurations. > > > > As far as the code example is concerned I wouldn't implement it that > > way in production code either. I just included it to illustrate what > > I was suggesting using the minimum changes required. In production > > code I would only scan the filename and patterns once. > > > > While you could use regex the patterns would be much more complicated > > and harder for the average user, who is familiar with using the shell, > > to understand. There is a reason why programs that deal with just > > filenames use the glob(7) and fnmatch(3) patterns. > > > > I think the reason that only one user has mentioned it in the last 5 > > years is due to a few factors, > > > > the code mostly works as expected, > > > > I believe that Wild patterns are primarily used for exclusions and > > most users don't examine which files are being excluded until they > > aren't there when you try to restore. > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Kern > > Sibbald > > Sent: Sunday, April 16, 2006 10:19 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 11:52, Robert Nelson wrote: > > > 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: > > > > Well, I am sorry, but I don't agree with you on the point of it being > > very intuitive. With your change, I would no longer be able to do > > something based on a part of the path -- for example, suppose I want > > to compress all files where any part of the path has kern in the name. > > I can do it with > > > > WildFile = "*kern" > > > > With your suggestion, that would only match the filename part and > > would never match against something in the path. > > > > In addition, if I did implement it, I wouldn't do it as in the code > > below because that code has a huge performance penalty especially if > > you are dealing with 3 million files. I leave it to you to work out why. > > > > After a good deal of thought, IMO the correct way to solve the problem > > is with regex, or possibly if it is really necessary with another > > directive that explicitly lets the user match against only the > > filename part rather than the full path, but I don't think a new > > directive will really be necessary since no one has asked for it in > > the 5 years it has been programmed. > > > > > } 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= > > > > 12 > > > > 16 > > > > 42 _______________________________________________ > > > > Bacula-devel mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > > > -- > > > Best regards, > > > > > > Kern > > > > > > ("> > > > /\ > > > V_V > > > > -- > > 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-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
