First of all I want to thanks for this aplication, it really looks good.
I’ve been testing with a repository with +14000 files and 5GB. There are 6 Nodes, all in the same Lan. But there are tho issues:
Every minute there are a Debug log with a file: block 0 hash mismatch . What does it mean?
All nodes are allways syncing at 99%, there are sone nodes that says 2 or 3 files out of sync, other says 1000 files out of sync, and there is one that sometines, for a few second says that is 100% sync. Is there any way to know the files that are left? Or the files that are out of sync?
The hash mismatch could be a change that changes all the time, or a file that can’t be written properly for some reason. You can see what files are out of sync by expanding the repository in the GUI and clicking the out of sync count.
Hello,
I also have to expres my big thanks to great work to all the developers especialy calmh.
I gave syncthing a new try when my Dropbox get me into troubles. I found that version 0.9.0-beta5 is out and quickly realize that it is working. My previous experience was with version 0.6.0 and that did not even run for me.
I quickly ugraded to 0.9.0 but I still do not underestand why syncthing nodes stuck and show block 0 hash mismatch.
To test the syncthing I setup 4 server nodes and my notebook as the fifth node. Then I moved my ZIM directory to the synchronized volume as a first test. This means that I’m editing the notes in ZIM having all it’s files on synchronized volume.
Thats the desription of my testing infrastructure, or say, part of it. There is other smart stuff connected to this.
Actually when I finished editing of my notes about Syncthing for today, I noticed that all but one of my servers have then “Block 0 hash mismatch” problem. My zim is closed roughly 15 minutes or more and the servers are still not synchronized.
Is there a solution for this? Or what can I do?
Yes I know that brute force, in form of restarting nodes, helps.
Note: It’s maybe hour or two and the nodes are still not in sync.
You’d have to check the log output on the failing side. As noted above (barring obvious bugs), the two possible reasons are that the file could not be written (disk full? permission problem?) or that it changed on the sending side while it was being sent.
If you do end up “fixing” it by restarting, take a copy of the index folder within the configuration directory before restarting, zip it, and please send it to me privately with a note on which file it was that was failing (visible in the gui and probably logs). If there’s some index corruption or something going on, that needs to get fixed.