Filesystem-local databases in mlocate

[Axel Thimm]

On Mon, Mar 19, 2007 at 11:51:19PM +0100, Miloslav Trmac wrote:
> Hello,
> Axel Thimm napsal(a):
> >> * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db;
> >>   mlocate also checks each mounted filesystem for a .mlocate/mlocate.db
> >>   file, owned by root or the invoking user, and not writable by anyone
> >>   but the owner.  Such files are automatically added to the database
> >>   path.
> > locate should also include .mlocate/mlocate.db a previous updatedb has
> > found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a
> > folder in its path it skips it and registers it for locate to use.
> This would make a difference only for "subdirectory-local" databases
> within a filesystem.

Exactly.

> I can't think of a reason why they would be necessary.

Consider for example a single volume nfs server exporting /home. So
you want to have updatedb create a subdirectory-local db in /home, so
it can be used on remote clients.

E.g. you can't assume that every exported volume will be identical to
a mounted volume on the server. Every exported dir is subject to
create an .mlocate/mlocate.db which for the server itself looks like
an ordinary subdirectory.

And instead of having to configure it in /etc/sysconfig it is easier
to keep the metainformation of about where such .mlocate/mlocate.db
should be maintained in the fs itself simply by creating the folder
.mlocate.

> > Perhaps that way you can even save the explicit mentioning of
> > --single-fs paths in /etc/sysconfig/mlocate. If a paths is to be
> > handled as such the admin just creates an .mlocate folder and updatedb
> > and locate automatically pick it up.

> I'd prefer a more specific administrator action;  otherwise just
> extracting an archive could unintentionally add a mlocate database and,
> in the worst case, double the updatedb overhead.

You mean an archive that contains .mlocate? That would be an
unfortunate archiving and given that only root can do that it means
the admin did it. Same would apply to quota or backup metainformation
which also doesn't make sense to archive away.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070320/88381af2/attachment.sig>