The problem is that you wrote the full, absolute path for file=. It needs to be the relative path, e.g. if your folder root is F:\yourfolder and the file F:\yourfolder\foo\bar, write foo\bar. Plus I think there’s no folder=*yourFolderID in the screenshot. The url needs to look something like localhost:8384/rest/db/file?file=foo\bar&folder=yourFolderID.
I tried it both ways and got the same result
and targeting this file (garden.jpg)
and also changed the case from upper to lower to see if that had any affect
Case does matter. In the screenshot it always was “Garden.jpg” in the rest path, while it is “garden.jpg” in the file manager. I assume that’s what you meant by “changed the case”, i.e. you did try “garden.jpg”.
Generally, I am out of ideas for now (except for wanting to integrate a “rest client” into the syncthing binary to get rid these kinds of problems).
Path separators and url encodong matter too, just an idea.
I changed the case to match the file name and also changed the filename to both match the PS script and to also ‘touch’ the file, which did actually result in it getting deleted - eventually.
I have now renamed the index folder on the RO side, paused all the folders except the one with the issue and will leave it to scan over night and will see in the morning if there are any differences.
Having removed the RO index folder, it’s at least realised that there is a mismatch in the number of files (as mentions on comment 5)
However after reverting, the query folders still remain
so this time I will wipe the index on the SO end. If that fails I will manually delete them
This is getting odd. The SO end has finished scanning and now it’s decided it is out of sync…
Looking at the out of sync items, they are all the files that were removed previously, but not on the RO end, which is now reporting…
so essentially I have reversed yesterdays ‘Syncthing state’. However the directories on the RO end which should not be there, are still there…
Having reverted the SO folder
thats all fine and as it was yesterday
rescanned the RO folder
and now both are saying up to date, but there is still a file # difference and the undeleted files still exist.
I’m out of ideas, so i’m manually deleting the odd ones.
There’s a clue: There’s 12 out-of-sync directories and 12 directories difference in local vs global state on the SO end. I just don’t know what to do with that clue.
The pictures show that the local directories are containing files that on the remote end were either deleted or in a renamed directory. However it does matter if it’s empty on the remote end as the local end should reflect those changes. At the moment they are not for unknown reasons.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.