bf_compact

[David Relson]

On Sun, 15 May 2005 16:04:09 +0200
Matthias Andree wrote:

> David Relson <relson at osagesoftware.com> writes:
> 
> >> 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.
> 
> I'm no particular friend of bf_compact, particularly because it is
> nothing innovative (a bogoutil --dump/--load cycle is all it does, only
> a bit more conveniently) but I'm willing to keep it alive.
> 
> I'd say it's also sane to tell the user to cd .. first and then running
> the script with a longer argument.
> 
> > 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.
> 
> We can as well remove the script then.

I was thinking of taking the current script and adding stuff like:

  FIRST_TIME="yes"
  if [ "$FIRST_TIME" -eq "yes" ] ; then
     echo 'Customize to fit your environment'
     echo 'then change FIRST_TIME to "no".'
     exit 1
  fi

With this in _addition_ to the rest of the script, it becomes the user's
responsibility to add whatever else is necessary...

We _could_ delete bf_compact.  If we do that, would the "traditional"
method of compacting (below) work or totally break things?

   cd bogofilter_dir
   bogoutil -d wordlist.db | bogoutil -l wordlist.new
   mv wordlist.db wordlist.save
   mv wordlist.new wordlist.db

> > 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.
> 
> Right.
> I simply hadn't thought of the split system/user configuration file, but
> it's a pretty standard way.
> 
> We should probably review all of our documentation if it's still
> current, if it's complete and polish it before the release. The bf_*
> scripts lack documentation big time.

Go for it.  I'm willing to way a few more hours for updated
documentation (but _no_ code changes) before building and releasing
0.94.12.  Can you finish the job by midnight GMT???

> >> 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.
> 
> Not necessarily, and at least way simpler than guessing around with
> realpath, getcwd and similar warts. The program is quite simple, find a
> copy attached.

Pleasantly simple!  I'm against _any_ last minute code changes, though
documentation changes are fine.  We can add bogo_ustat for 0.94.13

David