Currently I'm trying to migrate from mlocate to plocate. I'm using mlocate in my script (note: locate is aliased to either mlocate or plocate depending which one I've installed). ## Successfully searched home directory with mlocate Below is the first 10 outputs after running locate home (locate is aliased to mlocate):

/home
/etc/apparmor.d/tunables/home
/etc/apparmor.d/tunables/home.d
/etc/apparmor.d/tunables/home.d/site.local
/etc/systemd/homed.conf
/home/username
/home/username/.bash_history
/home/username/.bash_profile
/home/username/.bashrc
/home/username/.cache
/home/username/.cargo

As you can see, I could successfully find files in my home directories with mlocate. ## Unsuccessfully searched home directory with plocate: However, after installing plocate, I get results from /etc/, /usr/ etc, and all I get is one /home: After running locate home (locate is aliased to plocate):

/home
/etc/apparmor.d/tunables/home
/etc/apparmor.d/tunables/home.d
/etc/apparmor.d/tunables/home.d/site.local
/etc/systemd/homed.conf
/usr/bin/addgnupghome
/usr/bin/homectl

As you can see, plocate couldn't find files and directories in my home directory. ## What I've tried ### 1. Comment from author of plocate This manjaro thread [How to use plocate?](https://forum.manjaro.org/t/how-to-use-plocate/82592) has the author of plocate commented as below: > First, check that the database has been updated recently. Most users will want to use plocate’s updatedb; plocate-build (which converts from mlocate’s database) is generally not what you want since plocate 1.1.0. [...] > > The other reason why a file isn’t shown, is typically permissions. Check if you can find the files as root (sudo plocate test); if you can, the problem is most likely that you don’t have access rights to the directory all the way down from the root. plocate should find anything that find / -name *test* does, but no more. I've run sudo updatedb. My home dir access right:

/ 
➜ ll
drwxr-xr-x - root 17 Jul  2022 home/
drwxr-xr-x - root 16 Apr 21:44 usr/

/home 
➜ ll
drwxr-xr-x - username 16 Apr 21:51 username/

It does seem that plocate couldn't access files and directories under my home dir, but it has the same access right as usr. I don't understand why plocate can see usr but not files and dir under home. #### 2. Results are different when running as sudo The results are different when I run plocate as sudo. Below is regular locate:

➜  locate ranger
/usr/bin/ranger
/usr/lib/python3.10/site-packages/ranger
/usr/lib/python3.10/site-packages/ranger_fm-1.9.3-py3.10.egg-info
/usr/lib/python3.10/site-packages/ranger/__init__.py
/usr/lib/python3.10/site-packages/ranger/__pycache__

Below run as sudo:

➜  sudo locate ranger
/root/.config/ranger
/root/.local/share/ranger
/root/.local/share/ranger/bookmarks
/root/.local/share/ranger/history
/root/.local/share/ranger/tagged
/usr/bin/ranger
/usr/lib/python3.10/site-packages/ranger
/usr/lib/python3.10/site-packages/ranger_fm-1.9.3-py3.10.egg-info

I can see results in my home directories (i.e., first 5 results). ## What I want I'd like to be able to search my home directory with plocate the way I can do so with mlocate. In other words, I expect results from home directory when using plocate:

$ locate home
/home
/etc/apparmor.d/tunables/home
/etc/apparmor.d/tunables/home.d
/etc/apparmor.d/tunables/home.d/site.local
/etc/systemd/homed.conf
/home/username
/home/username/.bash_history
/home/username/.bash_profile
/home/username/.bashrc
/home/username/.cache
/home/username/.cargo

The locate program of findutils scans one or more databases of filenames and displays any matches. This can be used as a very fast find command if the file was present during the last file name database update. There are many kinds of databases nowadays, - relational databases (with query language e.g. SQL), - NoSQL databases - document-oriented databases (e.g. MongoDB) - Key-value database (e.g. Redis) - Column-oriented databases (e.g. Cassandra) - Graph database So what kind of database does updatedb update and locate use?

I have read that to run the **locate** command on **CYGWIN**, first I need to run the following command: updatedb --localpaths=c:/ What does this command do exactly? As I run this on CYGWIN and it is taking too much time.

I am attempting to update a single directory I created. I'm using updatedb so it will be found by the locate command. Command used: updatedb --localpaths='/frodo/lib/modules/3.12.3-031203-generic/kernel' Output: updatedb: unrecognized option '--localpaths=/frodo/lib/modules/3.12.3-031203-generic/kernel' Same result with: updatedb --localpaths= updatedb: unrecognized option '--localpaths=' From man updatedb: > --localpaths='path1 path2...' > Non-network directories to put in the database. Default is /. **Why does it give this error when --localpaths is clearly stated as an option?** ---------- Sytem info: > updatedb --version > updatedb (mlocate) 0.26 > Copyright (C) 2007 Red Hat, Inc. All rights reserved. > This software is distributed under the GPL v.2. > > This program is provided with NO WARRANTY, to the extent permitted by law. > > lsb_release -a > LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64: > core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2- > noarch:core-4.0-amd64:core-4.0-noarch > Distributor ID: Ubuntu > Description: Ubuntu 13.10 > Release: 13.10 > Codename: saucy > > uname -r > 3.12.3-031203-generic ---------- Edit: I have had success with updatedb -U /frodo/lib/modules/3.12.3-031203-generic/kernel, but I would still like to know why the --localpaths from the manual is not recognized. This alternative option is not in the manual, but found with updatedb -h. > -U, --database-root PATH the subtree to store in database > (default "/")

When I use the locate command (specifically plocate 1.1.22), it doesn't seem to include any files under the /mnt directory, i.e. on external drives. The man page for updatedb claims "The whole file system is scanned by default" (which I take to mean /**/*), so I retried after an update, but no luck. I considered creating a symlink to /mnt in a place that updatedb *does* map, but I understand from [this Q&A](https://unix.stackexchange.com/a/650592/610644) that symlinks won't work by default. I also tried setting PRUNE_BIND_MOUNTS = "no" and removing /mnt from PRUNEPATHS in /etc/updatedb.conf, but again this did nothing. So, is there a way to make updatedb or locate work with files under /mnt?

I have created mlocate database with the contents of a particular folder. I see that the updatedb doesn't include the path pointed by the symbolic links in the database. How can I include the path pointed by the symbolic links in the database? **Surprisingly**: *mlocate* has a default option -L or --follow that follows trailing symbolic links when checking file existence (default). > What purpose does it serves when *updatedb* doesn't include symlinks! --- References: - [updatedb(8): update database for mlocate - Linux man page](https://linux.die.net/man/8/updatedb) - [mlocate - Gentoo Wiki](https://wiki.gentoo.org/wiki/Mlocate)

After setting a password-less updatedb, I am presented with an error:

$ updatedb
/var/lib/plocate/: Permission denied

How can I fix it? *** That is just an example error I got latest. I got more of those. But since it is a very long time since I tried to set this up and failed, now I am confident to make it.

I keep my digital music and digital photos in directories in a Windows partition, mounted at /media/win_c on my dual-boot box. I'd like to include those directories—but only those directories—in the locate database. However, as far as I can make out, updatedb.conf only offers options to exclude directories, not add them. Of course, I could remove /media from PRUNEPATHS, and then add a whole bunch of subdirectories (/media/win_c/Drivers, /media/win_c/ProgramData...) but this seems a very clunky way of doing it—surely there's a more elegant solution? (I tried just creating soft links to the Windows directories from an indexed linux partition, but that doesn't seem to help.)

How is it possible for updatedb to run very fast by avoiding doing full disk scans? Since mtime of parent folder is not affected by files in subfolders. In Why does the updatedb program run so fast? > @hugomg I don't think it actually does. It should only change the > mtime of its immediate parent. – @Kusalananda I searched but cannot find the answer.

locate (or rather, updatedb) is somewhat simple: it takes the output of find for the required paths (usually '/'), sorts it, and then compresses it with a front-compression tool (frcode), in which the consecutive common prefixes are replaced by number of repeated characters. So I'm wondering, what's stopping anyone from creating something similar for full text search? Say, how about concatenating every file in the system, sorting every line with the format line:filename:linenumber, and doing front-compression? I guess you would end up with a faster grep, with the tradeoff of being outdated until the daily/weekly cron job runs, just like locate. Maybe locategrep would be overkill for the entire system, but I can see it being useful to speed up a large project which won't change much for the rest of the day. Does something like this exists already or is it trivial to implement with some known tools? **Note:** I would rather avoid enterprise-like solutions that include features beyond plain-text searching (but I appreciate regex support).

I'm building a Linux OVA on a VM to scan stuff with nmap.
I'm using cron to keep my packages up to date:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get autoremove

It's from my understanding that nmap should be kept up-to-date with this.
However, I've seen this command on different blogs: nmap –script-updatedb. This is the documentation from Nmap's website. >**--script-updatedb**
>This option updates the script database found in scripts/script.db which is used by Nmap to determine the available default scripts and categories. It is only necessary to update the database if you have added or removed NSE scripts from the default scripts directory or if you have changed the categories of any script. This option is generally used by itself: nmap --script-updatedb. Do I need both?

I'm trying to index the files on my NAS (It's a TerraMaster F4-210) with the command: updatedb -l 0 -o /home/jake/nas-index.db -U /mnt/nas/ After running for a little while it dies with the error: fdopendir: Permission denied No file is created at /home/jake/nas-index.db It was mounted with the command: mount -t cifs -o "username=jake,password=mypass" //10.0.0.127/jake /mnt/nas/ mount | grep nas //10.0.0.127/jake on /mnt/nas type cifs (rw,relatime,vers=3.1.1,cache=strict,username=jake,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.0.127,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1) and my user can read and write to it. For example I can do: $> cd /mnt/nas $> ls -al myfile.txt ls: cannot access 'myfile.txt': No such file or directory $> touch myfile.txt $> ls -al myfile.txt -rwxr-xr-x 1 root root 0 Feb 24 01:36 myfile.txt* $> cat myfile.txt $> echo "foo" >> myfile.txt $> cat myfile.txt foo $> rm myfile.txt $> ls -al myfile.txt ls: cannot access 'myfile.txt': No such file or directory So I can create, append, read, and delete the file. I have even tried running the updatedb command as root. To make sure I'm not accidentally ignoring the path or filesystem, I have commented out everything in /etc/updatedb.conf. I'm not sure what to try next. What is going on and how do I fix it? Thanks in advance.

A few days ago, when I ran locate to find some files in my home filesystem, it didn't return anything. It seemed to me that it had only indexed the files in the root filesystem but not the home filesystem. (Not sure where its configuration is.) So I ran updatedb and then locate found files in the home filesystem. Now when I ran locate again, it returned nothing. Has the database created by updatedb expired after a certain amount of time? Thanks. ------------- Update: I have been using NixOS. I am replying to the requests in the comment: > check for mlocate.db in /var/lib/mlocate/mlocate, $ ls /var/lib/mlocate/mlocate ls: cannot access '/var/lib/mlocate/mlocate': No such file or directory $ ls /var/lib/mlocate/ ls: cannot access '/var/lib/mlocate/': No such file or directory $ ls /var/lib/ alsa bluetooth cups dhclient docker lightdm lightdm-data logrotate.status machines misc NetworkManager NetworkManager-fortisslvpn nixos private systemd udisks2 vnstat > post the content of your /etc/updatedb.conf $ cat /etc/updatedb.conf PRUNEFS="afs anon_inodefs auto autofs bdev binfmt binfmt_misc ceph cgroup cgroup2 cifs coda configfs cramfs cpuset curlftpfs debugfs devfs devpts devtmpfs ecryptfs eventpollfs exofs futexfs ftpfs fuse fusectl fusesmb fuse.ceph fuse.glusterfs fuse.gvfsd-fuse fuse.mfs fuse.rclone fuse.rozofs fuse.sshfs gfs gfs2 hostfs hugetlbfs inotifyfs iso9660 jffs2 lustre lustre_lite misc mfs mqueue ncpfs nfs NFS nfs4 nfsd nnpfs ocfs ocfs2 pipefs proc ramfs rpc_pipefs securityfs selinuxfs sfs shfs smbfs sockfs spufs sshfs subfs supermount sysfs tmpfs tracefs ubifs udev udf usbfs vboxsf vperfctrfs" PRUNENAMES="" PRUNEPATHS="/tmp /var/tmp /var/cache /var/lock /var/run /var/spool /nix/store /nix/var/log/nix" PRUNE_BIND_MOUNTS="no" > Check for whatever related entry in your crontab. $ ls /var/spool/cron/crontabs ls: cannot access '/var/spool/cron/crontabs': No such file or directory $ ls /var/spool/cron/ ls: cannot access '/var/spool/cron/': No such file or directory $ ls /var/spool/ cups

I run Linux Mint 21. Currently the locate command always returns no results, and updatedb always returns immediately. The database is sized no more than a few kilobytes. I have verified that the package mlocate is installed. The updatedb command is a cascading symbolic link that ultimately resolves to /usr/sbin/updatedb.plocate, a native binary executable. The problem appears on two separate systems having no particular commonality other than both being x86 64-bit machines running the same distribution.

I run updatedb like this: updatedb --localpaths="/a /b" /a is a removable drive. /b is the local hard drive. Although /a's not always accessible to me, I frequently want to run locate to find if I have a certain file on it (based on the last time I ran updatedb). The problem is, if I run updatedb when it's not plugged in, I get an error: /usr/bin/find: '/a': No such file or directory The database gets the latest information about /b, but it removes /a's existing data. Is there a way to keep /a's data when /a isn't plugged in during updatedb? I think this might be possible with multiple databases, one for /a and another for /b. Then a script can check whether or not /a is plugged in when it decides whether or not to updatedb. But the man page for both commands kind of assumes I know a lot more than I do (e.g., what FINDOPTIONS does), so I'm hoping there's an easier solution to this problem.

updatedb.findutils and updatedb.mlocate don't seem to grab everything possible. How can they be instructed to include all files?

$ printf 'locate: %s, smaller than find: %s\n' "$(sudo locate '*' | wc -l | numfmt --grouping)" "$(sudo find / | wc -l | numfmt --grouping)"
locate: 9 348, smaller than find: 14 053

updatedb was run as root. Like title suggest, I want to *grab everything possible*. I don't want to limit locate, updatedb or find in its scope. I can't modify .conf files. I rather need a command that work as-is without modifying files Answer still gives different results

$ printf 'locate.mlocate: %s, smaller than find: %s\n' "$(sudo updatedb.mlocate --prune-bind-mounts no --prunefs "" --prunenames "" --prunepaths ""; sudo locate.mlocate '*' | wc -l | numfmt --grouping)" "$(sudo find / | wc -l | numfmt --grouping)"
locate.mlocate: 13 598, smaller than find: 14 053

$ printf 'locate.findutils: %s, smaller than find: %s\n' "$(sudo updatedb.findutils --prunepaths="" --prunefs=""; sudo locate.findutils '*' | wc -l | numfmt --grouping)" "$(sudo find / | wc -l | numfmt --grouping)"
locate.findutils: 13 455, smaller than find: 14 053

I have a timeshift user with backups in my /home. Every time after boot when I search for something with **locate**, all the timeshift directories are shown to me. To fix this issue, I added /home/timeshift to the PRUNEPATHS variable in /etc/alternatives/updatedb. I'm running Debian 10. On Arch I had the same issue and resolved it by adding the path to /etc/updatedb.conf. On Debian I don't have this file, so I changed /etc/alternatives/updatedb. When running updatedb manually after boot, locate doesn't show me the PRUNEPATHS anymore. But when I first start the system, updatedb shows me my /home/timeshift. Changing PRUNEPATHS in /etc/cron.daily/locate does not help either.

I am trying to create a custom mlocate db for my home directory. When running the updatedb it complains about inability to open a temporary file.

55;~/>uname -a
Linux yoga 4.12.14-lp151.28.59-default #1 SMP Wed Aug 5 10:58:34 UTC 2020 (337e42e) x86_64 x86_64 x86_64 GNU/Linux
56;~/>updatedb --version
updatedb (mlocate) 0.26
...
57;~/>updatedb -l 0 -o ~/.home-mlocate.db -U ~/
updatedb: can not open a temporary file for `/home//.home-mlocate.db'

Prepending updatedb with sudo or running as root does not change the outcome. Running simply sudo updatedb without any arguments succeeds. More generally unless the database is the default one updatedb can not create temporary file:

yoga:~ # /usr/bin/whoami
root
yoga:~ # /usr/bin/updatedb ; echo $?
0
yoga:~ # /usr/bin/updatedb -o /var/lib/mlocate/mlocate.db ; echo $?
0
yoga:~ # /usr/bin/updatedb -o /var/lib/mlocate/custom-mlocate.db ; echo $?
/usr/bin/updatedb: can not open a temporary file for `/var/lib/mlocate/custom-mlocate.db'
1
yoga:~ # /usr/bin/strace /usr/bin/updatedb -o /var/lib/mlocate/custom-mlocate.db 2>&1 1>\dev\null | grep "openat.*custom-mlocate.db"
openat(AT_FDCWD, "/var/lib/mlocate/custom-mlocate.db", O_RDWR) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/lib/mlocate/custom-mlocate.db.6JiH9O", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
yoga:~ #

My operating system is openSUSE Leap 15.1 and my /home directory is on an ext4 file system. What is the problem and how it is to be resolved?

I've just read: https://unix.stackexchange.com/q/301717/34868 but that is pretty slow. Now, on typical Linux systems, a filesystem database-of-sorts is maintained, which can be searched using locate, rather than iterating the entire filesystem. Is it possible to utilize that database - as-is or with a tweak to the search procedure - to get symlinks pointing into a given directory? Or symlinks in general?

When I run updatedb I get an error "Permission denied" to /run/user $ sudo updatedb /usr/bin/find: '/run/user/1000/doc': Permission denied Note my version of updatedb comes from the package [locate](https://savannah.gnu.org/projects/findutils/) which is itself just [GNU Findutils](https://savannah.gnu.org/projects/findutils/) . My updatedb eventually resolves via symlinks to updatedb.findutils. Here you can see [man 1 updatedb.findutils](https://manpages.debian.org/testing/locate/updatedb.findutils.1.en.html) which doesn't mention a configuration file at all. Is there anyway to configure GNU Findutils to skip searching in a directory? Note if I do this, sudo updatedb --prunepaths=/run It works fine. If I do this, echo 'PRUNEPATHS = "/run/user/"' | sudo tee /etc/updatedb.conf I still get the error.