Is it a bug?

[Marcin ‘Qrczak’ Kowalczyk]

2008/7/20 NoOp <glgxg at sbcglobal.net>:

> In Hardy, locate doesn't
> find the file in the trash (/home/<user>/.local/share/Trash/) folder, it
> instead finds where it was.

This is because the locate database is updated daily. Wait until the
next day and it will be found in its current place.

> Another interesting thing; if I search for the file via Tracker or
> Nautilus, the file is not found.

This is because Tracker and Nautilus skip hidden files and directories
(those with the name beginning with a dot).

Tracker uses a database like locate (which indexes file contents too,
not just filenames), but it tracks filesystem changes in realtime.

> However, if I search for the file using
> Places|Search the file is found.

This is strange, because it does skip hidden directories for me.

This is indeed a mess, because file searching tools have partially
overlapping functionality. They differ in the balance between speed
and accuracy:
1. Read current filesystem contents? (find, mc / M-?, Nautilus/Find,
Places/Search)
2. Use a database which is tracked in realtime? (Tracker, Beagle,
Google Desktop)
3. Use a database which is updated by cron? (locate)
where 3 should really be subsumed by 2, but locate is much older and
simpler than the tools from group 2. They differ in whether they scan
only the home directory or the entire filesystem. They differ in
whether they look inside file contents (Nautilus/Find and locate
cannot). They differ in whether they skip hidden files and directories
(find & locate do not). They differ in the types of files they are
able to extract contents from. They differ in whether you provide the
top directory of the search or they return results about the whole
filesystem.

Some of the differences may be historical accidents. Some of the
differences are caused by admin-oriented or user-oriented attitude of
particular tools. Some combinations are probably impossible for
performance or security reasons, e.g. extracting contents from all
kinds of files should not be done in real time, and Tracker / Beagle /
etc. should probably continue having a separate database for each
user.

They have been some attempts at unifying them. I remember patches
which made Nautilus/Find use Tracker or Beagle when available. This
has been abandoned because too many things work differently depending
on the searching backend: while using a database instead of scanning
the filesystem make searching faster, some files cannot be found at
all (e.g. when they are located outside the home directory and the
database stores only the contents of the home directory, or when a
network drive is mounted inside a home directory but is not scanned by
Tracker).

It would be nice if the mess was cleaned up a bit. For example:
- Nautilus/Find should be unified with Places/Search
- they should be able to use Tracker / Beagle etc., but falling back
to actually reading the filesystem when searching outside indexed
regions or on explicit request (perhaps they should detect that some
subdirectories are not indexed even though the top directory is
indexed, and in this case offer to search them directly for slower but
more complete results, after displaying the results obtained from
Tracker / Beagle)
- they should skip hidden files or not depending on the Nautilus
setting of displaying them
- locate should be able to track filesystem changes in realtime

-- 
Marcin Kowalczyk
qrczak at knm.org.pl
http://qrnik.knm.org.pl/~qrczak/