Everything for linux ?
Everything for linux ?
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!
Thank you!
Re: Everything for linux ?
A search for "Linux" on this forum return this thread:
viewtopic.php?f=2&t=6819&p=21694&hilit=linux#p21694
viewtopic.php?f=2&t=6819&p=21694&hilit=linux#p21694
-
- Posts: 2
- Joined: Sat Jul 07, 2018 9:45 pm
Re: Everything for linux ?
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.NotNull wrote:A search for "Linux" on this forum return this thread:
viewtopic.php?f=2&t=6819&p=21694&hilit=linux#p21694
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?
Re: Everything for linux ?
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)
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)
Re: Everything for linux ?
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?
Isn't there a search tool for Linux? Something that makes folder&file indexing the same way Folder Indexing works?
Re: Everything for linux ?
how about fzf https://github.com/junegunn/fzf
-
- Posts: 2
- Joined: Sat Jul 07, 2018 9:45 pm
Re: Everything for 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.
Re: Everything for linux ?
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).
Re: Everything for linux ?
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/
Re: Everything for linux ?
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.
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.
Re: Everything for linux ?
I wonder why Microsoft hasn't bought it from Voidtools. Their included search engine is a joke compared to Everything.
Re: Everything for linux ?
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.
Re: Everything for linux ?
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?
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?