I upgraded my home system to F18 and tried to synchronize my 17GB documents folder with my work machine. As usually happens when I upgrade the OS, Unison informs me that it has to do a full comparison of the file systems. Everything proceeds as normal, until it tries to reconcile the (nonexistent) changes, at which stage it gives the error message Internal error: New archives are not identical. Retaining original archives. Please run Unison again to bring them up to date. ... but of course, running Unison again only results in the same error message. I also tried removing the ~/.unison/ directories to no avail. Given the existence of bug #846833 I compiled a newer version of Unison (2.40.102) for my F17 work computer and F18 home computer. Unfortunately the F18 RPM fails to work, failing with $ unison Fatal error: out of memory. However, the F17 RPM worked on F18 and fixed the problem - I can now synchronize the directories. Please update unison240 to the newest version.
Please try the respective builds on your machines and report back. F-18: http://koji.fedoraproject.org/koji/taskinfo?taskID=4692447 F-17: http://koji.fedoraproject.org/koji/taskinfo?taskID=4692514
$ unison Fatal error: out of memory.
.. so the F18 problem described in the description still exists in your build. I upgraded my work machine to F18 today, so I don't have a F17 computer anymore, but I think that the synchronization problem occurs independent of the Fedora version.
*** Bug 877019 has been marked as a duplicate of this bug. ***
This bug happens mostyl after the complete sync of a file - or when a file is deleted on one or both pcs. The bug might be provoked by deleteing a the same file on two computers - and then starting a unison session. After checking all checksums, just when the screen for selecting sync directions should show up, Unison crashes. backtrace_rating: 4 Package: unison240-2.40.63-7.fc18 OS Release: Fedora release 18 (Spherical Cow)
Created attachment 646655 [details] File: backtrace
A regular crash on any try to synchronize via Unison. backtrace_rating: 4 Package: unison240-2.40.63-7.fc18 OS Release: Fedora release 18 (Spherical Cow)
I've played around with this and in my case the problem was that the F18 build of Unison was compiled against OCaml 4 but F17 (and my CentOS server) uses OCaml 3.12. Both F17 and F18 show the Unison version to be "2.40.63" giving the impression they should talk to each other without issues. The OCaml is (somehow) used to make a hash of both sides, the different OCaml versions create two different hashes for the same file and so Unison always assumes the transfer is corrupted. As previously mentioned, copying the F17 build to the F18 install fixes the problem of getting F18 and older to sync. I assume this is a OCaml 4 regressions, or possibly by design? A work around to the "OCaml" issue should be to mount the remote folder that requires syncing locally, and then use Unison to sync two local files/folders.
A typical racing condition problem at the end of a synchronisation of one or more files. backtrace_rating: 3 Package: unison240-2.40.63-7.fc18 OS Release: Fedora release 18 (Spherical Cow)
*** Bug 883213 has been marked as a duplicate of this bug. ***
*** Bug 883593 has been marked as a duplicate of this bug. ***
Are we talking about two different bugs here ? Some of the comments above describe failure in certain synchronization circumstances, but other comments talk about a situation where simply trying to run unison immediately returns the "out of memory" error (which is also what happens on my installation with FC18).
(In reply to comment #12) > Are we talking about two different bugs here ? Some of the comments above > describe failure in certain synchronization circumstances, but other > comments talk about a situation where simply trying to run unison > immediately returns the "out of memory" error (which is also what happens on > my installation with FC18). Yes. My original problem was that Unison didn't succeed in synchronizing my directories. But then I couldn't compile a newer version on F18 due to the ocaml bug (out of memory), for which I filed this bug.
oh yes, this report is about the crash caused by the big memory allocation. the other issue ("Internal error: New archives are not identical.") is already fixed in unison 2.40.102. sry for the confusion
Well if you look at my bug 883593, you see that it has nothing to do with the act of synchronizing at all. It just does it on startup on 64 bits before you even attempt anything. If you are not seeing the error immediately when running the command "unison" on the terminal, then your issue is possibly different and you should un-duplicate my bug report from this...
@Gregor Tatzner, I think your right, there are/where two issues mentioned here. I've yum updated my Unison to 2.40.102 for 64-Bit, I now run into the "Out Of Memory" bug also mentioned in the first post. I haven't tested on 32-Bit, but can do if it's felt really necessary.
Huh, interesting: I searched for the F17 version of unison through https://apps.fedoraproject.org/packages/s/unison and downloaded unison240-2.40.102-1.fc17.x86_64.rpm ; I then did a yum downgrade the_package, and lo and behold, it works fine. So something is broken in the packaging of the F18 version. Given that both are unison 2.40, perhaps you could do a comparison between the two packages to figure out what's wrong?
I have been bitten by the "out of memory" crash too. It happens regardless of synchronization state, as I took the measure of removing all state while troubleshooting. I worked around the problem on Fedora 18 by simply installing the Fedora 17 build of unison240. This seems related: https://bugzilla.redhat.com/show_bug.cgi?id=877128
(In reply to comment #18) > This seems related: https://bugzilla.redhat.com/show_bug.cgi?id=877128 Yep, I'd say that's a duplicate. The diffrence between the F17 and F18 builds is been worked out to be the Ocaml version, the core Unison code is the same. Appears to be fixed in rawhide, so I'm happy to vote this as closed once it trickle though to the "updates" repo. :-)
*** This bug has been marked as a duplicate of bug 877128 ***