I have some folder on a Windows machine where I found that random files and complete sub-folders were not synced to the two other Debian machines. Initially, while those Debian machines were still on 1.19, I found that not even any updates to the missing files caused them to be re-synced, but this problem is gone by now. I think it’s not related to the Debian machines actually, but maybe to a restart of the Windows machine.
The core issue remains though: Several files and sub-folders of that specific folder are still missing on the other Syncthing instances. If I modify a single file in a sub-folder, it suddenly gets synced to those other instances. However, simply forcing a rescan of the entire Syncthing folder is not enough. So I have a feeling that Syncthing “sees” that the sub-folder contains no changes (does it use the NTFS journal or object ID changes?). I should note that this directory structure is a copy of another directory structure within the same sync folder, and the other copy of the same directory synced without issues.
I noticed that a tool called stindex was mentioned in many related forum posts, but the ones I could find were several years old and the attached stindex version cannot seem to handle the current database. Where can I find a current version of stindex to confirm whether the database has any issues?
It’s possible that you’ve hit one of the index exchange bugs that were present in older versions. Initially, I would recommend that you start one of the machines with the command line option syncthing --reset-deltas and see if that solves the problem.
Not really, but syncthing does indeed not rescan files if neither the file size nor modification time (or other relevant metadata) has changed. Generally, a rescan does nothing if nothing has changed. In syncthing, each device pulls the data that it thinks it needs. If a device doesn’t download something, that’s probably because it thinks that it already has everything (which may indicate an index exchange bug being present).
Unfortunately, running syncthing --reset-deltas on one of the Debian machines didn’t change anything. I then ran it on the Windows machine to be sure, and that also didn’t cause the files to appear on the other machines.
Okay, so something else is off then. Is the Windows folder on an unusual filesystem (which on Windows is pretty much anything but NTFS) or a network share?
I also encountered this problem recently. I downgraded Syncthing on Windows to v1.27.12, and the problem disappeared.
You can also try it, to see if it was caused by some bug in v1.28.0.
Since the missing files are not critical at this point in time, with the knowledge there might be a bug in v1.28.0 I would be willing to keep that directory in the state it currently is, in case Syncthing developers need me to test something to figure out what’s going on.
I think I have the same problem. A few days after recently updating to a new Syncthing version, I noticed a specific folder did not synchronise anymore. This folder is not in the ignore list (and no settings were changed compared to the working state before).
Syncthing claims all shared folders are up to date and doesn’t perform any sync actions when I add new files below the ‘broken’ folder.
v1.28.0, x86, Linux Mint (PC)
to
v1.28.0, ARM, Raspbian (RPi 5)
To supplement the information in the previous ticket:
Going by the modified dates on the files in the source folder missing from the destination folder, synchronisation stopped somewhere between 2024-10-18 and 2024-11-05.
Syncthing on the PC was updated on 2024-10-20 (1.27.12 → 1.28.0).
Syncthing on the RPi was updated on 2024-10-30 (1.27.12 → 1.28.0).
Since no syncthing settings were changed on either device in that period, I strongly suspect the update triggered or caused this change in behaviour.
