Re: fsmonitor on linux is triggered due to unison changes its fingerprint cache

Hallo T=C3=B5ivo,

On Saturday 04 October 2025, T=C3=B5ivo Leedj=C3=A4rv wrote:
> 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 =3D 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.
>=20
> Correction to my previous statement: fsmonitor implicitly knows about
> ignored _sub-dirs_. Not about ignored files, of course.
>=20
> > > 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.
>=20
> 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.
>=20
> > > 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
>=20
> 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/114=
7__;!!IBzWLUs!Q-HFjhwdBUu-RvS8JVY_HdgR6iCmpEPX38KVagaY5axjbao-btDzvwOtNxuKG=
C7I88ZsTVYCEEGYGXuViXiAdwhdNq59KVniCZIqnTG0Jg8$  (you can download build
> binaries by opening the Checks tab and then clicking on 'CI').
>=20

Thank you for the patch! I installed the modified binaries
and the problem is solved. I found no regressions.

Thanks for the quick solution and best regards

Ulrich

--=20
Ulrich Gemkow
University of Stuttgart
Institute of Communication Networks and Computer Engineering (IKR)