Re: fsmonitor on linux is triggered due to unison changes its fingerprint cache
Greg Troxel <[email protected]> Fri, 26 Sep 2025 07:06:47 -0400
| Newsgroups | gmane.network.unison.general |
|---|---|
| Message-ID | <[email protected]> |
"'Dale R. Worley' via unison-users" <[email protected]> writes: > Ulrich Gemkow <[email protected]> writes: >> This is the output of a tool which uses the Linux inotify syscall to >> watch for changes in a directory tree. It tells that the file named >> at the end of the line is modified ((fpd51d53afbd71ea49fcec7a981a36e25f). >> >> This is unisons fingerprint file. > > Ah! I had assumed that "fpd51d53afbd71ea49fcec7a981a36e25f" was some > sort of internal code. > > The let me propose this sequence of events: > > 1. Unison wakes up and runs. > 2. No files have changed, so it doesn't do anything. > 3. Unison does not change the contents of fpNNNNNNNN but it updates its > modification date. > 4. Unison sleeps. > 5. fsmonitor is notified that the modification date of fpNNNNNNNN has > changed. > 6. fsmonitor wakes up Unison. > 7. Unison wakes up and runs. > etc. Plausible, but it should be easy to add debugging to confirm. I always try to hill-descend to a state where less is assumed and more is known. (I'm not criticizing your suggestion - just that I would love to see a trace that shows that is what is happening, vs a great guess.) I would also like to understand why this same problem does or does not happen to everyone else who: - uses unison on their homedir - uses the watcher and I would expect that's a significant set of people. As far as I know, we do not have a second report of this behavior -- even with this discusion. > What we need for this situation is that if Unison detects no changes, it > should not modify the file system, not even the files in ~/.unison. In > particular, it should not change the fp* file if it does not change its > contents. We need a way to break the cycle, and arguably multiple ways is more robust. I agree that not writing a fp file if is the same would be a good thing. Another way is for unison to run ignore processing on reports from fsmonitor. That would avoid the rescan also. A third way, as Boris just suggested, is to push the ignore list into the watcher. This is complicated by unison having expressions and not an explicit list, and those expressions including files, while the watcher operates in directories while doing setup. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].