How to reset/recreate the index on a certain folder?

Support
1

Hello,

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://92.222.95.0: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.

1 Like
2

So there is too much text to me understand wether the issue is there or not and if you need any help, but regardless, this is a known limitation/quirk having to deal with multiple platforms:

3

Indeed. The workaround for this issue is to rename it to something entirely different, let that sync, and then rename it back.

To actually reset the index for a specific folder you need to use a POST to the REST API, it’s in the docs somewhere. :wink:

1 Like
4

Not a very friendly remark. I’m trying to give as much information as possible and it certainly took me quite a while to piece it all together. Since you are not obliged to read why comment negatively?

Thanks for the link.

5

So I have read it all, but the tune changes multiple times throughout the post (first failed items, then no failed items, then failed items gain?) that I can no longer comprehend whether the issue is still there or not.

I think the link summarizes and covers the whole of the issue, but let me know if you want anything else answered, or something is left unanswered by the ticket.

6

I’m not a developer. Things can always be written differently in hindsight.

Knowing it is a bug is enough for me. I’ve tried updating the title but am not allowed to do this.

Uninstalling Syncthing and deleting the ~/Library/Application Support/Syncthing directory did solve it. This is a real bummer. Makes me doubt Syncthings reliability.

7

I’ve also tried calmh solution on a second machine. The rest command can be found here.

At first nothing happened, but after a restart of Syncthing the folder was gone. Other machines wanted to (re)connect and after that the folder came back clean from any errors.

Hooray! And thanks for the pointers.

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.