I know recently there was a bug for this however, is there not a better way to perform renames?
As it stands, if one of our users moves a folder that another user is currently editing a file in, it disappears for everyone else as expected except one user that was still editing a file in that folder then Sync never finishes because the device that was using that folder is now trying to save the file to that directory.
All devices then begin splurting out:
dst stat dir: GetFileAttributesEx C:\*****\General: The system cannot find the file specified.
When I then create the folder the messages change to:
pull: no available source device
But no one will have that folder now because SYncthing has successfully removed it from all devices so this error is going to remain forever unless I find the same file that was in it before…
Unfortunately I didn’t test this scenario beforehand. The only reason it’s cropped up now is because of the constant error messages being thrown up on all devices.
So I don’t think that the change in renaming caused this, as it should have behaved the same way.
I think it’s more of a race condition where A deletes/moves something, and B edits it, then it’s not deterministic which action wins in the sense of cluster, causing a conflict which are not resolved.
The way to recover from this is to add the file back, and touch it to bump the mtime, causing everyone to accept the return of the file.