I have observed recently that changing the NTFS compressed attribute (i.e. compressing or decompressing a file) triggers the file watcher (at least in Windows). Syncthing itself is supposed to ignore the compressed attribute, but I guess that the file system watcher does not care and still forces Syncthing to re-scan the files.
Changing the attribute does not change file hashes as such. On fast hardware, it is no big deal, but on slow CPU/storage, it takes a lot of time to go through the files, especially when doing mass compression or decompression, so I would say that it does matter in that case.
To be specific, I have observed this when decompressing files on an Intel Atom device, and it takes a lot of time to re-scan all of them (and for no real benefit/reason, as only the attribute has changed). In addition, re-scanning all the files also triggers the AV (which is Windows Defender in this case), which makes it even slower.
You misunderstand my question. The notification events only cause Syncthing to look at the file metadata - timestamp, size, etc. Then only if that differs is the file read and hashed. It sounds like the latter happens. Then the issue is not that the events happen, but that some part of the metadata we care about actually changes. In that case the file will be rehashed at some point regardless of notification events, so it would indeed be expected.
Hmm, but they do not really change, do they? Timestamps are untouched by changing the attribute, and as for size, Windows reports both “size” and “size on disk”. The latter is impacted by the NTFS compression, but the former remains unchanged.
I have now used GET /rest/db/file to compare a test file in a compressed state, and then after decompressing it. However, there is no difference at all. The file watcher still gets triggered and the GUI shows the folder being rescanned each time the attribute has been changed though .
Again, there’s a huge difference between the folder rescanning (because there might be something that changed) and a file being rehashed (because that file changed). If nothing changed in the file metdata (including the version), then it wasn’t rehashed.
The metadata does not change, so it would mean that Syncthing only checks the files without hashing them. I guess that there is no way to just stop triggering the file watcher on such insignificant attribute changes, right? By “insignificant” I mean those that are not used by Syncthing for the actual synchronisation.