No connected device has the file - touch won't fix

Support
1

I’m getting the error "No connected device has the required version of this filefor two files. This has been going on for days while other sync actions seem fine. Both sync nodes involved are R/W on this sync folder.

I went to those few files and “touched” them to update their modification date, expecting the newly dated file would become the most recent version in the cluster, propagating to all the others and the error would go away.

It did not. Why is that message still present on a computer that has the most recent version? I would think this computer would not want any other version now.

This situation also causes “Out of Sync” for that folder on the web GUI, so I’d like to figure out what I misunderstand and prevent it from happening again.

2

The error usually means there’s another device somewhere that advertised a change but went offline before that change could be synced.

Touching should indeed “fix” the situation (potentially causing a conflict when the disconnected device comes back online), so no idea why you still have out-of-sync items, that definitely should be the case. The output from a querying https://docs.syncthing.net/rest/db-file-get.html for an affected file might give a clue as to why (it would be nice to integrate that into the web UI somehow as often as it’s needed…).

3

Simon, I think you just confirmed the issue. So I’m still wondering how to fix it.

I clicked on the link, but it’s not clear what that is supposed to do. It looks like some C or java-script or API? Or ?? something? The linked “worked” but means nothing to me.

4

I have this too.

I cannot tell exaclty when this happens, but those actions are involved for the following scenario:

File was synced between those three (R/W) Devices/Folders:

  • Device O went offline months ago.
  • I modify a file on Device A (with a NotePad++, so there is a *.bak file created and overwritten a lot of times, as well as the original file changes a lot)
  • Device B (Laptop) will be “Lid-Closed” sometimes while syncing is in progress

When both Devices (A+B) are online for a 8h or so, I too get that message “No connected device has the file”.

I have this message mostly for files which are synced to more than 2 Devices and where 1 Device is offline (and never had that current/up to date file).

Hope it helps. If not, ignore please.

5

One other person seems to have the same problem. One person confirmed “touching” the file should have fixed the problem. No other suggestions or explanations received. Apparently, this is a residual issue.

Rather than correct it direclty, is there an approved way to wipe the associated directory database and (therefore) resync all files in that directory? That should eliminate any history that might be causing the situation. If the problem remains then, I’ll figure out how to log a bug.

6

I forgot to ask. Is there a way that Syncthing can tell me what node it thinks has the most recent file? That might help me reset the nagging error.

7

The rest endpoint that was mentioned @imsodin’s previous post is what we are after and will have what you are after.

8

Simon, Audrius,

I think I already tried the link you are referring to in the previous post. I replied, “I clicked on the link, but it’s not clear what that is supposed to do. It looks like some C or java-script or API? Or ?? something? The linked “worked” but means nothing to me.”

I see something titled, “GET /rest/db/file”. Also, Audrius said, a “rest endpoint”. I do not know what these words mean or what to do with this information in order to determine what node Syncthing thinks the most recent file copy is on.

9

In the parent of the link there’s some info on the rest API and how to access it. And in this thread there’s also info on it Ingored files stay "out of sync"

10

Simon,

I can curl html pages from the Syncthing port 8384. I figured out how to get the API-Key off the Advanced configuration pages on the Syncthing GUI. I see the html GET command that should show me information about which node is expected to have the most recent copy of the file.

Lots of pieces that are not integrated. I do not know know to integrate the proposed GET command with the curl command, simultaneously offering the API key.

Wish I could get this fixed, but I don’t have time right now to get down into the development tools to debug it.

It seems to me that ~no~ other node should have a more recent copy of the file if I just “touched” the file on any given node. Something seems wrong that Syncthing won’t behave that way. I’ll have to wait until other users also get trapped and the issue elevates to a level of a bug the developers can engage on.

11

I am engaging on it - the output from that call will give me information that I need to further narrow the problem down. I simply don’t have any clue what the problem might be at this point, while it is clear, that there is a problem.

You can essentially just copy-paste and adapt the command from the link I posted above (replace all the caps parts with the bits that apply to your system):

curl -X GET -H "X-API-Key: KEYISHERE" 'http://127.0.0.1:8384/rest/db/file?folder=FOLDER_ID&file=RELATIVEPATHTOYOURFILE'
1 Like
12

Simon,

Thank you. Spelling out the URL options in the single quotes helped. The documentation just had “…” and I didn’t know what options to include in the URL.

Below is the output. However, the bug may have “escaped”. In desperation, I renamed the directory instead of just touching the file. Changes propagated and the file error message quit. What I DID notice is that the old directory name keeps coming back and it’s related to a Windows/Linux uppercase lowercase problem. On linux, directory was named Admin-linux. On Windows, directory was named Admin-Linux. Could that perennial problem also cause the “no connected device” problem for just ~one~ of the dozens of files ~in~ that directory?

dell@DELL-E6440:~$ curl -X GET -H "X-API-Key: uWk-privacy-redacted"  'http://127.0.0.1:8384/rest/db/file?folder=3zr-redacted&file=computer\Admin_Linux-temp-sync-quarantine\LILO-BIOS-boot-disk-error-codes.txt'

{
  "availability": [
    {
      "id": "OCLV7CX-redacted-for-privacy-G2SCRQR",
      "fromTemporary": false
    }
  ],
  "global": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2019-07-19T08:05:30-04:00",
    "modifiedBy": "OCLV7CX",
    "mustRescan": false,
    "name": "computer\\Admin_Linux-temp-sync-quarantine\\LILO-BIOS-boot-disk-error-codes.txt",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "sequence": 348275,
    "size": 4139,
    "type": 0,
    "version": [
      "C2PVFR6:1",
      "OCLV7CX:1",
      "2YNUA3L:1"
    ]
  },
  "local": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2019-07-19T08:05:30-04:00",
    "modifiedBy": "OCLV7CX",
    "mustRescan": false,
    "name": "computer\\Admin_Linux-temp-sync-quarantine\\LILO-BIOS-boot-disk-error-codes.txt",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "sequence": 82547,
    "size": 4139,
    "type": 0,
    "version": [
      "C2PVFR6:1",
      "OCLV7CX:1",
      "2YNUA3L:1"
    ]
  }
}

Interestingly, the above queries the new filename, so as expected, no problem. (File is globally owned by the node I renamed it on.) However, querying the old problematic directory name also shows the file globally owned by the same node. …and that is inconsistent with the node wanting to get it from somewhere else (original error message).

{
  "availability": [
    {
      "id": "OCL-redacted-for-privacy-RQR",
      "fromTemporary": false
    }
  ],
  "global": {
    "deleted": true,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2019-06-16T18:52:23.6857714-04:00",
    "modifiedBy": "OCLV7CX",
    "mustRescan": false,
    "name": "computer\\Admin-Linux\\LILO-BIOS-boot-disk-error-codes.txt",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0",
    "sequence": 86865,
    "size": 0,
    "type": 0,
    "version": [
      "BHYUWRT:1",
      "C2PVFR6:3",
      "OCLV7CX:1"
    ]
  },
  "local": {
    "deleted": true,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2019-06-16T18:52:23.6857714-04:00",
    "modifiedBy": "OCLV7CX",
    "mustRescan": false,
    "name": "computer\\Admin-Linux\\LILO-BIOS-boot-disk-error-codes.txt",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0",
    "sequence": 86865,
    "size": 0,
    "type": 0,
    "version": [
      "BHYUWRT:1",
      "C2PVFR6:3",
      "OCLV7CX:1"
    ]
  }
}
13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.