14 out of sync items

After successfully reverting from a Dropbox mishap I now have 14 out of sync items om my Synology NAS.

But the files were actually present and identical to the files on my pc. I then tried to delete them on my NAS with the PC in Send only mode and used the override button. The PC now said Up To Date but nothing happened on the NAS which still had the 14 items out of sync.

The I copied them back manually from the PC and made a rescan but still no change.

I even tried deleting the files on both sides to no avail.

Screenshots of pc and NAS:

Output from RESP API for one of the files (WEB603652.pdf)

{
  "availability": null,
  "global": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2019-10-23T11:27:58.377395396+02:00",
    "modifiedBy": "24RXGCN",
    "mustRescan": false,
    "name": "WEB603652.pdf",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0600",
    "sequence": 2903,
    "size": 64740,
    "type": 0,
    "version": [
      "WU5B2SF:3",
      "24RXGCN:2"
    ]
  },
  "local": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2019-10-23T11:27:58+02:00",
    "modifiedBy": "7NSOW5E",
    "mustRescan": false,
    "name": "WEB603652.pdf",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "sequence": 3061,
    "size": 64740,
    "type": 0,
    "version": [
      "WU5B2SF:2",
      "24RXGCN:2",
      "7NSOW5E:2"
    ]
  }
}

It seems the file announced by 24RXGCN is not available anywhere, so the device that announced it and gone offline.

After I turned my laptop on a scanned again, Syncthing now complains about the 14 items as failed because of chmod not permitted. But I checked the permissions, they are ok.

But the owner was wrong. Changed it and now it seems to work.

A last question: Why didn’t SC report failed items before the laptop went online? The “operation not permitted” problem must have existed even with the laptop off?

It doesn’t touch items that are currently unavailable, as there is nothing it could do with then.

The fact that we had to poke at the api to understand where the files came from is a bit grim and probably github issue worthy.

How did you read from the JSON what was wrong?

Availability is null

Yes there’s indeed a bug. There should be failed items in the UI, with errors containing “no connected devices has…”. However we do track if we do changes during a pull, and consider it a success if there were no changes. However in case of several non-recoverable failure modes we do not track that as a change (to prevent another pull iteration), so we then reset all errors, even though there are legitimate errors that should be displayed to the user. I opened an issue about that: https://github.com/syncthing/syncthing/issues/6139