I’m seeing my remote devices stuck with “Syncing (95%, 0B)”. This has been reported before several times, but I don’t think the reproducible and resolution for my issue has been detailed yet.
To reproduce my issue (using v1.2.2 on both sides), do on the local device:
mkdir test
touch test/testfile.txt
Wait for file to sync to remote device.
Add “testfile.txt” to .stignore.
rm -rf test
The remote device will now get stuck with “Syncing (95%, 0B)”, with neither test nor testfile.txt deleted. It seems that since testfile.txt is now ignored, it won’t be deleted on the remote site, but since the “test” directory was deleted on the local side, the devices are now out of sync.
Probably the proper thing to do is for Syncthing to delete the “testfile.txt” on the remote site since the whole directory was deleted. But I haven’t thought about this deeply enough to know if this would lead to unwanted lost files in some situations.
I have also seen this bug at irregular times, but have not been able to find the cause. I’m not using ignores, just a shared folder with one side being send-only. There are no permission problems, all other files are transferred. The only thing I noticed is that it is usually a 0 byte file that has been deleted on the sending side.
usually a 0 byte file that has been deleted on the sending side
Hey, nice find. Now I know that I’ve also encountered this multiple times without knowing the cause in sendonly>receiveonly setup where I had to hit override on the sending side.
This is by design: What Syncthing does is it displays a failed item on the remote side: test directory is not empty; files within are probably ignored on connected devices only. It does that because the local device sends an update that it has deleted test, but not testfile.txt, as it ignores that. The remote then tries to delete the test dir, and sees that there’s still content within, that isn’t deleted. So it doesn’t go ahead to protect your data, but displays this error message.