It is very strange how it got damaged. Checked kernel logs of A, the USB device seems okay and did not disconnect unexpectedly while scan/sync. Renamed the index folder while st was off and went again to a fresh start. Let it be over night, checked in the morning and all states show the same on A+B and all files seem to be there. Now running a comparison of file contents with total commander between both datasets of A+B.
Could it be some racyness because of unsuccessful connection attempts? I noticed during the second run in the logs that device C was permanently trying to connect to A. C was there before I got the new OS installation on A because A had another syncthing device id running in the past. A correctly rejected every connection attempt of C . I have stopped C’s syncthing instance short after starting my second try after index reset.
I’ve ran some stress tests now for a couple of hours doing continuous database updates and checking for this issue in parallel and haven’t found anything on my systems. So it’s not totally systematic at least.
I reran and tried sth I did last time with my fresh sync cluster. While the initial scan took place on the source for /path/Install, I created another Syncthing folder pointing to a subfolder of it (Install2). Left the nested-folder unshared, let it scan 50% and then deleted it via Syncthing’s Web UI. The main folder /path/Install was initially shared to and accepted by the destination while scanning and already beginning transferring data while scan was in progress. I “unfortunately” could not reproduce the index problems. The sync went well over. I’ve also captured logs, nothing special in there - because of successful sync.
The only messages I’ve found suspicious on source.log is:
2020-02-03 14:20:17 Adding folder "Install2" (ppukr-qztcq)
2020-02-03 14:20:17 No stored folder metadata for "ppukr-qztcq": recalculating
2020-02-03 14:20:18 Ready to synchronize "Install2" (ppukr-qztcq) (sendreceive)
2020-02-03 14:20:51 Adding folder "Acrylic" (s5yhr-7wbsp)
2020-02-03 14:20:51 No stored folder metadata for "s5yhr-7wbsp": recalculating
2020-02-03 14:20:52 Ready to synchronize "Acrylic" (s5yhr-7wbsp) (sendreceive)
2020-02-03 14:20:53 Completed initial scan of sendreceive folder "Acrylic" (s5yhr-7wbsp)
2020-02-03 14:21:12 Failed initial scan of sendreceive folder "Install2" (ppukr-qztcq)
Full logs of source and destination (fresh setups) for reference - if they are of any use. Else ignore.
That’s not ok. If you enable the app debug facility, is there also a service which fails to terminate in a timely manner? (that should probably be changed to log at info or even warning level anyway)
I’m observing a weird log line when syncing between two other devices, not related to the initial post. But this time, the sync seems to work okay.
Folder F shared between A+B (id “n4q4z-ohpfz”)
A: Windows 10-1903 x64, Syncthing v1.3.4
B: Linux amd64, Syncthing v1.3.4
A has a suspicious entry in the log:
2020-02-05 14:04:49 Syncthing should not run as a privileged or system user. Please consider using a normal user account.
2020-02-05 14:04:50 Stored folder metadata for "n4q4z-ohpfz" is 723h26m4.8138797s old; recalculating
2020-02-05 14:04:50 Index for nonexistent folder "n4q4z-ohpfz"
Maybe the log is related to the problem? I don’t see why the metadata should be old. Why do I get the log line “Index for nonexistent folder “n4q4z-ohpfz”” because of a non-paused folder which seems to be fully in sync between the two online devices A+B.
Going to build a windows stindex.exe …
go run build.go -goos windows -goarch amd64 build all
Hmmm… stindex this time doesn’t output anything which implies the database is okay. I expected it to show errors for device A (like it did in the initial post’s case between those linux devices). Not sure if we diagnose the “same” problem here.