Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fsearch, a fast file search utility for Unix-like systems

github.com

Post reply on HN
Print view View original

71–80 of 98 posts

Re: Fsearch, a fast file search utility for Unix-like systems

#71

Post by darkwater »

atoav wrote: post #51
drekipus wrote: post #5

Earlier quoted context omitted.

rg or fd?

rg if you want to find stuff in files 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/l…

If you want to put this (fantastic, thank you very much for it!) command in your git toolbox, personally I did it like this:

1) 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`.

Re: Fsearch, a fast file search utility for Unix-like systems

#73

Post by Beijinger »

wander_homer wrote: post #69
Beijinger wrote: post #30

"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." https://www.lesbonscomptes.com/recoll/pages/index-recoll.htm... "Recoll finds documents based on their contents as well as their file names." "Recoll…

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 dat…

"FSearch is primarily built to find files on the entire system instantly "

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.

Re: Fsearch, a fast file search utility for Unix-like systems

#74

Post by wander_homer »

smcleod wrote: post #72

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.

Re: Fsearch, a fast file search utility for Unix-like systems

#75

Post by QuadrupleA »

berkes wrote: post #56
QuadrupleA wrote: post #38

Earlier quoted context omitted.

Too much research and extremely low level troubleshooting required (i.e. source code reading) to get things working. Especially around wayland, multi-monitor, multi-GPU, Nvidia, etc. I hate what Microsoft has been doing with Windows, but Linux just isn't practical for my setup yet.

You are either extremely unlucky or chose a very strange setup. 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 o…

I'm not new to all this - I used Slackware and Red Hat on the desktop in the early 2000s, and I use Linux on the server side daily. But on two separate laptops recently, manufactured 10 years apart, I've had all kinds of glitches and performance problems with (Arch) Linux, on a variety of desktops (Sway, KDE Plasma, Gnome) especially around video and GPU. You could say just don't buy Nvidia - but one, too late, and two, if you want to do anything interesting in AI these days they're hard to compete with.

YMMV and if you're just in the shell and in VIM all day you might not notice video glitches and performance problems (computers did text terminals in the 70s so it's not a high bar). But as a lapsed game dev I have an eye for stutter, missed frames, etc, and those were pretty constant in my configs, despite sinking probably a hundred plus hours in, time I won't get back.

Re: Fsearch, a fast file search utility for Unix-like systems

#77

Post by rkagerer »

RachelF wrote: post #4
dzek69 wrote: post #3

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 lea…

Me too - strangely, one of the reasons I stay on Windows is Everything ( https://www.voidtools.com/ ) - it is just so useful.

I had Everything installed but didn't use it as much as expected. I've gravitated toward FileLocator Pro instead, which uses extremely fast metadata table searching instead of requiring an index (I don't use the Agent Ransack features).

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...)

Re: Fsearch, a fast file search utility for Unix-like systems

#78

Post by mistercow »

pvtmert wrote: post #66
mistercow wrote: post #15

Earlier quoted context omitted.

That's just a cli for Spotlight, right? I have found Spotlight to be increasingly unreliable over the years, to the point of being essentially useless now. Most recently, I discovered that absolutely nothing in my iCloud drive can be found with Spotlight, even if the file is on disk and I'm just trying to match its name. For extra fun, I found an Apple support page that suggested the Windows-in-1999-esque procedure o…

if you do not have the "show all file extensions" enabled, `.md` query in spotlight will not show up anything. 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)

It also doesn’t work without the extension. It does work on my work laptop, so I expect that something is broken with my index. But this is also part of the problem. The whole thing is opaque, breaks, and offers no clear recourse for how to resolve any issues.

Re: Fsearch, a fast file search utility for Unix-like systems

#79

Post by lelanthran »

CyberDildonics wrote: post #22
wander_homer wrote: post #13

Earlier quoted context omitted.

Author here. The app works in two steps: 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 syste…

This is simply done by walking the filesystem. 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 thin…

> Everything scans the filesystem very fast and there is no way it is just using 'stat' on every file then diving into the directories.

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.

Re: Fsearch, a fast file search utility for Unix-like systems

#80

Post by CyberDildonics »

lelanthran wrote: post #79
CyberDildonics wrote: post #22

Earlier quoted context omitted.

This is simply done by walking the filesystem. 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 thin…

> Everything scans the filesystem very fast and there is no way it is just using 'stat' on every file then diving into the directories. 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 providin…

What you are talking about is file change notifications. A huge part of Everything's speed comes from reading the master file table that other people mentioned, so you would need a way to quickly read file table entries on linux.

https://learn.microsoft.com/en-us/windows/win32/devnotes/mas...

Post reply on HN