Bug 57340 - Wrong HashCode after sync if home is mounted over NFS
Summary: Wrong HashCode after sync if home is mounted over NFS
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: SyncEvolution (show other bugs)
Version: 1.3
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: SyncEvolution Community
QA Contact:
Depends on:
Reported: 2012-11-20 20:10 UTC by Daniel
Modified: 2018-10-13 12:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Daniel 2012-11-20 20:10:06 UTC
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.
Comment 1 Patrick Ohly 2012-11-20 20:29:49 UTC
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.
Comment 2 Daniel 2012-11-20 21:12:36 UTC
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.
Comment 3 GitLab Migration User 2018-10-13 12:44:17 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.