locate command finds a file's path, but the file does not exist in that path

find ls locate

17,835

Solution 1

It is possible that you had the Origin90SR2DVD.iso file in the location /home/david when the database file of locate (/var/lib/mlocate/mlocate.db) was updated last time by cron (or by yourself). As locate just for the file names in the database file (thats why it is fast) while searching, you can consider it's technique not live.

Although locate is showing the location of the file, it is very possible that the file is not present there (might be removed or moved to somewhere else).

You have two ways to be sure of whats going on:

You can update the locate database file by sudo updatedb and then run the same locate command.
Alternately, you can use find to do a live search. To look for the file in your home directory recursively:
```
find ~ -type f -iname 'Origin90SR2DVD.iso' -print -o -path ~/.gvfs -prune
```
-path ~/.gvfs -prune (thanks to Eliah Kagan) is used so that we do not descend into ~/.gvfs directory while searching. Otherwise we will get a distracting permission denied message, since the directory is owned by root. You can omit this (and see the message) by removing -print -o -path ~/.gvfs -prune.

You can also look for all possible places in the filesystem hierarchy. Here I have considered few places that can contain the file, it will be unusual if your file is found under any other directory.
```
sudo find /home /root /opt /usr/local /mnt -type f -iname 'Origin90SR2DVD.iso'
```

EDIT :

locate's database is updated by cron on a daily basis. In my system it is run at 6:25 AM everyday (check your's on /etc/crontab).

Actually anacron will run the cron job to ensure that if the computer is Off at that time, the job will be run after the computer is turned On next time. If anacron is not available, run-parts will execute the files (including mlocate) in /etc/cron.daily directory only at the mentioned time.

Solution 2

Run sudo updatedb to make sure your mlocate database is up to date.

17,835

Dave

Updated on September 18, 2022

Comments

Dave over 1 year
I have written:
```
locate Origin90SR2DVD.iso
```
And I received the path where that file is located:
```
/home/david/Origin90SR2DVD.iso
```
Then I have written:
```
cd /home/david
```
I have run:
```
ls -lrth
```
And I cannot find the Origin90SR2DVD.iso file.

Why the file is not in that path?
- mkasberg about 9 years
  
  What is the output of locate Origin90SR2DVD.iso?
- Dave about 9 years
  
  @mkasberg /home/david/Origin90SR2DVD.iso
- Dave about 9 years
  
  @EliahKagan Just edited the question adding postimage.org images
- Dave about 9 years
  
  @Eliah Kagan Just edited the question adding postimage.org images
Dave about 9 years

I runned sudo updatedb , and then I wrote locate Origin90SR2DVD.iso. The output was: /home/david/Pictures/Origin90SR2DVD.iso. So, before running sudo updatedb, the path was /home/david/. Why the locate database was not up to date? Does it need to be updated due to the fact that locate is not a Live technique ? Thank you very very much!
heemayl about 9 years

@EliahKagan The 2>/dev/null for ~ is for ~/.gvfs..and yeah weird places could be ignored..i will make an edit..
heemayl about 9 years

@Dave Check my edits..
heemayl about 9 years

@EliahKagan: Seconded and edited :)
Eliah Kagan about 9 years

@heemayl I should mention, one disadvantage of -print -o -name .gvfs -prune is that if other, non-special files or directories called .gvfs have been created, they'll be pruned as well. If you're searching in just one user's home directory, you may want to append -print -o -path ~/.gvfs -prune instead, which also seems to work well. The only disadvantage is that you must give .gvfs's path exactly as it appears relative to the directory you passed as the first argument to find, e.g., find ~ -name foo -print -o -path ~/.gvfs -prune, find . -name foo -print -o -path ./.gvfs -prune.
heemayl about 9 years

@EliahKagan It is highly unlikely that a user would have a file/directory named .gvfs somewhere else in ~ ..anyway keep it precise i will edit..thanks..
Eliah Kagan about 9 years

Agreed. And if they do, it's not really worse than how user-owned directories without read and execute permissions won't be checked. (That is, if someone wanted to make a .tar file or something where extraction produced folders whose contents wouldn't be found using this method, they already could.) And I like this better than >/dev/null as unrelated errors are shown. ...Btw, why use -iname instead of -name? The specific filename is known, after all. Also, you might want to explain -type f. It's OK here but I think often doesn't do what people want.