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

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?

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

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

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].