This morning I have realized that there is a /rest/folder/versions endpoint which can be used to return a huge list of file when called with GET (it does not document taking any selection parameters) or be used to restore file(s) with POST. Would using this API have advantages over simply doing mv …~YYYYMMDD-HHMMSS …? Should that force trigger detection of the file change even if the scanner, or what you call it, would fail to do so?
Thanks for clarifying how scanning works. I was indeed having the misconception that all files were rehashed with a frequency of rescanIntervalS. I read that “The only way to force a rehash of everything would to be reset the database” which definitely does not seem like something I would wish to do.
My corrupted files came from fsck, which means the mentioned metadata properties appears to have remained constant. Still the corrupted files were detected as new and got replicated. However after restoring they do not get picked up. I fail to understand why. It can’t be explained by inotify, as syncthing was not running at the time of doing fsck. If wildly speculating, would perhaps changed inodes be a possible factor?
Both the laptop which corrupted the files and the server which fails to detect the restored ones run syncthing 1.19.2~ds1-1+b4, which admittedly is quite old even if being the “latest packaged” in the Debian world.
Understanding that this is not considered a bug which can be helped by me debugging the current state, I’ll update mtime of all restored files in a few hours.