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

Hallo Greg, hello all,

sorry for coming back to this so late, I had to build
a test environment. Please see below

On Saturday 20 September 2025, Greg Troxel wrote:
> Ulrich Gemkow <[email protected]> writes:
> 
> A question I didn't think to ask, which is: are there remote filesystems
> of any kind involved here, such as NFS, CIFS, gluster?   Is the sync
> Linux to Linux, and does each machine use ext3/ext4 or some other normal
> local filesystem?

We use Linux on both sides, server and client. There are no remote
filesystems involved, server and client use a Linux btrfs filesystem,
which is a little bit enhanced but normal local filesystem.

> > In the mode "-repeat watch" unison uses the fsmonitor to watch
> > (wait) for changes in the replicas. As long as no change happens,
> > unison waits.
> 
> That matches my understanding.
> 
> > On Linux, the fsmonitor uses the Linux-Kernel inotify interface,
> > which works (simplified) as follows: The fsmonitor gives the
> > kernel a list of directories (recursively from a starting dir)
> > and the kernel adds "watches" on these directories. Then the
> > fsmonitor calls a blocking system call which returns ("triggers"),
> > when in one of the watched directories something has changed.
> 
> OK, but what is returned is about the accessed or  modified file, not
> just about the directory, as your example shows.

Yes, the watches created by the inotify call are added to directories,
the reported changes are on a file-or-directory level. This may be
Linus-specific.

> > Then fsmonitor itself wakes up unison and gives the changes
> > information to the calling unison process which looks whether
> > is has to synchronize the change.
> 
> Presumably this is "writes the changes info to a pipe or socket, and
> unison is waiting via select or some such to read that".
> 
> > Unfortunately the fsmonitor only receives the root dir of the
> > replica and adds watches for all subdirs of this replica.
> > fsmonitor has no knowledge about ignore-Lists. This
> > simplification in the protocol between unison and fsmonitor
> > is good, other solutions would be complicate because fsmonitor
> > would have to translate the ignore lists in the kernel list.
> 
> I see how this will result in unison receiving notifications about files
> within the replica that are configured to be ignored.
> 
> > But from this it may happen that unison is waked up
> > ("triggered") also for directories which should be ignored.
> > This is a small flaw in itself but in most cases no problem.
> 
> The problem seems to be that in your case, unison is not ignoring the
> notification for a file that should be ignored, and is then rewriting
> the fingerprint file.
> 
> Nobody else has reported this problem.  It's possible there's something
> odd about your setup, and it's possible that just..  nobody has noticed.
> 
> Have you confirmed that the contents  of .unison/homesync is *not*
> synced to the other side?
> 
> I would really like to hear from others who set up -repeat watch on a
> homedir with .unison, about what happens to them.
> 
> > I will further investigate to answer your other questions
> > as soon as possible (have to patch the sources).
> 
> I would want to understand what information is passed to unison,
> precisely, and if it is a specific pathname, if that's run through
> ignore processing before being acted on.

I further tried to better understand and found the following
(which may not be very helpful).

The .prf and the other unison files (ar* fp*) live in
~/.unison/homesync. I use a separate tool to watch for changes
on the server (it uses the same inotify call as the fsmonitor).

Then

- When I use the following ignore-Statements (with ... being
  the path of my homedir)

  ignore = Path .../.unison/homesync/ar*
  ignore = Path .../.unison/homesync/fp*

  then unison on the server opens, modifies and closes the fp-file
  in ./unison/homesync every second. The content of the file does _not_
  change. This is shown by the watch-tool and the fsmonitor wakes up.

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

So when ignoring only the files, the problem happens. When excluding
the whole directory with the files inside there is no problem. This
seems to be a little strange - I really hope that I made no mistake.

I tried to find the reason in the source but failed.

Has anyone an idea what unison does every second with its fp-File
when the directory where it lives is not ignored? Does a bell ring?

Regarding the question whether to put the ignore-path handling in the
fsmonitor I would recommend not to do this: It would mean that on every
change of the watched tree all watches whould have to be checked and
replaced. This is expensive on the kernel side (on my medium-sized
homedir adding all watches takes about 3 seconds on our rather fast
fileserver). It seems to be better that unison is waked up sometimes
without reason - the problem here is that it happens rathed often.

Thanks for all answers and best regards

-Ulrich

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