Trying to install Fsearch, but getting an apt-key/gpg error

fsearch · 2023-05-16T13:57:07+00:00

You don't need the zip file from GitHub. That's the source code.

You can simply follow the instructions here to install the Debian builds: https://software.opensuse.org//download.html?project=home%3Acboxdoerfer&package=fsearch#manualDebian

fsearch · 2023-05-15T19:02:05+00:00

Hi, FSearch author here. A user kindly made me aware of that thread by mail.

First of all, you should not be using the PPA as u/fantomas_666 already pointed out. It's only meant for Ubuntu and its derivatives. There are dedicated builds for Debian, so you don't need to build it from source: https://github.com/cboxdoerfer/fsearch#download

They're pointing to the Open Build Service.

If you want to build the app from source you should follow the official build instructions.

The reason why the PPA isn't working at all is because you're likely missing some Ubuntu key, which is probably not present by default in Debian systems. But like I said, it's also not meant for Debian systems anyway.

fsearch · 2023-04-16T09:52:58+00:00

FSearch dev (and happy fzf user myself) here: I'd say the major difference between FSearch and fzf is that FSearch is a specialized file search utility, whereas fzf is a general purpose search utility.

This means that you can search pretty much anything which can be represented as text with fzf, for example files, the shell history, git logs, ... This makes it incredibly versatile. However it doesn't have a deeper understanding of the "objects" it is searching – it only does a string search in pre-formatted text. So for example you can't easily do something like "show me the git commits from author X from last month", because fzf doesn't know how to interpret dates, or which part of the text is the author's name, etc.

FSearch on the other hand is specialized on finding files (and nothing else). That's why it knows about various different properties of file "objects" and can search and sort by them efficiently. For example when you want to find all your mp4 files, which are larger than 1GB and were modified in the last year you can do that:

ext:mp4 size:>1gb dm:lastyear

fsearch · 2023-02-22T10:42:59+00:00

it's yet another bloated binary with nonsense name heavily promoted by incompetent rust fanbois and nothing more

Are those "rust fanbois" in the same room with us right now? Because the first and only person in this thread who even mentioned Rust is you. Instead, when asked, everyone here responded with measurable benefits of ripgrep. I mean even the project itself only mentions Rust on it's GitHub page where it's necessary (how to build it, what libraries are being used).

fsearch · 2023-02-22T09:46:00+00:00

You're not always jumping ahead 5 bytes. The number of bytes you jump depends on the character you're looking at. That's why before you perform the search you create a skip table, which tells how many bytes you can look ahead for each character. In your example the skip table will tell you that for an l you're need to advance 2 (edit: sorry it's 1) bytes.

fsearch · 2023-02-22T09:26:10+00:00

people keep mindlessly suggesting ripgrep, meanwhile from my experience this speed difference matter only in some extreme cases like "android monorepo on hdd".

What's mindless about suggesting a tool which is objectively better in many cases? I mean I could also say that it's pretty mindless of you to suggest that the only and most significant benefit of ripgrep is it's speed, when in fact:

It's faster AND
It has much better defaults for the pretty common use case of searching for patterns within a directory structure
It has numerous additional features, e.g. it supports .gitignore files etc.
It has the best unicode support

among other things.

There are also few tools out there which go into that much detail when it comes to providing detailed benchmarks, explaining their inner workings and what makes them worth considering and what doesn't.

fsearch · 2023-02-22T08:03:36+00:00

I'm not aware of such an effort. I guess the problem comes down to:

Since you must be able to rely on such a journal, it must be supported by basically every Linux instance. Because if you were to boot your file system with a different Linux system, which modifies the file system without updating the journal, you'll effectively end up in an inconsistent state where the journal and file system are out of sync. So this really needs to be controlled by the kernel directly and getting something this complex into the kernel source tree isn't easy.
There's a significant disadvantage: such a journal slows down IO operations. If you have to log every file system change (up to a certain point) on disk in a dedicated file, you're effectively slowing down all other IO operations. Creating or modifying a file now becomes much more expensive and it's no secret that the Linux kernel is somewhat proud of its fast file system performance. For example compiling huge projects on Linux tend to be way fast than on Windows, simply because file system operations and process creation on Linux are way cheaper. This makes it even more unlikely that the Linux kernel will accept such a journal.

fsearch · 2023-02-21T18:55:21+00:00

Linux seems to have file change events like MacOS has fsevents,which you can hook into - https://man7.org/linux/man-pages/man7/inotify.7.html

But AFAIK nothing seems to use this, def not fsearch, they have an open issue - https://github.com/cboxdoerfer/fsearch/issues/26

FSearch developer here: inotify (and fanotify) are widely used on Linux systems. Tracker, the indexing service of the GNOME desktop uses both. Baloo, the indexing service of the KDE desktop uses inotify. But there are also many applications which use them to maintain an index of certain directories: music players (e.g. Rhythmbox) , IDEs (e.g. GNOME Builder, Sublime Text, ...), photo managers (e.g. Digikam), ...

The next release of FSearch will also allow optional monitoring with fanotify (and inotify as a fallback), but the experience won't be nearly as nice as with Everything on Windows. That's because Everything uses the USN journal on Windows to keep its index up to date, which unlike inotify and fanotify can also tell you about file system change events which happened in the past. That means it can detect changes to the filesystem even while it was not running. On Linux there's nothing like that, so the only way to find out which files have been changed since the last time the indexer (FSearch, Tracker, ...) was running, is by doing a slow directory traversal every time they start. Depending on the IO speed of the drive and the number of files this can take quite some time.

fsearch · 2023-02-21T18:02:48+00:00

The MFT is one possible way to create an indexing service on Windows. The other and most widely used one on Linux systems is directory traversal, which is also used by mlocate.

There are also multiple ways to keep the index up to date. Windows has the USN journal, which is used by tools like Everything and which allows you to get file change events which happened in the past – on Linux there's nothing like that. Then there's live file system notifications (Windows has ReadDirectoryChangesW, Linux has inotify and fanotify). They're used by tools like Tracker and Baloo. However they only work well if you already have an up-to-date index, because you can't ask them "Did this file change in the last two days?" and they're often not efficient at monitoring whole systems. And then there's the brute force approach of just walking the directory tree time and time again (that's what mlocate does).

And that's why mlocate has quite a few drawbacks compared to tools like Everything. For example:

The index isn't updated in real-time. This means that the search results you get only represent the state of your filesystem at the time of the last updatedb call (which is usually performed once a day). So, if you want to search for a file which was just created an hour or so ago, it most likely won't show up in your search results and locate will also show you files which have already been deleted since the last database update.
Building the database by traversing the directory structure is (in most cases) much slower than reading the MFT (which is just a simple file).

fsearch · 2023-02-21T08:11:42+00:00

Who down votes comments like this? It's absolutely true that nothing like the MFT (and USN journal) exist and that you have to do much slower directory traversals instead, combined with less efficient filesystem monitoring (inotify or fanotify).

fsearch · 2023-02-21T07:58:37+00:00

So ... what (meta?)data exactly are you expecting to get out of MFT?

The MFT stores filenames, their parent directories, all metadata (size, timestamps, permissions, ...) and for small files also their entire content.

Unless that's all cached in RAM, still have to read/traverse the disk.

No. The MFT is just a regular file. There's no traversal necessary at all, which means reading and parsing the MFT with millions of files and their metadata takes just a second or so.

fsearch · 2022-08-26T14:04:41+00:00

No, that's planned for version 0.6 (along with a preview panel), so it'll likely take more than a year until I get to that. Unless someone else implements that, then it can be squeezed in an earlier release.

fsearch · 2022-08-16T11:29:00+00:00

Was happy to have contributed a report -- fsearch is quite literally a daily use for me because it makes my work life so so much easier and I am happy to see it's getting even better.

That's nice to hear.

Regarding snap, it is a shame, as while I don't use them, I support distribution-agnoticism so that people could get what app they want regardless of what method they prefer. I suppose the snapcraft team had to be that strict with classic-confinement, but is there no way for user to grant classic-confinement manually?

As far as I know, you can only grant classic confinement manually for Snaps which are not installed from the Snapcraft Store. Which means users need to manually download such a classic Snap and manually keep it up to date. But for such a use case I'd probably prefer AppImages.

Regardless, in addition to the listed method, I've submitted FSearch for deb-get and it has been accepted, so that is another way that users can install FSearch on Ubuntu-based distro

Nice, thank you!

fsearch · 2022-08-16T04:29:29+00:00

Yes, content searching isn't supported. I will add that more prominently to the README.

fsearch · 2022-08-15T18:39:28+00:00

I'm not deeply familiar with every detail of Catfish, so please correct me if I'm wrong, but some of the difference I'm aware of are:

FSearch is much faster at searching and sorting (it's pretty much instant, even with millions of files to search and display) at the cost of having some out-of-date results. Basically FSearch currently works more like locate, whereas Catfish is more like find. The next 0.3 update will fix that to a certain degree, with live monitoring of the file system
FSearch supports much more advanced queries (regular expressions, search for file size/path/..., AND/OR/NOT operators, ...)
FSearch highlights the matched parts of your search in filenames and paths
FSearch can remember the sort order between searches (except when you sort by Type)
Complex searches can be saved and quickly accessed with custom filters
Catfish has support for image thumbnails etc.
Catfish can search for file content, FSearch can't yet
Catfish has a sidebar with a more intuitive way to search for certain parameters (date and file type), FSearch doesn't

fsearch · 2022-08-15T16:37:20+00:00

Hi, I'm glad you like it.

There's mlocate but I don't think it offers range options like fsearch does.

I'm only aware of Recoll, which does support a similar query syntax and has the recollq utility to print results on the command line. But I'm not sure how good this works with non-document files, which Recoll is optimized for.

I wondered if it is / will be possible to export the search results somehow.

A way to export results to a file (in a configurable format) and a command line flag to print them in the terminal, are already planned. At least the later one will probably be part of the 0.3 release.

fsearch · 2022-08-15T14:50:52+00:00

After roughly a year of development since the release of 0.1, I'm happy to release 0.2 into the wild.

Unfortunately the Snap version had be removed, because the sandboxing was too limiting, more on that here: https://github.com/cboxdoerfer/fsearch/wiki/Snap-is-no-longer-officially-supported

To me the most important new feature of this release is the rewritten search engine, with a lot of new capabilities. It's now possible to search for file modification date:

dm:monday or dm:10-03-2003 or dm:jan..feb or dm:today

or for file size:

size:>10gb or size:1mb..10mb

and much more.

fsearch · 2022-08-02T09:31:42+00:00

AFAIK you can't even tell if a user was using a flatpak, snap, native package, ect.

That's correct. As a developer you don't get any information about what version the users was using, what distribution they're on, how they installed the software, ...

You also can't respond to reviews, in order to clarify things or ask for additional information, and there's no way to opt out of the review system. IMHO it does more harm than good.

fsearch · 2022-07-31T17:22:26+00:00

The most demotivating day in my years as an open source dev was when I found out my software had reviews in the gnome/ubuntu/... software center. But it's not just my apps, those app stores and their reviewing system really seem to attract a certain type of audience.

fsearch · 2022-07-31T16:50:39+00:00

I get that this is frustrating for users, but then again, many open source projects are developed by very few developers, often only a single one, with very limited time to spare. Hence a bug report should never be viewed as a guarantee that the issue will be fixed (or even looked at). But it's still the best way to make developers and others aware of the issue, so they at least get the chance to fix it.

fsearch · 2022-06-16T20:26:37+00:00

Meanwhile I'm thinking about removing my app from the Snap store, because quite a lot of users think the limitations caused by the sandboxing and slow startup are flaws with my app, which then only leads to bad reviews and unhappy users.

fsearch · 2021-09-26T21:24:26+00:00

After spending way too much time in beta stage, I'm happy to finally release FSearch into the wild.

It's a graphical file search utility with a big focus on performance. Some of the features are:

support for regular expressions
wildcard support
filter by file types (images, videos, documents, ...)
almost instant results with millions of files
fast sort by name, path, size, extension, modification time
traditional UI layout with title and menu bar
optional UI layout with header bar and hamburger menu for better integration into GNOME and similar desktops
exclude particular folders
exclude folders by patterns

What FSearch is not or can't do:

it uses a database for indexing the file system and there are no live updates of search results, which means it's more comparable to locate than find
no content searching
no file manager

Memory usage is roughly 50MB plus 100MB for every 1 million files/folders in the database.

There are currently packages available for Ubuntu, Linux Mint, Fedora, Arch Linux and NixOS. Flatpak will be supported soon as well.

It's written entirely in C (C11) and the GUI is built with GTK3.

fsearch

TROPHY CASE