Beta Release: 0.3-beta1 #662
Replies: 9 comments 14 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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! |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
Ah this is a great update, looking forward to the non-beta release. |
Beta Was this translation helpful? Give feedback.
-
|
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: 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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
This discussion was created from the release Beta Release: 0.3-beta1.
Beta Was this translation helpful? Give feedback.
All reactions