65

On Windows there a nice file search engine called Everything, which is (unlike find) very fast and (unlike locate) always returns up to date results. AFAIK it works by filling a database from the NTFS journal (it doesn't work with other filesystems).

I wonder if there's something similar (I don't care about the GUI; my point is the speed and the up-to-date guarantee) for Linux (ext3 or ext4); I have googled but found nothing. Can something like this be done or is even somebody working on it?

manatwork
  • 30,549
  • 7
  • 101
  • 91
maaartinus
  • 4,979
  • 7
  • 30
  • 29
  • 4
    The thing I like about Everything is that it not only is instantaneous, but also works for multiple partitions, like multiboot systems with six windows installations plus several data partitions. I'd like to have a Linux search that will work across multiple Linux partitions, not just the single partition. – Arch Parsons May 22 '14 at 01:34
  • Many variant of locate exists (mlocate, slocate, rlocate,....) with there own characteritics (incremental updatedb, realtime or secure indexing,...). All are highly configurable (manpages of updatedb.conf and locate) – Manu H Sep 12 '15 at 07:33
  • 2
    This may not exactly answer the question but today I finally understood why people rave about `fzf`. It's a lot quicker than `find` which I've been using blissfully ignorantly until now. – Sridhar Sarnobat Apr 03 '21 at 22:12

13 Answers13

44

You may have a look at rlocate, a reimplementation of locate that is always up-to-date. Another interesting project is recoll which also supports real time indexing and allows you (like beagle) additionally do full-text searches. Finally I should mention doodle which also supports real time indexing. For doodle there are some nice frontends like catfish.

Note that you can also make (r)locate results clickable by using for example urxvt as terminal-emulator and by writing something like

URxvt.perl-ext: default,matcher URxvt.urlLauncher: /usr/bin/gnome-open     
URxvt.matcher.button: 1 URxvt.matcher.pattern.1: /.*

(and executing xrdb -load ~/.Xdefaults afterwards)

student
  • 17,875
  • 31
  • 103
  • 169
  • 1
    I think this answer should be accepted. `rlocate` itself makes a complete answer already. – phunehehe Feb 20 '12 at 15:17
  • 6
    What's up in 2017? rlocate mentions Linux 2.6 and no Ubuntu 16.04 package. recoll seems interesting and updated, though overkill for my need. doodle has Ubuntu package as of 16.04 so might be an option. – Stéphane Gourichon Mar 19 '17 at 17:49
  • Why is recoll an overkill, you can also run recoll from the commandline. It also integrates well with kde and unity if you want. – student Mar 19 '17 at 18:59
  • My biggest issue with catfish is inability to interact with files - if I want to copy 20 files from the search results I need to `Show in File Manager` 20 times. – AnnanFay May 26 '17 at 14:20
  • [rlocate's documentation](http://rlocate.sourceforge.net/) has a list of "Kernel configuration" requirements that I don't know how to meet, and if I untar it and run `./configure` I'm told I must "install the package with full kernel sources". This tool seems to be out of reach for non-gurus. – Qwertie Oct 30 '18 at 20:59
  • Does `rlocate` index the content of a file? If not, the question is still not answered. – xuhdev Jul 30 '23 at 20:31
10

I was also searching for the "Search Everything" tool for linux and discovered "Search Monkey" in the Ubuntu repository. LOVE IT!

It's light weight, loads quick, wild card searches produces tons of results instantly, plus it has filters and advanced search methods.

I now have my "Everything" search tool back for linux!

VMMF
  • 103
  • 4
Charles
  • 117
  • 1
  • 2
8

Interesting idea to implement this rooted within the filesystem, but nothing like that exists to my knowledge. Apart from a few add-ons trying to burrow themselves deep enough into the upper fs layers to get an early hold on data (Update: Everything falls into this cathegory itself), I'm afraid you're limited to the less satisfying processes of regular indexing.

What might come closest to what you're looking for might be the libferris virtual filesystem.

In the indexing world, you might want to take a look at glimpse, which at least is able to update and append its index.

Update: I just read the stuff about "Everything", and it doesn't seem to be inherent to the FS either, so libferris isn't that far off, plus it also allows to index content, not just filenames. It does satisfy your need of being up-to-date at all times.

Tatjana Heuser
  • 765
  • 4
  • 7
  • 2
    Ferris mailing list dried up since 2007 and do not continue beyond 2010. There's a github repository that was not active between mi-2016 and March 2017 https://github.com/monkeyiq/ferris/commits/master . Perhaps it continues. – Stéphane Gourichon Mar 19 '17 at 17:39
8

I know that this answer is really late, but this might help someone else, especially since there is no real solution till now to this problem.

Linux kernel 5.1 Introduced a kernel API called 'fanotify', which allows recursive directory watches for monitoring creations/deletions/moves, etc. ...

... and there are some tools that started to leverage (or at least testing). To create a search engine that is always up to date like: gosearch, Tracker and lolcate-rs.

G-Man Says 'Reinstate Monica'
  • 22,130
  • 27
  • 68
  • 117
Yehia Amer
  • 181
  • 1
  • 2
5

I am using Angry Search on a Raspberry Pi 3 B+ running Stretch and it works fine. It is really quite fast just like Search Everything on windows. It is very nice to be able to find files so quickly.

lulu
  • 51
  • 1
  • 3
4

btrfs has implemented the find-new command against subvolumes for years. If you keep a relatively up-to-date snapshot tree, it can be used to atomically watch a filesystem for all changes with little fuss.

You would use it like:

btrfs sub find-new /chk/path [gen-id]

You can get the gen-id you need for comparison with the same command, but using a bogus gen-id. There is more info here.

mikeserv
  • 57,448
  • 9
  • 113
  • 229
4

You can use locate command and if you want update its database run the following command:

# updatedb

This command update the locate database in a few seconds

RobotMan
  • 151
  • 2
  • interactive sample implementation: https://github.com/phil294/linux-locate-everything – phil294 Dec 26 '16 at 12:17
  • It might be a few seconds on your small system but on my multiterrabyte system it's minutes or even hours – roaima Dec 04 '21 at 20:50
4

There are other solutions like Angry Search, however, I like FSearch the most.

Please note that, Everything monitors file systems for all changes. Your search results will update in real-time to reflect any changes. Everything keeps NTFS indexes up to date with the NTFS USN Journal. This feature (search results update in real-time to reflect any changes) needs Windows specific features so is missing in Linux. For more details please check here. Being said that, In FSearch, to update index (not real-time), press Ctrl+Shift+R. There is also a option to automatically update index every time you start FSearch.

Ahmad Ismail
  • 2,478
  • 1
  • 22
  • 47
  • 1
    Considering how many search results you get pointing to FSearch when you google for Evernote alternative for Linux, I'm surprised you are the only one who posted it here. – Ghos3t Oct 28 '18 at 16:56
2

FSearch, which is inspired by by Everything Search Engine.

Yong Yang
  • 31
  • 2
1

UI front-end for locate command that works almost the same as Everything :

https://github.com/AlexTuduran/Locator/releases

Alex Tuduran
  • 11
  • 2
  • 1
    This appears to be built on the false premise that `locate` is never updated automatically. – roaima Jun 23 '15 at 13:14
  • Please develop. What do you mean by locate being updated? – Alex Tuduran Sep 11 '15 at 11:03
  • Your GitHub project states that the _Unix command `locate` uses the same principle, except that the database is not updated automatically_. The `locate` package includes a `cron` task that does automatically update the database. – roaima Sep 11 '15 at 13:11
  • If that's true, then it's only helping the goal of the tool. Having the database updated automatically off-loads the user from doing another task. The user still can update the database explicitly if needs immediate updates. Or what is the concern here regarding the false premise? – Alex Tuduran Feb 17 '16 at 11:16
1

It should be possible to build something like this in a few lines of code using inotify (there's also the inotify-tools package which would allow you to implement this using shell scripts).

(I'd be very surprised that any such tool would be driven from the journal - more likely it's implemented in the virtual filesystem tier)

symcbean
  • 5,008
  • 2
  • 25
  • 37
  • 2
    I'm unsure if `inotify` could be useful here as it's not recursive. Creating watches for the whole tree is simple, but can the kernel handle many tens of thousands of them? Even if it can, this doesn't look as an effective way to me. – maaartinus Feb 08 '12 at 03:33
1

You might want to try beagle. Unfortunately http://www.beagle-project.org is now parked domain - wikipedia.

Anjesh
  • 11
  • 1
0

Depending on your actual use cases, you could use IntelliJ IDEA, free Community Edition. https://www.jetbrains.com/idea/download/#section=linux

If you don't really need to search the entire disk (which I doubt), but rather sets of files (projects), then you can open any directory as a project, and search with Ctrl + Shift + F . IDEA keeps an up-to-date index all the time.

This may be a bit overkill just for the searching, but if your files are text and you also read and edit them, then you should give it a try.

Ondra Žižka
  • 879
  • 9
  • 16