[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 81257] option to use locate/slocate working very slow
From:       Ben Smith <kde () deesconsulting ! com>
Date:       2004-06-30 17:49:35
Message-ID: 20040630174935.11880.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
      
http://bugs.kde.org/show_bug.cgi?id=81257      




------- Additional Comments From kde deesconsulting com  2004-06-30 19:49 -------
I'd just say I'm against limiting functionality when slocate is used because of the \
following:

1) As somebody already said, using slocate used to be *faster*.  From a few straces, \
it looks like, now at least, files in the given directory are scanned regardless of \
whether 'use index' is selected or not.

2) If, as I said, slocate gains functionality in the form of pattern matching, it \
would be preferable to use said functionality in the program as close to the database \
as possible.

3) One case in which locate is the preferable, and possibly only, option, is
to search files on a network (NFS) drive.  In fact, I'd like to be able to
limit users to *only* use slocate, instead of taxing fileservers and
networks, and have them still be able to perform complex pattern matching.

4) kfind (probably) doesn't want to implement a full, secure, cron-able, caching \
utility such as slocate.  Duplicating this effort would be needless.


[prev in list] [next in list] [prev in thread] [next in thread]