Recurring issue of "Syncing 95%, 0B" after file rename

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:

{
  "availability": [
    {
      "id": "SENDER_LONG_ID",
      "fromTemporary": false
    }
  ],
  "global": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2020-01-30T02:40:30+11:00",
    "modifiedBy": "SENDER_ID",
    "mustRescan": false,
    "name": "library/2020/2020-02-99_misc-around-home/029A9286.CR2",
    "noPermissions": false,
    "numBlocks": 147,
    "permissions": "0664",
    "sequence": 240914,
    "size": 19215845,
    "type": "FILE",
    "version": [
      "SENDER_ID:1"
    ]
  },
  "local": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2020-01-30T02:40:30+11:00",
    "modifiedBy": "SENDER_ID",
    "mustRescan": false,
    "name": "library/2020/2020-02-99_misc-around-home/029A9286.CR2",
    "noPermissions": false,
    "numBlocks": 147,
    "permissions": "0664",
    "sequence": 240914,
    "size": 19215845,
    "type": "FILE",
    "version": [
      "SENDER_ID:1"
    ]
  }
}

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?).

Correct

Yes, that’s correct, I just ran stindex again on the “sender” PC and it doesn’t show any output at all.

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.