Running Syncthing v1.14.0: I’ve got a folder on a Synology NAS, which is syncing from another Synology NAS for off-site mirroring. The two NASes got out of sync (from a different sync tool), so I’m using Syncthing to get them back into sync, setting the receiver to Receive Only until such time as they’re actually in sync.
But when I press Revert Local Changes, the folder goes into Scanning - and eventually comes to rest in exactly the same state as this.
Looking in the logs, I see this:
[*****] 2021/03/05 15:12:15.871682 folder_recvonly.go:143: INFO: Revert: directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally
[*****] 2021/03/05 15:12:15.943961 verboseservice.go:37: VERBOSE: Folder "*****-*****" is now idle
[*****] 2021/03/05 15:12:15.957554 folder_sendrecv.go:1750: DEBUG: receiveonly/*****-*****@0xc019be6700 scheduling scan after pulling for <file path here>
etc...
It looked from that previous thread that this had been thought resolved - but not according to what I see here.
Is there anything I can do to help narrow down this problem?
To me this says pretty much as it describes - that the remote side has had a directory deleted, but was set to ignore the contents. On the local side, the directory cannot be deleted because there are contents that are still present, but not flagged to be deleted.
It’s a complicated concept, and I can’t think of a more eloquent way to describe it concisely! Whilst writing the above paragraph, it took me quite a while to parse the message to ensure I was understanding it correctly within the context of Syncthing operation - and that’s as a native English speaker, and one who’s used to using Syncthing…
However: in my case, the ignore patterns are the same on each side - so I can’t see that this is a useful message for troubleshooting in this situation!
If I did have a danger that the ignore patterns were different on each side, then the log message would have been a helpful pointer.
I suspect anyone who finds the log files is probably already going to have a half-decent idea of what might be going on, based on that message.
There are correct, ‘good’ files inside the folders, on both sides; as far as I can see, the list of Locally Changed Items comprises only folders - but I’m not sure why they’re there.
It does look like the mtime of the folders on the receiving side is newer than the mtime of the folders on the sending side - though the contained files have the same timestamps. Would that cause what I’m seeing?
Probably those directories are “deleted” in db on the other device, and get revived here because of their contents. Does the other device (almost) never scan? Then a full rescan on that device might already fix the problem. In any case the output of the /rest/db/file endpoint would be interesting (respectively /rest/debug/file, which works the same way but has more info): GET /rest/db/file — Syncthing v1 documentation
Sorry - I’m not sure what you mean here. I can’t see /reset/db/debug in the REST API documentation.
FWIW I’m quite happy to delete the affected folder tree on the Receive-Only node (which I presume will cause it to sync into place from the other node), if this niggle isn’t worth chasing down.
That was a typo, should have been /rest/debug/file that works like /rest/db/file - anyway not relevant here, won’t contain any more info than what you posted.
There’s nothing to chase down - the “bad thing” already happened. The interesting bit would be what/how that happened, but can’t detect that after the fact.
Deleting probably wont work: For some reason the receive-only folder knows nothing about those folder from the other device. You can try resetting deltas though (start with -reset-delta command line flag), that might fix it.
If I did have a danger that the ignore patterns were different on each side, then the log message would have been a helpful pointer.
