>>>>> On Tue, 7 Oct 2008 07:37:36 +0200, Kern Sibbald said:
>
> On Monday 06 October 2008 22:04:39 Martin Simmons wrote:
> > >>>>> On Mon, 6 Oct 2008 13:05:49 +0200, Kern Sibbald said:
> > >
> > > On Monday 06 October 2008 06:22:51 Troy Daniels wrote:
> > > > Hi,
> > > >
> > > > Not sure if this has been discussed elsewhere (been offline for a week
> > > > or so, so am still catching up on my emails :) )
> > >
> > > Yes.
> > >
> > > > > It is not too late to change the name of the directive, but I would
> > > > > like to see some discussion/input on this. Although I don't have any
> > > > > strong attachment to "Ignore Dir", I think I personally prefer it to
> > > > > "Exclude Flag File", which will be harder for me to remember.
> > > >
> > > > I found 'IgnoreDir' to be non intuitive - Looking at it, it initially
> > > > struck me as an option to specify a directory to ignore rather than to
> > > > specify a file to cause a directory to be ignored. ie, Ignore Dir =
> > > > "SVN" would ignore the directory if *it was called* "SVN" not *if it
> > > > contained* a file/dir with that name.
> > > >
> > > > To make it more clearer, maybe one of the following:
> > > >
> > > > Ignore Dir Containing
> > > > Exclude Dir Containing
> > > > Ignore Dir Holding
> > > > Ignore Dir Holding
> > > >
> > > > Using the Exclude* syntax would keep it in line with current Bacula
> > > > naming conventions as well.
> > >
> > > Thanks for your comments.
> >
> > If it hasn't been done already, it could be useful to consider how this
> > affects the mental model that users have of the include/exclude algorithm
> > (which is already a source of some difficulty). This applies to the
> > fstypes and drivetypes directives as well.
> >
> > There are two things about these directives that make them different from
> > others:
> >
> > 1) The current implementation is within the Options clause, so the config
> > can potentially have more than one per fileset. Is that desirable or does
> > it just over-complicate the issue?
> >
> > 2) The directories are excluded *after* being included in the backup
> > according to the Options matching. In all other cases, an exclude cannot
> > override a matching include.
> >
> > I may be less confusing to put the new directive at the top level of the
> > fileset directive, outside any of the Include or Exclude clauses.
>
> I personally don't find it that confusing, but am willing to admit that some
> would. So, what is the solution?
>
> Drop the feature?
>
> Change the feature?
Putting it outside the Include option and making it truely apply to the whole
fileset would at least make it easier to define what it does.
> If it involves programming, please realize that this is contributed code, and
> so any changes would have to be agreed on by some sort of consensus, and then
> done by someone other than the developers or perhaps by the author.
I think the fileset syntax needs a complete overhaul. The two main problems
are that it tries to do too many things simultaneously (setting options and
well as controlling the tree walk) and also that it defines a flat set of
rules for something that is, by nature, a tree.
__Martin
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
