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

Ulrich Gemkow <[email protected]> writes:

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

A bit of a guess, but when unison writes a new fp file, it writes to a
tmp file and then calls rename(2), and this causes the directory mtime
to be updated.

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

The problem is really that one wakeup causes another wakeup.

Overall, I have to conclude that it's a misconfiguration to configure a
replace which contains a dir used as ".unison" without completely
ignoring it.

This would explain why it's only you, and no other reports, as ignoring
ar/fp separately is likely to be very unusual.

You might say you want to back up the prefs files, and that would be
support for "prefs and ar/fp should not be in the same place".

It's possible the manual should say more than it does, but I'll caution
you that I'd be ok with only very brief comments.  For the manual to
remain usable to all, it has to avoid being a treatise on any particular
edge case.

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