Re: fsmonitor on linux is triggered due to unison changes its fingerprint cache
Tõivo Leedjärv <[email protected]> Sat, 4 Oct 2025 14:05:56 +0200
| Newsgroups | gmane.network.unison.general |
|---|---|
| Message-ID | <CAALvpZRZF+63gNHzNtxYCB2bPwCrV-ahE1CVttrg4bzU9+bLHw@mail.gmail.com> |
On Fri, 3 Oct 2025 at 21:17, Ulrich Gemkow <[email protected]> wrote: > > > > - When I exclude the _whole_ directory ~/.unison/homesync with > > > an ignore-Statement like > > > > > > ignore = Path .../.unison/homesync > > > > > > then the 1-second open-modify-close cycle does not happen, the > > > fsmonitor does not wake up and my watch tool shows no events. > > > > This is to be expected. The fsmonitor implicitly knows about ignored > > paths because Unison only asks it to monitor non-ignored sub-dirs. Correction to my previous statement: fsmonitor implicitly knows about ignored _sub-dirs_. Not about ignored files, of course. > > It's a feedback loop caused by a slight inefficiency in Unison's code. > > The inefficiency being that Unison writes to the fingerprint cache > > file at every scan, even if it has nothing new to write to the cache. > > This causes an inotify event, which causes a new scan, which writes > > the cache file, which causes an inotify event, ... > > > > There is no tmp file or rename(2) involved. The issue is that the > > cache file is truncated and a preamble written at every scan. This > > causes the MODIFY inotify event. > > Thanks for the explanation, this explains the behavior. > > But the question remains why unison performs a scan when it should > only "watch" using the fsmonitor. And why every second. The loop is started by the first scan which is done always, without fsmonitor requesting it. That first scan writes the fpcache file, which then triggers fsmonitor and so on. As to why every second, there is nothing magical about the second. There is a small delay in fsmonitor to batch multiple changes before triggering a scan and also to prevent too frequent scanning becoming too resource intensive. > > I'm considering improving this to skip writing the cache file if there > > is nothing new to add to the cache. > > Thanks again and best regards I have opened a PR which may or may not be accepted for merging but if you're interested, you could test the builds with the patch with your _original_ configuration (the one that caused the issue). It should be fixed with this patch. https://urldefense.com/v3/__https://github.com/bcpierce00/unison/pull/1147__;!!IBzWLUs!XREXk-4pBBG0P7jr3d6W3ScXgQ-ZAsVu-mVP3SUf1IAmQYBEBD0PXWDCxqN1va1AVnJ3neSGAiCr2Kl2qvt7sQ$ (you can download build binaries by opening the Checks tab and then clicking on 'CI'). To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].