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.
Is this the expected behaviour?
Does it get rehashed? If so, something about the metadata we see did change. If not, does it matter?
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.
Thank you for the explanation 
.
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.
You can compare the file info (from the API) before and after to see what changed, if anything…
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.
just thinking out loud: maybe it would help to replace the scanning state (with/without percentage) with something like “looking for changes” and then “hashing changed files (…%)”.
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.
I don’t know, you can debug what the notification is, precisely, and we can see. Generally just looking one extra time at a file’s metadata isn’t something that matters much.
Yeah, this is extremely minor, but still 
. I will try to enable some debugging and see what the log says. I will come back if I manage to find anything useful.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.