"syncing: no connected device has the required version of this file"

calmh · July 4, 2025, 1:52pm

If you wouldn’t mind, could you take the Syncthing binary from the latest dev build:

https://github.com/syncthing/syncthing/actions/runs/16075219364/artifacts/3466352886

And run:

syncthing debug database-file tnhbr-gxtuf TreeSizeFreeSetup.exe

and also

syncthing debug database-counts tnhbr-gxtuf

(You don’t need to upgrade your setup to this version, just downloading it and running it with those parameters should produce a couple of tables of information)

sn2024 · July 4, 2025, 2:06pm

I ran the Syncthing from the highlighted zip file but got error.

D:\>syncthing debug database-file tnhbr-gxtuf TreeSizeFreeSetup.exe
syncthing: error: no such folder

D:\>syncthing debug database-counts tnhbr-gxtuf
syncthing: error: no such folder

calmh · July 4, 2025, 2:42pm

You need to unpack the syncthing-amd64 zip file and run the Syncthing from there.

sn2024 · July 4, 2025, 3:02pm

D:\syncthing-windows-amd64-v2.0.0-rc.22.dev.11.gff88430e>syncthing --home=c:\PortableApp\SyncTrayzorPortable-x64\data debug database-file tnhbr-gxtuf TreeSizeFreeSetup.exe
syncthing: error: no such folder

D:\syncthing-windows-amd64-v2.0.0-rc.22.dev.11.gff88430e>syncthing --home=c:\PortableApp\SyncTrayzorPortable-x64\data debug database-counts tnhbr-gxtuf
syncthing: error: no such folder

Same results whether I use --home flag or not.

calmh · July 4, 2025, 5:30pm

Just to confirm, your regular setup is 2.0.0-rc.22?

sn2024 · July 4, 2025, 5:38pm

calmh · July 4, 2025, 9:17pm

I guess in that case it most likely means that the --home is not the path to where the database (index-v2) is stored. I don’t know how the portable thing is set up, sorry.

tomasz86 · July 4, 2025, 9:47pm

In the Web GUI, you can check your actual paths in Help → About → Paths. In this case, the one under “Database Location” should be what you need.

sn2024 · July 4, 2025, 10:14pm

D:\syncthing-windows-amd64-v2.0.0-rc.22.dev.11.gff88430e>syncthing --home=c:\PortableApp\SyncTrayzorPortable-x64\data\syncthing debug database-file tnhbr-gxtuf TreeSizeFreeSetup.exe
DEVICE   TYPE  NAME                   SEQUENCE  DELETED  MODIFIED                      SIZE      FLAGS    VERSION                                BLOCKLIST
-local-  FILE  TreeSizeFreeSetup.exe  499       del      2025-07-04T11:52:36.2804841Z  0         -------  HZJYWFM:1751507473,OMKHRPB:1751629956  -nil-
J5WNYJ6  FILE  TreeSizeFreeSetup.exe  500       del      2025-07-04T11:52:36.2804841Z  0         -------  HZJYWFM:1751507473,OMKHRPB:1751629956  -nil-
23NHXGS  FILE  TreeSizeFreeSetup.exe  445       ---      2025-06-23T03:16:10.2804841Z  13832808  -nG----  HZJYWFM:1751507473                     7B4kLitF
JKX6ZDN  FILE  TreeSizeFreeSetup.exe  320       ---      2025-06-23T03:16:10.2804841Z  13832808  -------  JKX6ZDN:1750992570                     7B4kLitF

D:\syncthing-windows-amd64-v2.0.0-rc.22.dev.11.gff88430e>syncthing --home=c:\PortableApp\SyncTrayzorPortable-x64\data\syncthing debug database-counts tnhbr-gxtuf
DEVICE   TYPE       FLAGS    DELETED  COUNT  SIZE
-local-  FILE       -------  ---      0      0
-local-  FILE       -------  del      1      0
-local-  FILE       --G----  ---      44     1501977502
-local-  FILE       --G----  del      3      0

calmh · July 5, 2025, 7:29am

Thank you, I understand now. Will hack on it.

The problem here is that there is a sync conflict between two versions of the file (scanned independently on two different devices). One of them wins, but the losing device is apparently not online to resolve it at the moment and the conflict remains. No problem so far.

Once the file is deleted, however, it is still in conflict with the old version from the offline device and now we resolve it differently because in a conflict between a deleted and a non-deleted file, the deleted file always loses.

This obviously results in incorrect behaviour in this case.

calmh · July 5, 2025, 8:19am

github.com/syncthing/syncthing

fix: allow deleted files to win conflict resolution

main ← calmh:jb/delconflict

opened 08:10AM - 05 Jul 25 UTC

calmh

+86 -32

We've always, since the introduction of conflicts, had the policy that deletes l…ose against any other change, for safety's sake. This is a problem, however, because it means the sort order of versions is not a total order. That is, given two versions `A` and `B` that are currently in conflict, we will sort them in a given order (let's say `A, B`, so `A < B` for ordering purposes: we say "A wins over B" or "A is newer than B") and consider the first in the list the winner. The loser (who has `B` on disk) will process the conflict at some point and move the file to a conflict copy and announce `A'` as the resolved conflict. The winner (with `A` on disk) doesn't do anything. However, if `A` is deleted the ordering changes. We still have `A < B` and, of course, `Adel < A` (this is not even a conflict, just linear order). In most sane systems this would imply the ordering `Adel < A < B`, however in our case we in fact have `B < Adel` because any version wins over a deleted one, so there is no logical ordering at all of the files at this point. `Adel < A < B < Adel ???` In practice the deleted version may end up at the head or the tail of the list, depending on the order we do the compares. Hence, at this point, "whatever" happens and it's not guaranteed to make any sense. 😬 I propose that we resolve this my simply letting deletes be versions like anything else and maintain a total ordering based on just version vectors with the existing tie breakers like always. That means a delete can win in a conflict situation, and the result should be that the file is moved to a conflict copy on the losing device. I think this retains the data safety to almost the same degree as previously, while removing probably an entire class of strange out of sync bugs...

sn2024 · July 5, 2025, 1:38pm

I don’t get why these files have conflicts. None of them were modified in any way on any devices after they were downloaded from the web.