Re: How to find a needle in a haystack?

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


On Wed, 2010-05-19 at 15:40 -0430, Patrick O'Callaghan wrote:
> On Wed, 2010-05-19 at 14:07 -0400, [email protected] wrote:
> > The data in the files is of the unstructured binary type.  When I do a
> > search, I have _most_ of the file name.  Enough to uniquely identify
> > it.
> So you don't need to look into the file to get a match? Sounds like the
> best procedure would just be to keep an index of all the filenames and
> update it when files are added/removed (assuming you have control over
> both of these processes). A simple database should be able to handle
> this easily, which is pretty much what you suggested yourself. In fact
> it looks so simple that a Berkeley DB file would do it, without needing
> all the fancy DB machinery or MySQL or Postgres. See for example "man
> DB_File".

Is there any reason to not use the already existing updatedb/locate
combo? The fedora updatedb seems to be based on mlocate, which as far as
I know uses the mtime of directories to tell if a directory has changed
since the last scan (mtime of the directory will change if files have
been added or deleted). This should speed up runs unless a lot of
directories change between runs.

You can disable the default updatedb configuration and run it manually
(or in cron jobs) specifying one file system for each job. Let them run
in parallel with output to separate bases. Then globally set the
environment variable to tell locate where to look so it finds all the
bases. Look at the man pages for updatedb, updatedb.conf locate and
mlocate.db. The last one is very optional.


users mailing list
[email protected]
To unsubscribe or change subscription options:

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux