bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: findutils -- feature request for database with relative pathnames


From: Peter Breitenlohner
Subject: Re: findutils -- feature request for database with relative pathnames
Date: Tue, 9 Sep 2008 10:03:58 +0200 (CEST)
User-agent: Alpine 1.10 (LNX 962 2008-03-14)

On Sat, 6 Sep 2008, Miloslav Trma? wrote:

Peter Breitenlohner pí?e v Pá 05. 09. 2008 v 15:57 +0200:
2.1 The database format is not modified but slightly reinterpreted as
follows: The current implementation cannot contain an empty filename.
Thus, adding a dummy empty filename as first database entry can signal
to locate that a database contains relative filenames.
Does this leave any room for future extensions of the file format?

Hi Mirek,

it certainly leaves room for extensions, as long as they use the same basic
stategy, i.e., offset from end of previous string + new string (the present
scheme works for both locate02 and slocate formats). I think it would be
easy to also implement this for the old format, but that would certainly be
a waste of time. The only restriction on future extensions would be that the
first filename returned by the format can't be empty because that would
indicate relative paths.

We require that the database is a file in the top-level directory
(/SERVERPATH, /CLIENTPATH1, resp. /CLIENTPATH2) and thus locate can
deduce the required filename prefix from the directory part of the
database name.
It would be more extensible to encode the relative path of the database
from the top-level directory (e.g. encode ".locatedb"
in /SERVERPATH/.locatedb).  Some people are concerned about littering
the root of the filesystem with similar FS-specific files, this would
allow eventually storing all such files in ./.per-fs.  I'm not sure
whether this is overengineering.

I had thought about that. The reasons to require that the database is in the
top-level directory (of the subtree to be handled by that database, not
necessarily to top-level directory of a mounted filesystem) were as follows:
(a) simplest to implement (least invasive changes)
(b) yields meaningful results (sort of) with a locate program not aware of
    this feature
(c) even works for a database from stdin

Maybe one should add
(d) least chance for conflicts with future extensions

The default name ".locatedb" was chosen in order to make the clutter less
visible (at least for non-root users).

2.2 A new commandline option for updatedb (e.g., --relpath=PREFIX)
causes the creation of databases with relative filenames. This option
would be incompatible with --old-format and --netpaths, and would
require that --output=DBFILE and --localpaths='DIR1 DIR2...' specify
explicitly relative paths. The option --relpath=PREFIX would imply
--changecwd=PREFIX and an explicit --changecwd would be either ignored
or be an error.
The same feature can be used for handling clustered file systems, e.g.
GFS.  In that case there is no dedicated server, and it seems reasonable
to run updatedb on all nodes.  updatedb would need a locking mechanism
to prevent two nodes running updatedb simultaneously.  (That can be
added anytime later.)

I suppose, that very same locking mechanism is needed when building normal
databases.

regards
Peter Breitenlohner <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]