This is great tool, I use it everyday, but far from it's Windows based original Everything.
Also this is anbandoned apparently, which makes me extra sad, because it lacks few crucial features like:
- being able to just remove a file from the index if you delete it from the app directly (insted it shows a window how it "soon" gonna be implemented)
- while i understand that indexing service is more complex job - at least caching the index would be nice, because right now when i start the app i have to wait for it to index everything again, but usually i search for files that exists for a long time, not these that was created between my fsearch uses
So yeah. Cool dead and incomplete piece of software ¯\_(ツ)_/¯ From time to time I look for better alternative, if you happen to know one - let me know.
Hi, I'm the author of this little piece of software.
> Also this is anbandoned apparently, which makes me extra sad, because it lacks few crucial features like:
PersonalIy I wouldn't call it abandoned. I'm still working on it — not as often as I'd like to, but I'm still making progress towards the next release. Though it's still months away from being released.
> - being able to just remove a file from the index if you delete it from the app directly (insted it shows a window how it "soon" gonna be implemented)
That feature is already implemented, but there are no official builds with it yet, because other parts of the software haven't been updated after the rewrite of the database engine (e.g. loading/saving the database file is broken at the moment). Once the old feature set is working again, I'll publish the first official dev builds of the 0.3 release.
> while i understand that indexing service is more complex job - at least caching the index would be nice, because right now when i start the app i have to wait for it to index everything again, but usually i search for files that exists for a long time, not these that was created between my fsearch uses
This is already supported and part of the stable releases. The index is cached and loaded upon application start, so you can search right away, even while the new index is being built. You can also disable auto index updates when the application is launched, if you prefer manual or scheduled index update instead. Or do you mean something else?
Last commit 2 weeks ago? Doesn't look dead. Perhaps not actively developed by original author but seems they're still acting as a maintainer and willing to take PRs.
"Performance. On Windows I really like to use Everything Search Engine. It provides instant results as you type for all your files and lots of useful features (regex, filters, bookmarks, ...). On Linux I couldn't find anything that's even remotely as fast and powerful."
"Recoll finds documents based on their contents as well as their file names."
"Recoll will index an MS-Word document stored as an attachment to an e-mail message inside a Thunderbird folder archived in a Zip file (and more… ). It will also help you search for it with a friendly and powerful interface, and let you open a copy of a PDF at the right page with two clicks. There is little that will remain hidden on your disk."
Recoll serves a different purpose as it's primarily build to index and search within your personal documents. That's why it doesn't work well when you point it to the root folder, in an attempt to search within the entire system of millions of files and that's also the reason why it's not as fast, since it's doing more work (parsing complex file formats, searching within a more complex database structure and more data, ...).
FSearch is primarily built to find files on the entire system instantly (by that I mean that all results should be ready by the time you press the next character while typing), based on their name, size, time, filetype, etc. This is less work than what Recoll does and that's why it is much faster.
Do any of the modern filesystem on Linux cover this very important use case of instant search anywhere like the good old NTFS does (that's how you get Everything's awesome performance)?
fsearch is the best locate front-end for Linux, but sadly, I've got many gripes with it... crappy drag'n'drop, no daemonization to minimize to system tray, closing the app resets the clipboard for some reason (EXTREMELY annoying when you open it to copy a file path), the list is long. Not to mention that locate itself doesn't auto-update the index with fs changes.
Not to detract from your overall point, but the app is not resetting the clipboard. In X11 if you close any app, you lose anything you copy from it. This is because in X11 windows do message passing to emulate a clipboard. Your browser say and fsearch send messages to each other to send data in few KB chunks(yes there's an incremental transfer protocol where you have to support all kinds of irrelevant clients even if the last such client died before the turn of the century) So when one of the windows closes, it's gg. It's a pretty convoluted over-engineered idea when instead a single file ~/. clipboard would have sufficed.
Step one is building an index of the file system. This is simply done by walking the filesystem. The resulting index is stored in RAM and a file. On the next app start the index ia loaded from that file, which is much quicker than walking the file system.
Step two is using this in RAM index for searching. This scales really well with the number or CPU cores and on modern systems a normal case insensitive substring search should finish almost instantly with few million files.
The next release will support file system monitoring with inotify and fanotify to keep the index updated. Although this has some drawbacks.
Does it support find in files? I am using catfish and looking for alternatives but find in files would be a must have. Some are recommending fzf (rg, fd). What is your search workflow and what tools do you use?
It’d be interesting if this could integrate with plocate (mlocate’s replacement) which is incredibly quick at indexing and returning results but relatively basic.
You mean like being able to read the plocate database with FSearch? I don't see much point in that, because the plocate database is missing some crucial data, which FSearch uses to make searching and sorting quicker. For example file attributes like size or modification date and the sort order by various attributes (name, path, size, ...) aren't indexed by plocate.
If plocate is faster at building the index, it probably makes more sense look at what's the reason behind that and add these improvements to FSearch.
For anyone looking for a Mac equivalent, there's GoToFile[0].
As far as I've seen, this is the only app for Mac that doesn't just reuse Spotlight search (which I find to be terrible). I looked for exactly this type of app for years before finding it, and when I did, it didn't seem real with the old-fashioned website and zero mentions on sites like HN. But I can assure that it works great and it's maintained. I just wish the author would promote it better so it gets more attention and isn't so hard to find.
+1 on the need for non-Spotlight options. Source code makes a mess of spotlight for everyday usage. I like Leap a lot for multimedia browsing with more precise search capabilities than spotlight: https://ironicsoftware.com/leap/
Soma-zone software in general is pretty neat for Mac power users. I especially like Launch Control, which lets you configure and inspect launchd (the mac service daemon) services.
dzek69|2 years ago
Also this is anbandoned apparently, which makes me extra sad, because it lacks few crucial features like: - being able to just remove a file from the index if you delete it from the app directly (insted it shows a window how it "soon" gonna be implemented) - while i understand that indexing service is more complex job - at least caching the index would be nice, because right now when i start the app i have to wait for it to index everything again, but usually i search for files that exists for a long time, not these that was created between my fsearch uses
So yeah. Cool dead and incomplete piece of software ¯\_(ツ)_/¯ From time to time I look for better alternative, if you happen to know one - let me know.
wander_homer|2 years ago
> Also this is anbandoned apparently, which makes me extra sad, because it lacks few crucial features like:
PersonalIy I wouldn't call it abandoned. I'm still working on it — not as often as I'd like to, but I'm still making progress towards the next release. Though it's still months away from being released.
> - being able to just remove a file from the index if you delete it from the app directly (insted it shows a window how it "soon" gonna be implemented)
That feature is already implemented, but there are no official builds with it yet, because other parts of the software haven't been updated after the rewrite of the database engine (e.g. loading/saving the database file is broken at the moment). Once the old feature set is working again, I'll publish the first official dev builds of the 0.3 release.
> while i understand that indexing service is more complex job - at least caching the index would be nice, because right now when i start the app i have to wait for it to index everything again, but usually i search for files that exists for a long time, not these that was created between my fsearch uses
This is already supported and part of the stable releases. The index is cached and loaded upon application start, so you can search right away, even while the new index is being built. You can also disable auto index updates when the application is launched, if you prefer manual or scheduled index update instead. Or do you mean something else?
eredengrin|2 years ago
RachelF|2 years ago
rand0mx1|2 years ago
https://news.ycombinator.com/item?id=33816014
hiAndrewQuinn|2 years ago
drekipus|2 years ago
Beijinger|2 years ago
https://www.lesbonscomptes.com/recoll/pages/index-recoll.htm...
"Recoll finds documents based on their contents as well as their file names."
"Recoll will index an MS-Word document stored as an attachment to an e-mail message inside a Thunderbird folder archived in a Zip file (and more… ). It will also help you search for it with a friendly and powerful interface, and let you open a copy of a PDF at the right page with two clicks. There is little that will remain hidden on your disk."
wander_homer|2 years ago
FSearch is primarily built to find files on the entire system instantly (by that I mean that all results should be ready by the time you press the next character while typing), based on their name, size, time, filetype, etc. This is less work than what Recoll does and that's why it is much faster.
That's why I also use both tools.
eviks|2 years ago
OvbiousError|2 years ago
apt-get|2 years ago
I miss Everything :(
porridgeraisin|2 years ago
For a more articulated rant from 20 years ago, see the rant file in https://github.com/porridgewithraisins/x11cp. Also shameless plug.
To fix this, use a clipboard manager. Also shameless plug https://github.com/porridgewithraisins/coffee-pesto :)
CyberDildonics|2 years ago
wander_homer|2 years ago
Step one is building an index of the file system. This is simply done by walking the filesystem. The resulting index is stored in RAM and a file. On the next app start the index ia loaded from that file, which is much quicker than walking the file system.
Step two is using this in RAM index for searching. This scales really well with the number or CPU cores and on modern systems a normal case insensitive substring search should finish almost instantly with few million files.
The next release will support file system monitoring with inotify and fanotify to keep the index updated. Although this has some drawbacks.
jcul|2 years ago
The GitHub page recommends mlocate for a CLI version.
wander_homer|2 years ago
Likely the most significant benefit is the more powerful query language. For example you can also search by file modification date or size and use boolean operators. https://github.com/cboxdoerfer/fsearch/wiki/Search-syntax
soundarana|2 years ago
WebTDs|2 years ago
Searches not only file names but in contents as well. Also blazing fast in my experience.
pacifika|2 years ago
croemer|2 years ago
Edit: Or does it? https://ports.macports.org/port/fsearch/details/
paradox460|2 years ago
liotier|2 years ago
ensocode|2 years ago
wander_homer|2 years ago
No, not yet.
smcleod|2 years ago
wander_homer|2 years ago
If plocate is faster at building the index, it probably makes more sense look at what's the reason behind that and add these improvements to FSearch.
einpoklum|2 years ago
QuadrupleA|2 years ago
ivanjermakov|2 years ago
pjmlp|2 years ago
carpo|2 years ago
aikinai|2 years ago
As far as I've seen, this is the only app for Mac that doesn't just reuse Spotlight search (which I find to be terrible). I looked for exactly this type of app for years before finding it, and when I did, it didn't seem real with the old-fashioned website and zero mentions on sites like HN. But I can assure that it works great and it's maintained. I just wish the author would promote it better so it gets more attention and isn't so hard to find.
[0] https://www.soma-zone.com/GoToFile/
code_biologist|2 years ago
optimalquiet|2 years ago
monroewalker|2 years ago
eviks|2 years ago
There are a couple of other filename-only apps with own index, but don't remember now which of the alternatives do that (HoudahSpot?)
unknown|2 years ago
[deleted]