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.
> 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?
But I really welcome any sort of contribution. For example there's also things like improving the main interface language (English isn't my first language, so there's likely room for improvement there), helping with support questions and bug reports, artwork, ...
Not a Linux expert, but out of curiosity did you try Recoll when you looked at other platforms? (https://www.lesbonscomptes.com/recoll/pages/index-recoll.htm...)
It has a few other qualifiers, like big: huge: etc to search large files. Same way with time etc.
Rarely when you need it you prefix with regex: and you get everything you need.
It's very useful that both everything and fluent search integrate into explorer in that if you right click on the search result you get the same context menu as you would in explorer. Drag drop works, etc,. The issue with every other tool in every other OS is the lack of this feature. You basically have a virtual fully featured directory for every search result, simply cannot beat that.
After that I mostly just use "pic:" or "path:".
fd if you want to find stuff in filenames
fzf for when you want a fuzzy menu type of search on top of this.
I can't recommend fzf enough you can do some really powerful stuff with it. If you don't know it: it gives you a fuzzy search on things you pipe into it. It is powerful because it also can do things like running special commands ("preview") on the currently selected entry/line and allows for displaying the output in a separate pane.
So you could build a thing that e.g. let's you search and multiselect (enqueue) your music collection and on each entry display audio metadata using a custom script.
Or a blazingly fast PDF-content searcher that opens the PDF in the end. The possibilities are endless.
Edit: Here a short video showing my basic git log alias: https://youtu.be/9W27D8lrn-s
gl: aliased to git log --all --pretty=oneline --pretty=format:"%Cgreen%h%Creset %s %Cred%d%Creset" --color=always | fzf --ansi --preview 'git show --pretty=medium --color=always $(echo {} | cut -d" " -f1)' | cut -d" " -f11) create an executable script called `git-l` and put it in a place in your PATH, and make it executable 2) use `git l` to invoke it
You will avoid escaping hell and you can even expand/complicate it much more. The same extension principle works with other CLI tools like `kubectl`.
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."
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.
I am not sure, but I think my Bodhi "everything starter" solves this problem for me. If I look for something more specific, I use recoll.
I miss Everything :(
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 :)
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.
This is the part I'm wondering about. Everything scans the filesystem very fast and there is no way it is just using 'stat' on every file then diving into the directories.
Are you just using stat from C to walk the filesystem or are you doing something else?
I've used sqlite to cache filesystem results and it is also extremely fast once everything is in there, but I think a lot of approaches should work once the file attributes are cached.
Then on subsequent starts it reads the NFTS update journal to see what changed.
The last time I checked, Everything worked by using the AV calls microsoft provides; anytime a file is written, the name (and other metadata) can be written to a log that Everything can check once every 5 seconds or so.
If I thought there was any money at all to be made from providing an Everything equivalent[1] on Linux, I'd spend the week or so to write it, but as far as I can tell there's just no market for something like this.
[1] By that I mean "similar in performance and query capabilities"; I would obviously need more time than that to hook into the common file-open dialog widgets (Gnome/KDE/etc) so that users could run their queries straight from existing file dialog widgets.
Everything is parsing a file called the MFT to build its index. This much more efficient but unfortunately this file only present on NTFS volumes, which makes it super useful on Windows systems, but not so much everywhere else.
Another benefit you get on Windows is the USN journal, which allows Everything to keep the index updated much more efficiently.
The GitHub page recommends mlocate for a CLI version.
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
Searches not only file names but in contents as well. Also blazing fast in my experience.
Edit: Or does it? https://ports.macports.org/port/fsearch/details/
Testing out mdfind and trying to simply find a file in a specific directory (which only contains five files):
mdfind -onlyin . name-of-my-file.md
mdfind -onlyin . -name name-of-my-file.md
mdfind -onlyin /absolute/path/to/cwd -name name-of-my-file.md
This is pretty reflective of my experience with the Spotlight GUI. Every search turns up something, but the file I want is almost never in the results.
I think MacOS is great. Many of the features are brilliant. The UI is second to none to this day.
But holy moly, Spotlight has degraded. From searching my files, to searching my files and the internet, to consistently providing me with nothing I am looking for.
When Apple first started selling OSX it's UNIX heritage was a part of the selling point but my vibe is that they only really consider text input a feature for devs. Which thinking of Mac's history is on brand but just leaves you down many a frustrating dead end.
try without extension. (eg: just the name)
I even have scripts to locate other scripts using mdfind, it is pretty robust to be honest...
Eg:
source $(mdfind -name spacelatte-bashlib.sh)No, not yet.
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.
I hate what Microsoft has been doing with Windows, but Linux just isn't practical for my setup yet.
The problems you describe were common in early 2000s, but haven't been common in Linux desktop for a decade or so.
For those reading above and thinking "I'll skip Linux, if that's the current status": it's not. Just pick Ubuntu LTS. Use it on common hardware (e.g not bleeding edge) and stick with the defaults. Don't try to make it exactly like your Mac or Windows machine but lean into how it does things. They are different . They may be uncomfortable. Then, once familiar feel free to tinker and hack.
I'm on Linux since 1996. I've hacked and tweaked everything in my younger years. Now I'm on a boring, hardly configured Ubuntu LTS. Well, my she'll and nvim are tuned beyond recognition, I guess. The rest: boring.
Even Linux branded laptops keep having issues, example on the one I still have around, I never got around fixing it dropping wlan connections, so for large OS updates it needs to be plugged on the LAN.
Multi monitor support should generally be fine in most desktop environments, at least for 2 screens. More than that can indeed be quirky, dependent on the desktop environment and window manager (X or Wayland) you're using.
Multi-GPU is probably a bit niche to have good driver coverage, partly probably because of the Nvidia issue.
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.
There are a couple of other filename-only apps with own index, but don't remember now which of the alternatives do that (HoudahSpot?)