Everything for linux ?

[zhuo.quan]

I love this awesome tool, do you have a plan on linux in future ? Or it's impossible to achieve the same performance on linux?

Thank you!

[NotNull]

A search for "Linux" on this forum return this thread:
viewtopic.php?f=2&t=6819&p=21694&hilit=linux#p21694

[Laurent_Paris]

A search for "Linux" on this forum return this thread:
viewtopic.php?f=2&t=6819&p=21694&hilit=linux#p21694

Fsearch is fast but doesn't come close to Everything in terms of functionality. It can find files as you type (but lacks complex search syntax), open the containing folder (but doesn't even focus on the target) and that's pretty much it.
As of July 2018 there is
- no way to rename (let alone bulk-rename) files in the results
- no drag-and-drop or simple way to move them to another folder
- no real-time update (requires a complete manual update every time you change something)
Those are pretty basic uses of Everything as far as I'm concerned and in many cases it's more efficient to use Nemo's painstakingly slow native search function rather than Fsearch.

So the question still stands. Are there any plans to port Everything to Linux?

[Metavoid]

Hi
I dont think its directly possible as Everything uses NTFS meta info to get the insane speeds.
But of course the rest of its functionalities could be ported. (maybe not the insane fast live update)

[Stamimail]

I think Everything uses a lot of built-in components of Windows.
Isn't there a search tool for Linux? Something that makes folder&file indexing the same way Folder Indexing works?

[therube]

Is there a file search engine like “Everything” in Linux?

[traycerb]

how about fzf https://github.com/junegunn/fzf

[Laurent_Paris]

Is there a file search engine like “Everything” in Linux?

So no real alternative then
These projects still seem to struggle with real-time updating (I understand this is largely due to Linux limitations) and don't offer much functionality (no quick way to rename the files you've found or simply move them around).
Unless native search gets drastically faster with Mint 19 I think I'll just switch back to Windows. I've become that dependent on Everything.

[therube]

Came across this the other day, Windows & Linux, FileSearch is designed to create a static index of files for fast searching and filtering... (untested, & of course it cannot be Everything).

[cjb76]

Hi, I'm an Everything Fan, recently switched to Linux, anyway I'm not sure if this was mentioned but "FSearch is inspired by Everything, here's the official link: http://www.memecode.com/filesearch/

[TheDauthi]

FSearch doesn't hook into inotify yet, which is the linux version of the NTFS change notification system. Supposedly adding it in the near future.

Tech gobbledygook explanation: inotify has some nice features and advantages over the NTFS change journal and FindFirstChangeNotification. But the userland interface is kinda miserable and can cause you to miss events under load. You have to handle adding new files to the inotify watcher yourself, and if you move a lot of files at once, you will miss some of the changes. You can tell when you miss a change, but not what the change itself was, meaning you're back to doing directory scans.

tl;dr: Windows makes doing this easy. Linux adds functionality but makes it hard to do without extra work.

I find it pretty understandable that no-one has written a written a linux version of everything and wouldn't expect one in the near future.

There was one file searcher - beagle, I think - that did the work needed, but it hasn't been maintained in 10 years. I started to write one a couple of years ago, but when time came to start putting together a user interface I just kinda quit.

[Antbat]

I wonder why Microsoft hasn't bought it from Voidtools. Their included search engine is a joke compared to Everything.

[horst.epp]

I wonder why Microsoft hasn't bought it from Voidtools. Their included search engine is a joke compared to Everything.

The Windows search is not only indexing file names like Everything
it does index contents for may formats (depending on installed software and IFilters).
It runs fine if correctly configured and is not a problem on todays Hardware in actual Windows 10.
I use both Everything and Windows search of course.

[4c3T]

Hi. Currently also looking for a Linux version, and I had this idea, of sorts.

I use both Windows and Linux, and for the latter I'm a bit of a n0ob, but not quite relevant to this idea that I had.

It would be super-sweet if a service could be set up on a Linux box to have it run file list updates, then use a network connection to broadcast it, instead of having the Windows-machine running these updates over mounted (network) drives, which consumed resources (although, not much, but adds to delays and such), and I would imagine a server-client communication would cut down on time considerably.

I'm not keen on shortening down the update time as it would mean more traffic over the network. Currently set for 3 minutes, but some +20 TB takes time to traverse, and there's no detection for updated/removed/added files as it would be if run locally, so it's sometimes painstaking to wait for it to complete its update.

Anywho, this feature might be something that could benefit many out there looking to have a Linux file server and need to being able to search for files.

Edit: Just realized a potential problem.
How would pathways to server relative to Windows work? <-Rhetorical
Could some ID-system be implemented, without affecting CPU/RAM for this, or would just a conversion for pathways (/ vs \) suffice?

[3xploiton3]

hi, 2024 here

we hope everything present in linux, i cannot live without it
this is why i use dual boot windows 11 and arch linux

[ChrisGreaves]

I dont think its directly possible as Everything uses NTFS meta info to get the insane speeds.

Hi metavoid. Insane speeds is great, no doubt about it, but ...
Some twenty-plus years ago I read a report (can't find it now or I would link to it) from Sun Micro-systems about user file usage. Statistically it can be approximated as "Users access of the files modified more than six weeks ago (older files) account for onky 3% of the user's access requests".
The result was a three-tier file system (1) local and network fast hard disk (2) slower massive disk storage (3) tape archives.

The bulk of a user's files were available on fast disk.
A few file requests had to be brought in from slow disk.
A very few had to come via a request to (automatically) load a tape cartridge.

There was a cute link mechanism that, when your file was relegated to slower storage, the original location was replaced with a shortcut-link, but anyway ...
I have 291 files called WhatFAQ.DOC of which the most recently modified is T:\Pers\WeightLoss\Recipes\WhatFaq.doc because it is summer-time and I am busy bottling rhubarb, bottling jam, and pretty soon bottling beets. Once winter time comes, that file will slip down the list to an inferior position. If in winter-time I open a jar of baked beans that is not so good, I would tolerate a small penalty of five seconds to open that same file just to edit the specific recipe ("10387") to avoid making THAT mistake again. Five seconds is a small price to pay to save four hours of a new batch of inedible baked beans, yes?

Everything's blindingly-fast response time is welcome and admired, but realistically I often think that the fact that Everything can FIND a file (by size, content, word-count, duration or whatever) is what counts more than Milli-second response time. I'm OK waiting five seconds to find a file I wrote twenty years ago about, say, The Goldfields Water Supply.

I suspect that these arguments will apply to the (currently) fastest available file search program under Linux.
What will really count is the user-interface, the means of specifying a request, rather than the response time.

Cheers, Chris

[mvdeckard]

I wonder why Microsoft hasn't bought it from Voidtools. Their included search engine is a joke compared to Everything.

Thank god,