bf_compact

[David Relson]

On Sun, 15 May 2005 14:59:44 +0200
Matthias Andree wrote:

> David Relson <relson at osagesoftware.com> writes:
> 
> > On Sat, 14 May 2005 22:57:11 +0100
> > R Kimber wrote:
> >
> >> On Sat, 14 May 2005 20:18:54 +0200
> >> Matthias Andree <matthias.andree at gmx.de> wrote:
> >> 
> >> > > Yes.  Thanks.  I wasn't offended - just that I used it as advertised
> >> > > and my wordlist and config files disappeared.
> >> > 
> >> > If your *wordlist* disappeared, then that is a genuine bug that needs
> >> > to be fixed - in that case, have my apologies for mis-reading your
> >> > previous mail. Configuration files in .bogofilter? DB_CONFIG perhaps,
> >> > we are copying that if present, but no other configuration files
> >> > should be in that directory, no?
> >> 
> >> /etc/bogofilter.cf suggests one can have:-
> >> user_config_file=~/.bogofilter/config
> >> which is what I had.
> >
> > Good point.  bogofilter.cf definitely mentions putting the config file
> > in ~/.bogofilter.  One solution would be to add lines like the
> > following to bf_compact:
> >
> >    FILES=`ls $BOGOHOME/* | egrep -v "$BOGOHOME/(log.0|__db.|lockfile.)"`
> >    cp -p $FILES $TEMP
> 
> I'd think this is much too broad. We want to leave everything behind.

My thought is that we want to preserve everything except transaction
specific files, i.e. __db.00x, lockfile.?, and log.xxxxx, because the
transaction specific files will be recreated after the wordlist(s) are
rebuilt.  What are you thinking of that I am missing?


> We could use bogofilter -QQ however and look for the user_config_file
> and copy it if it's part of that directory.

Additional complexity :-<  When we first realized the need for scripts
like bf_compact, I expected them to be short and simple.  We seem to be
heading in the direction of a large, complex, monstrosity.

Perhaps the script we distribute should (on its first run) say "This
script is a template that must be modified to fit the needs of your
environment." and should then exit.  The user then makes whatever
changes he/she deems appropriate (including disabling the message and
exit statement) and is then ready to go.  An approach like that means
we developers don't have to anticipate all the possibilities.

> To that extent, and generally to check if two *existing* directories (or
> otherwise inodes) are identical, we can stat() them and compare st_dev
> and st_ino. Unfortunately, there is no standard utility that provides
> these two figures, while ls(1) can provide st_ino, the "file serial
> number", I know no way to determine st_dev. We'll have to write our
> own. st_ino and st_dev are mandatory per POSIX.
> 
> Such code in a separate utility does not require much code. I'm hacking
> such a beast now.

More complexity :-<  Ick.

David