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