Previous versions were ok. I should have the total local state closer to 7Tb, but as yet it’s not yet fully indexed all the folders, so it’s still showing this
It appears to only be the receive only folders that show wrong figures. I checked the send only jobs and they appear to be reporting the folder / file sizes correctly. Interestingly, the first snip where it shows 1.81Tb global, the send only end shows this…
And I checked the actual folder and the figures tally. So it may be a misreporting issue and is ok (hence the ‘up to date’), just the figures are wrong, perhaps this is why my total (local state) is so low.
Folder types have always send (remote) receive (here)
Just reading Folder shows as “Up to Date” but global and local states do not match. There’s mention of database resets. On the ‘receive only’ I had renamed the index folder as I wanted to downgrade and allowed it to rebuild and then come back to 1.4. I wonder if there is any merit in maybe doing the same thing on the remote computer to see if they then realign. It feels like there is some sort of doubling up on the number of files possibly caused by the index being wiped and rebuilt.
I spoke too soon. I followed the link / instructions verbatim not realising that the first section refered to a config export (which apparently worked). However when I try the following commands
The command itself is actually fine, it just responded that there is no such file (“No such object in the index”). Is the file actually in the folder root? If it’s in a sub-directory, you need to give the path relative to the root (e.g. file=foo/00b7974a-0000-0000-0000-00093d000000.vhdx).
Bit odd, some paths simply refused to work, some servers had too early a version of powershell to work, but eventually I was able to pull the files off a W10 box. They were on 1.4.0 rc2, but it was still a mismatched sync
There was nothing wrong/special with the /rest/db/file outputs, no mismatching deletes at same version and everything valid and no local flags.
It looks like all files at first existed local only, i.e. with the receive only local flag. Then the remote came in, everything got updated fine in the db but in metadata we only added the new global and didn’t remove the old, receive only, file. However I don’t yet have an idea how that would happen.
Is it therefore worth resetting the remote (send only) db? or I could remove the affected folder and re-add it. Or sit tight and see if any future fixes it resolves it.?
No db resetting needed. You just need to recalculate metadata, which can be done by setting the STRECHECKDBEVERY environment var to 0. If you use Synctrayzor I believe there’s a setting to add env vars.
strecheckdbevery has solved the problem. The folders that were misreporting are now realigned
But also the performance issue that I have had for the last week (where the gui freezes and the disk queue goes very high) is also gone / back to normal.
CPU is high, but that’s to be expected as I still have folders to scan, but after 16 hours of uptime, last week I would be locked up, now it’s just plodding along
and the local state is starting to increment whereas it was stuck on 2.??TiB
Perhaps it might be a good idea to invoke the checkdb each time there is a db upgrade to clear out any errors
Nice that it’s working. The performance issue seems unlikely to be related, as the recheck is only about size metadata that’s stored. That’s just for visuals and does not influence the behaviour in general. Thus I do suspect a weird coincidence (I know, no such things as coincidences, but then again… xD ).