I have two machines with Ubuntu 10.04. Machine A is the master. On machine B my home is mounted with NFS from Machine A. Synchronisation works fine on machine A, and also on machine B. But after sync on machine B on machine A it does not work any more. I am logged in at a time on one machine only of course.
I have found out that the hash code in the file ~/.config/syncevolution/default/peers/memotoo/.internal.ini is much more greater after syncing on machine B then after syncing on machine A. I then open .internal.ini and delete the hash code. After that syncevolution creates a new hash. From then sync on machine A works fine until I sync the next time from machine B.
Messages from syncevolution on the command line on machine A during sync after sync on machine B:
[ERROR] error code from SyncEvolution fatal error (local, status 10500)
~/.config/syncevolution/default/peers/memotoo/.internal.ini: HashCode = 10594356235175291768: cannot parse value
machine A: HashCode = 1435593592
machine B: HashCode = 10594356235175291768
Because I use auto sync and the home is NFS mounted, the auto sync also occurs on machine B. Thus the hash code is wrong after that.
Machine B is running in 64 bit mode, isn't it?
The hash code written by machine B is 64 bit wide, which is the reason why machine A cannot read it. The "HashCode" field is "unsigned int" internally.
The use case of sharing a home directory between machines was not forseen when making that choice. It is hard to fix now, because changing the way how the hash gets calculated on 32 bit machines would have side effects (hash mismatch) if done naively. I don't remember how bad it would be, but when I noticed this issue, I decided against changing the algorithm.
How important is this? Obviously it matters to you, so I guess for you the answer is "essential" - it's just not very common.
For me it is not very essential. I know how to fix it. And yes, machine A is 32 bit, machine B is 64 bit. No I understand and can live with it. Some time I will have only 64 bit machines.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/125.