syncthing seems to have problems if an item name changes only its case (like Hello to hello or CASEsensitive to caseSENSITIVE) if there are filesystems involved that are not case sensitive or handle that in a peculiar way. Maybe it’s just my setup.
I’m syncing JHFS+ (OS X) to ext4 (Linux) to NTFS (Windows). All three filesystems should be case sensitive. Renaming a folder from HTML to html wrecked havoc on the folder contents.
I am unable to exactly explain what happened - so much did happen and on so many different things on different machines. Since I did not watch it in the beginning, I’m unaware of how things startet, but as I became aware of the problem (because scripts were failing) the situation was a total mess. The original folder HTML was recreated on some machines (OS X, Linux) while others did not copy the lower case variant (html). After a little more time some machines had two folders, others just one in upper or lower case lettering. The contents of the folders were in equal dismay, some having files, others just files with conflict added, some both. I could for the life of me not find out who should have what file (because I could not remember what should have been in the folder to start with and which was updated most recently).
step 1: In the past I’ve had good experience with Syncthing working things out for itself. This time, waiting for a day (folder sync is 900 secs = 5 min) did not help.
step 2: So synchronization was stopped. The folder on one machine was restored to its original state from a backup. This folder on this machine was made the master. Synchronization with all peers was restarted. Waiting another day, and pushing the red button on the master machine now and then did not work out either.
step 3: Synchronisation to the peers was stopped again and the contents of the folder rsync’ed to each and every client by hand, except for the Windows machine (because of lack of SSH). The Windows machine was “synced” by SMB copying the files from the master (yes, I am aware that the access time stamp there would be newer that on the master). Synchronization was restored. It was expected that the windows machine (having the newest access time stamp) would take over as the most recent source and distribute the (almost identical) files. Things did get better quickly, but some clients are still insisting they have a folder to synchronize that is neither on them nor on any other client in the network.
step 4: Synchronisation was stopped again. One machine restored from the Backup like before. On one of the conflicting machines the offending folder was removed via the GUI. It was assumed that this would also delete the index from Syncthing. Syncthing asked for a restart. After that the folder was recreated (well, the GUI entry for the folder; the contents of the folder hadn’t changed and were okay). After the initial scan, Syncthing flags 1 “Failed Item”. The folder is still unshared.
Now I am puzzled. How would Syncthing, just having been restarted, know about a sync error for a folder that has just been created? Only if it had some information about the previous time, this folder had been under its supervision.
step 5: The folder was deleted again and recreated with the same path but a different name (like “blah”). Still not shared. After the initial sync, Syncthing shows no errors, no failed items.
How come? Has anybody any insight and give me a tip on where to look? I would like to reset the index for this folder.
The log (loglevel=8) gives no indication:
[AZ7G3] INFO: syncthing v0.12.22 "Beryllium Bedbug" (go1.6.1 darwin-amd64) wolf@DE71364-CL-M2 2016-04-13 09:52:12 UTC [AZ7G3] INFO: My ID: AZ7G33L-... [AZ7G3] INFO: Single thread hash performance is ~102 MB/s [AZ7G3] OK: Ready to synchronize Documents (read-write) [AZ7G3] OK: Ready to synchronize BLabla (read-write) [AZ7G3] INFO: Using discovery server https://discovery-v4-1.syncthing.net/?id=SR7AARM-... [AZ7G3] INFO: Using discovery server https://discovery-v4-2.syncthing.net/?id=DVU36WY-... [AZ7G3] INFO: Using discovery server https://discovery-v4-3.syncthing.net/?id=VK6HNJ3-... [AZ7G3] INFO: Using discovery server https://discovery-v6-1.syncthing.net/?id=SR7AARM-... [AZ7G3] INFO: Using discovery server https://discovery-v6-2.syncthing.net/?id=DVU36WY-... [AZ7G3] INFO: Using discovery server https://discovery-v6-3.syncthing.net/?id=VK6HNJ3-... [AZ7G3] INFO: Device AZ7G33L-... is "DE71364-CL-M2.lvdw.local" at [dynamic] [AZ7G3] INFO: Device 3WA5ZSH-... is "DE71364-CL-M3.lvdw.local" at [dynamic] [AZ7G3] INFO: Starting usage reporting [AZ7G3] INFO: GUI and API listening on 0.0.0.0:8090 [AZ7G3] INFO: Access the GUI via the following URL: https://127.0.0.1:8090/ [AZ7G3] INFO: Completed initial scan (rw) of folder BLabla [AZ7G3] INFO: Established secure connection to 3WA5ZSH-... [AZ7G3] INFO: Device 3WA5ZSH-... client is "syncthing v0.12.22" named "DE71364-CL-M3.lvdw.local" [AZ7G3] INFO: Joined relay relay://184.108.40.206:443/?id=UOVD33C-... [AZ7G3] INFO: Completed initial scan (rw) of folder Documents
Here “BLabla” was deleted and the original “Scripts” recreated. The deletion is nowhere documented, nor the creation.
[AZ7G3] OK: Ready to synchronize Scripts (read-write) [AZ7G3] INFO: Completed initial scan (rw) of folder Scripts
At this point the 1 Failed Item error is back that was not there while the same folder (in the disc) had been named “BLabla” in the GUI.