On Thu, 27 Jul 2006, Bernd Ernesti wrote:

> On Wed, Jul 26, 2006 at 09:49:07PM -0400, Perry E. Metzger wrote:
> >
> > Daniel Carosone <dan@geek.com.au> writes:
> > > On Wed, Jul 26, 2006 at 09:39:54PM -0400, Perry E. Metzger wrote:
> > >> > Fits /var/db pretty well, if that's really the case.
> > >>
> > >> If it configures the kernel and survives reboots I'm not sure that it
> > >> should be in /var/db except for a few trivial things like ntp.drift
> > >> which really is not per se configuration.
> > >
> > > Then neither should dhclient.leases, which is a closely analogous
> > > construct.
> >
> > The leases file is ephimeral data -- it isn't the result of user
> > editing and it can be blown away without any real issue. Same with the
> > ntp.drift file. If the bluetooth xml file is something that can't be
> > blown away at will, it isn't really something for the db
> > dir. Otherwise it might be.
>
> Or it should be splited into two files, the one in /var/db and a second
> one which overwrittes the configuration in /etc

I'm fairly easy as to the location, though I dont really consider XML
to be humanly readable so I left it out of /etc.

If the file is deleted nothing will change, but next time you reboot, your
bluetooth devices will not be attached and you would have to reconfigure
them. It is not necessary to user edit the entries since the information
comes from the remote device and its not that difficult to get it.

Similarly so with the bthcid.keys file actually - the keys file is created
and maintained by bthcid and should require no user intervention, but it
if its lost then your connections will fail and some user will have to
enter a PIN to authorize a new key.

Is all of /var considered ephemeral or is it just /var/db?  In reality how
likely is it that this will be lost? (do people use mfs for /var?)

iain