Importance of mlocatedb on modern Linux?

SlowCoder · 10-14-2021, 01:32 PM

How important is mlocate, on a personal desktop distro? What important apps/services rely on it to function properly? It seems I/O these days is probably fast enough, and the desire to see actual files, and not a cached database, practically render locate unneeded?

michaelk · 10-14-2021, 01:53 PM

To me, very important.

Many distributions do not even install mlocate anymore. If the typical user does not have much CLI experience then I assume they will just use the file browser for their searches.

If you want to find a file quickly and know it has not been recently updated using locate is easy.

find is a great tool but can get complex quickly and can be confusing for users who do not use the CLI and just want a quick search.

syg00 · 10-14-2021, 04:38 PM

I use it exclusively. Having had very bad experiences with the indexers - gnome tracker primarily - I make efforts to disable them on every install. Re-running the updatedb is trivial in my case, so I have always disabled the timed task if installed as well.

frankbell · 10-14-2021, 08:25 PM

I find mlocate and the associated "locate" command essential.

GazL · 10-15-2021, 08:28 AM

I still use locate, but I also have this quick-find function defined in my shell init file

Code:

qf () 
{ 
    find "$HOME" /local/library \( -name ".*" -prune \) -o \( -ipath "*$1*" -type f -readable -print \) 2> /dev/null
}

After the initial search any subsequent ones are quite responsive as everything is in vfs cache, and it has the advantage of being realtime rather than point in time like locatedb. It's also more focussed as my locatedb covers a much wider set of directories.

IMO both approaches have a role to play.

Like syg00 I've had bad experiences with the desktop indexers, and now refuse to go anywhere near them.

pan64 · 10-15-2021, 08:38 AM

no app/services rely on this (I guess), but I use it too. And find it very useful.

Quote:

Originally Posted by GazL

I still use locate, but I also have this quick-find function defined in my shell init file

Code:

qf () 
{ 
    find "$HOME" /local/library \( -name ".*" -prune \) -o \( -ipath "*$1*" -type f -readable -print \) 2> /dev/null
}

find is slow, there is a tool called fd which is much faster and more efficient. (and by the way, I do not really use it so often, that caching is not really helpful)

GazL · 10-15-2021, 08:59 AM

Code:

$ time -p locate Solsbury
/local/library/audio/CDs/Peter Gabriel/1977 - Peter Gabriel 1/02 - Solsbury Hill.flac
real 0.18
user 0.18
sys 0.00
$ time -p qf Solsbury
/local/library/audio/CDs/Peter Gabriel/1977 - Peter Gabriel 1/02 - Solsbury Hill.flac
real 0.05
user 0.04
sys 0.00
$

That's quick enough for me, and I have enough ram for the dirents to hang around in cache for a very long time.

sundialsvcs · 10-15-2021, 11:50 AM

I still like to use locate, but on my Macintosh I had to turn-off most of the features of their "Spotlight Search" because the daemon was consuming way too many resources updating its databases. Once the initial "locate" database is built, it doesn't take too much time to keep it updated ... usually in the dead of night.

hazel · 10-15-2021, 12:05 PM

I use locate a lot. It's much easier to use than find and has the advantage that it searches substrings by default, so you don't need to have the correct filename.