On Tue, Mar 20, 2007 at 12:50:26AM +0100, Miloslav Trmac wrote: > Axel Thimm napsal(a): > > 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. > >> 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. > But on the client, where locate runs, /home/foo would be a separate > filesystem. Yes, but updatedb (and locate) runs also on the server. > As for updatedb, > > 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. > wouldn't it be even more practical to support > FS_DB_GLOB=/srv/home/* > in /etc/sysconfig/mlocate ? It's better not to have any knowledge under /etc of where special .mlocate/mlocate.db are injected on the (local) filesystem. Consider the (local) volume in question to be mounted from a SAN device, maybe even in a cluster active/passive setup. Or consider moving a data disk from one system to another. It's better to try and keep the metainformation non-global (e.g. out of /etc) and self-describing, so it is rather transparent for the admin. Otherwise he needs to cater for any change of host <-> storage mapping in mlocate as well. -- Axel.Thimm at ATrpms.net
Attachment:
pgpqtJfv4cSUb.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list