Hi all
I get this (95% 0B (7 items)) displayed on a linux 0.14.44-rc2 (device A).
There are 3 nodes involved in the folder share where the 7 listed files are. Other nodes are one linux 0.14.43 (device B) and one Win32 0.14.44-rc2 (device C).
All show same local=global=243 non-ignored regular files. A & B & C show Up to Date for the folder share when B & C show Up to Date with the other 2 devices. Device A shows the title message to the Device C only (Device B Up to Date).
List shows 3 filenames with Mod. Device A in folder root and 4 filenames spread in Mod. Device B root and a sub-folder.
IIUC this behaviour was fixed in 0.14.44-rc1 (bug #4668).
The question is : do all the nodes in the cluster need to upgrade to 44-rc1+ for the erroneous display to disappear?
The issue #4668 only fixed the inconsistency of displaying “out of sync items” together with “0 files”, so if you can actually see “7 files” and display the list of out of sync items, that particular issue was resolved. Updating other devices won’t change anything about the underlying issue of being out of sync.
Just to reiterate that I understand the situation correctly:
Device A shows device C as syncing 95%, and the out of sync files list has entries E for folder F. This folder F is up-to-date on all devices.
Do all files E not exist on device C and are not ignored on either A or C?
True : not even any syncthing-regular-picture-filename.jpg.tmp pending in any 3 devices. Ignores templates on the 3 nodes is (?d)(?i)*.lnk, (?d)(?i)*.ini, (?d)(?i)Thumbs.db on the 3 nodes (no (?i) on C as it is a Win). C hosts a single shared folder.
Files E don’t exist in F anymore anywhere.
Files E may exist in an other folder F’ only shared by B to a 4th node D (this D device being a linux 0.14.43 showing everything OK)
All 4 devices knows each other but C & D unknowing each other.
Layout.pdf (22.8 KB)
[EDIT] A was involved in F’ ignoring almost all, but I removed it ATM, restarted all nodes and the issue remain. All files E were removed from A some days ago with fslint-gui as detected as duplicates
Can you post the output of curl -X GET -H "X-API-Key: yourapikey" 'http://localhost:8384/rest/db/file?folder=F&file=pathRelToFolderRoot' | json_pp on both A and C for one of the files reported as out of sync. In windows powershell the command apparently looks like the following, I don’t know how to do it otherwise on windows:
(Invoke-WebRequest -Method Get -Headers @{"X-API-Key"="API-Key"} -Uri "http://localhost:8384/rest/db/completion?device=DEVICE-ID&folder=FOLDER-ID").Content | ConvertFrom-Json
curl -X GET -H "X-API-Key: MyKeyHere" 'http://localhost:8384/rest/db/file?folder=Dog%20of%20three%20head&file=IMG_2499.jpg' | json_pp
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "<a href="https://loc...") at /usr/bin/json_pp line 44.
Another try with othe file in subdir
curl -X GET -H "X-API-Key: MyKeyHere" 'http://localhost:8384/rest/db/file?folder=Dog%20of%20three%20head&file=Récup tél Marie Whatsap/IMG-20170806-WA0004.jpg' | json_pp
JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at /usr/bin/json_pp line 44.
On Win side, I’ll have to find how to Power Shell (WinXP) if possible
I did, I only redacted the post. Is there an error in the output ?
I’m using https+User+pw for the GUI. Do I have to change the command accordingly?
Is there a space before MyKeyHere?
You can see 2 different kind of outputs. I gave several trials. For the 1st one I first renamed the folder to Doth, then reversed to original and retried replacing spaces in name with %20.
For the 2nd file can spaces or “é” or “/” in name be a problem ?
In the lap time, I searched & found some files from E list in B machine: they just were renamed (by me from within F’ on device A when A still belonged to F’). On B, I copied one to F and let it sync to A & C. Nothing bad happened, G=L went +1 on all 3 nodes . I let as is hoping ST would recognize the file hash on A and rebuild the same with original name, but it didn’t. Still on A I copied the file out of ST view, rename to original name, then moved it in F. A scanned it and pushed it to B & C. List then went from 7 to 6.
Then I did nearly the same with another file, but did the rename on place. GUI unsync list briefly jumped from 6 to 7 then immediately down to 5. All nice
I can try to do this for others, but that won’t help to dig the issue. Also, I’m pretty sure I won’t find exact same hash for the 5 remaining… I’ll give a try with a fake file with same name, just to see if ST remembers the genuine hash or don’t worry and only cares with name in this matter.
curl -k -X GET -H "X-API-Key: RemoteDevKey" 'https://192.168.X.Y:8384/rest/db/file?folder=Dog%20of%20three%20head&file=IMG_2499.jpg'
No such object in the index
That means the problem is with the folder string, as the file can’t figure in the UI but not be in the (global) index at all. You did use the folder id, not the folder label? (sorry for asking )
No not necessary, this already contains relevant infos: They do fully agree on global and local versions, so both are in sync. However the index between A and C is somehow messed up, such that A believes C does not have the up to date version of the file (as seen in the availability part). I have no idea how that could have happened and/or how to find out, but resetting the index on A or C should resolve it (-reset-deltas option). Maybe wait with doing that until tomorrow, just in case @AudriusButkevicius or @calmh takes an interest in digging into this further.