Beta Release: 0.3-beta1

[cboxdoerfer]

After a long time in development, the 0.3 release is finally just around the corner. The main feature in this version is support for filesystem monitoring.

Up until version 0.2, FSearch was a relatively simple application under the hood: the in-memory database was built once at startup and remained unchanged afterward. This made both the data structures and the search logic straightforward, since everything operated on a static dataset.

With the introduction of filesystem monitoring, this became much more complex. The application is now much more dynamic, with the database being updated continuously as files are created, modified, moved, or deleted. This brings a number of new challenges: keeping the index in sync with the filesystem in real time, handling bursts of changes efficiently, and ensuring that searches remain fast and consistent even while updates are happening in the background.

While this adds quite a bit of complexity internally, the goal is that it remains almost invisible to users.

Here are the major changes:

• The database has been almost completely rewritten. When you launch version 0.3 (beta) for the first time, it will start empty, so you’ll need to re-add your folders. To keep the codebase manageable, backwards compatibility with previous database versions has unfortunately been dropped.
• Filesystem monitoring can now be enabled per folder via the preferences dialog by checking the “Monitor” column.
• Monitoring is only available on platforms and filesystems that support fanotify or inotify and even though fanotify works great for huge directory trees, I don't recommend to monitor the root directory itself.
• In testing, the database handled tens of thousands of changes per second without issues, but more feedback here would be appreciated.
• Database exclusions have been improved: files and folders can now be excluded using fixed patterns, wildcards, or regular expressions.

---

This discussion was created from the release Beta Release: 0.3-beta1.

[Benedikt81]

This is really great news! Finally, there will an equivalent to the mighty Everything on linux. Working on a system with HDD and SSD I especially like the fact that I can activate the monitoring feature on a folder-basis.

Regarding the includes and excludes, maybe you can put in the release notes and the help that these settings are currently in the (~/.config/fsearch/)fsearch.conf) and/or find a way to backup the file during the update.

In any case, thanks a lot. I don't use fsearch too often right now, as my home directory is on the hdd and it takes ages to update the index. I will definitely use it on a daily basis.

[kajodowe]

Hi Christian -- I am just an average user and I have finally successfully installed this Beta. Everything working fine now. I am in the US and when I tried to open FSearch this morning (April 12 2026) it would immediately close. I finally found your page here with downloadable Flatpak and downloaded it. Had to work on being able to use Flatpak since I don't regularly use it. But after that I finally successfully installed FSearch and added my folders.

[kajodowe]

It's me again! I posted the following on the 'Issues' tab as a comment from a previous posted item regarding Flatpak. I'll just repeat it here: "Hi -- writing this on April 13 2026. I've got the 0.3 Beta version and all is well except for the "Open With" issue. In my case when I click on a file to open from FSearch I always get the "Open With" query although I already have established what applications open what files. This 'Open With' query doesn't happen anywhere else at this time. Could it be related to the fact that I installed via Flatpak?"

[atrugiel69]

This is awesome, awesome news. Thank you so much for this new development. Real time monitoring is incredible and brings back basically everything made Everything great on Windows.

What's the correct way to implement fsearch so that it runs in the background, for monitoring to be effective?

I see that if I launch it and then hide it using the Escape key, it remains loaded in memory (with a very reasonable memory footprint). This is probably due to "exit_on_escape=false" in fsearch.conf. But I don't see any option to start at reboot and I would also prefer for fsearch to start already in the background, without showing its window every time I reboot the machine.

But, once more, first of all and last of all... THANK YOU!

Edit: found your PayPal link and I took the pleasure of sending you a small donation as a token of appreciation.

Edit 2: and pressing Escape simply minimizes to the taskbar. Ideally it would go to tray, so as not to occupy space constantly in the taskbar.

[cboxdoerfer]

Thank you!

But I don't see any option to start at reboot and I would also prefer for fsearch to start already in the background, without showing its window every time I reboot the machine.

Currently there's no way to launch it in the background. You can only add it to the auto start mechanism of your desktop, which will still show the application window.

and pressing Escape simply minimizes to the taskbar. Ideally it would go to tray, so as not to occupy space constantly in the taskbar.

In the 0.4 release I'm going to focus on the UI, with a port to GTK4 and maybe tray support. But for the 0.3 version I don't want to postpone the release any longer by trying to add more features as the development has been long and challenging enough already.

[atrugiel69]

Completely understandable and I truly appreciate the effort. If at all possible, for future versions, I think background running (as a service, maybe?) would be ideal.

At least in Linux Mint it's easy to set a keyboard shortcut to launch the program, so if this is common behavior in other Linux distros, tray support could be not needed.

fsearch running in the background, recalled with an OS keyboard shortcut, sent to background with the Escape key. Paradise! 😁

[wolpadinga]

Hello,

you can use a script that starts the app at startup and instantly moves it on another workspace. Then you can use a shortcut to toggle the workspaces. Works pretty well for me.

[atrugiel69]

Hello,

you can use a script that starts the app at startup and instantly moves it on another workspace. Then you can use a shortcut to toggle the workspaces. Works pretty well for me.

Yup. That's what I ended up doing. A workaround to carry us through until this is solved for good.

[alan-null]

@cboxdoerfer Thank you, Christian!

I’m truly grateful that I was able to find a replacement for Everything on Linux. Leaving Windows felt a bit daunting, but people like you have made my new tech home feel welcoming.

If I’m not mistaken, this year marks the 10th anniversary of fsearch. Congratulations!
We should celebrate with a “Search Party” 😄

[brezanac]

Hello there.

Thank you for all the effort, time and energy poured into this wonderful project.

The Flatpak version did not want to install without org.gnome.Platform//48 (deprecated as of March 24th 2026) as a dependency.

However, compiling from source with the default prefix worked great (Linux Mint 22.3).

I am really glad to see that there is now more control over when specific paths are updated with the introduction of the "Monitor" option.

Unfortunately, since this option only works on systems which support inotify or fanotify, it still doesn't solve the issue of controlling the update freqency of files located on local mounts to NTFS drives, SMB mounts etc.

I understand that FSearch is primarely aiming to solve the problem of searching on Linux, but from my experience it's pretty common to have large amount of data (archives) on external FAT/NTFS drives, or perhaps even shared in a dual-boot configuration.

Maybe add a checkbox to each path for an option called "Update" which when unchecked would completelly ignore the path during database updates.

That would be somewhat of a low-hanging fruit solution to #532 too.

Again, huge thanks for the update!

[Parsnip]

Ah this is a great update, looking forward to the non-beta release.

[atrugiel69]

While trying to execute commands that need sudo from the terminal, I get asked the password, as normal, but a message appears in the terminal window: Failed to add a watch for /run/systemd/ask-password: inotify watch limit reached

It came to mind that fsearch is using inotify and I wonder if it would/could make sense to try to follow the suggestion here:

https://unix.stackexchange.com/questions/285529/internet-stops-working-failed-to-add-run-systemd-ask-password-to-directory-wa

that is, to increase fs.inotify.max_user_watches

Edit: I see here: https://stackoverflow.com/questions/535768/what-is-a-reasonable-amount-of-inotify-watches-with-linux#comment85146771_535796 that fanotify requires only 1 "watch" for an entire file system

As it stands, I also notice that leaving fsearch running is using almost 1GB of RAM. If I close it and then reopen it, it quickly goes through a fast indexing phase and it ends up at 170MB of RAM used. So... I don't know if it could end up overrunning the system, if left running for a very long time.

My inotify values are:

max_queued_events 16384
max_user_instances 128
max_user_watches 246701

[cboxdoerfer]

@NotMithical Thanks! I'll also try to do that once I'm home. I have a suspicion that this might be related to the memory leak issue. Currently on master the old database isn't freed properly when you do a rescan, and this also keeps all the old watches running. So when you do multiple rescans the system eventually runs out of fanotify watches for the running db and eventually starts using inotify watches until they also run out. The commit responsible for that is: 43d6a1b
But if you don't do any database rescans at all then that's an entirely different issue and a bisect would be greatly appreciated.

[cboxdoerfer]

The memory and watch leak I mentioned is now fixed on master. Let me know if the issue(s) persist.

[NotMithical]

@cboxdoerfer The latest commit appears to have fixed it. Thank you!

[atrugiel69]

Thx, this sounds like some other issues then.

1. Regarding the memory usage: What folder(s) do you have included and excluded and how many items are in the database? Is there some way you can reproduce the increase in memory usage? Like does it slowly increase over time or does the memory increase after certain operations (e.g. a database rescan)? Maybe you have a cronjob running or something like that which triggers rescans? If it's that, then I already have that fixed, but not yet published.

I have updated to release 20260518+r2297.866ddc47~ubuntu24.04.1.

I launch now fsearch anew and it sits at 170,7 MB for memory used. Let's see in a few hours, after I leave it open, in order to have monitoring active.

FSearch reports 907.965 items, 820.019 files, 87.946 folders.

I am monitoring several media and documents folders, plus the home folder of my user in Linux Mint. There are no scheduled rescans in the program but I probably had still active a systemd timer that activated a database refresh through a user service. I have disabled the timer, the service and stopped the running timer as well. I think I wrongly assumed that it was enough to disable the service, but the timer was still running and activating the service (which invoked fsearch --update-database). It ran every 12 hours, which could probably sync with the progressive memory usage increase I was witnessing.

2. Just because the kernel was built with fanotify support doesn't mean that fanotify watches can be created for every folder. FSearch is still using one fanotify watch per folder, because setting up a fanotify filesystem watch requires root privileges (however this is planned for a future release). So maybe you are running out of fanotify watches (`/proc/sys/fs/fanotify/max_user_marks`) or there might be other reasons. In any case, FSearch only creates inotify watches when adding fanotify watches failed for some reason. I'll try to add more debug output to a future build for better debugging this kind of issue. If you are a bit familiar with C you could also try to add some debug output yourself around the `fanotify_mark` and `fanotify_init` calls. All of the fanotify code is here: https://github.com/cboxdoerfer/fsearch/blob/master/src/fsearch_folder_monitor_fanotify.c

Unfortunately I am most definitely not a coder, so I cannot proceed autonomously in this. But I remain available to test whatever you want to test on my side. Just reply here and I'll get a notification by email. Thanks!

One thing I can report, don't know if at all useful is this: if I look at open files for the fsearch process, I see a bunch of files open, with "object" anon_inode:inotify and anon_inode:[fanotify]. What this means, if anything, is beyond me.

[atrugiel69]

@cboxdoerfer yes, I think that commit fixed it for me too. The memory leak was probably coming from my database refreshes, once every 12 hours. Now, after two days of being running, FSearch sits at 214MB used and it was like that 24 hours ago.

[atrugiel69]

I can confirm... fsearch starts around 170MB of RAM used. If I leave it open (in order to have it monitoring the selected directories) it ends up increasing and increasing... don't know if there's a "stop point" but I'm, for now, closing it and immediately relaunching it every once in a while. @cboxdoerfer

[cboxdoerfer]

I've just pushed some additional changes to master, which address some feedback from the 0.3 beta. The rescanning is now more robust, the database config is now part of the config file again and things like "Rescan after X hours" can now be configured for each included folder, instead of it being a global setting. I'll do a second beta release this weekend, and if there are no more serious issues, I'll be preparing the final 0.3 release.