The /rest/db/file output is from the same device where the no such file occurs in logs?
That would be super weird, as the /rest/db/file output both shows to be already up-to-date (no syncing should happen), and even if there’s a mistake in that and it still tries to sync, it should try to sync a deleted file, however it handles it like a regular, existing file.
that one is from the “sender” in the above scenario, from a previous message I thought that’s what you needed. Sorry if I’ve got the wrong end of the stick. Similar output from “receiver” is below:
At the same time as you get these /rest/db/file outputs, you also get the failed items with “no such file” message for the file “library/2020/2020-02-99_misc-around-home/029A9286.CR2”? That should be entirely impossible: The receiver output you posted shows that it thinks it is already up-to-date (global version is equal to the local one), i.e. no syncing occurs and thus also no sync error. On the other hand the global file on receiver is older than the one on sender, which points again at sequence problems (which should show up running stindex -mode idxchk on sender, however it doesn’t, correct?).
That honestly leaves me with no clue as to the cause. Nevertheless lets hope it’s still related to the db fix in 1.4.0. Please report back if you still have the problem after updating.