[Top][All Lists]

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

Re: Status of updatedb

From: Miloslav Trmac
Subject: Re: Status of updatedb
Date: Fri, 21 Apr 2006 03:01:49 +0200
User-agent: Thunderbird 1.5 (X11/20060313)

James Youngman napsal(a):
> On 4/20/06, Dmitry V. Levin <address@hidden> wrote:
>> On Sat, Dec 17, 2005 at 11:42:53PM +0000, James Youngman wrote:
>>> One more wheel and we'll have enough for a car :)
>> I found one more wheel! :)
>> Yet another locate implementation is mlocate, see
>> http://www.redhat.com/archives/fedora-devel-list/2006-February/msg01060.html
> Thanks.  Dear God, though.
> As far as I can see, it's not as though we are unapproachable, remote,
> difficult to deal with, hard to find, awkward or slow to respond.  
> Why don't people talk to us?
This particular wheel can't be easily used for the findutils car without
changing the findutils' interface, which I assume isn't desirable:
- locate(1) had to be compatible with slocate and thus the locate
  interface conflicts, at least in the -r option semantics.
  Therefore just extending findutils' locate wouldn't work (without
  "bastardizing" findutils for Fedora).
- mlocate uses the slocate's concept of scanning as root and having
  a privileged group for locate; extending findutils' updatedb to
  handle both this model and the traditional "run find as nobody"
  model (for backward compatibility) would be IMHO rather ugly.
- mlocate's updatedb tries hard to skip reading directories, so
  updatedb.sh --findoptions can't be easily implemented, at least
  not without dropping to a "slow mode" and reimplementing most of
  find(1) in the meantime.  This could probably be solved by strongly
  tying together find and updatedb in findutils.

That said, I would be happy to work with you on integrating the code as
far as possible, e.g. getting most of the code in findutils as a shared
library, and leaving mlocate as a tiny wrapper.

reply via email to

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