10

I'm trying to get unison working after upgrading to Mac OS X Catalina. Unfortunately, macports installs a more recent version of ocaml (4.08.1), which means that the unison 2.51.2 release won't compile.

Well, that's no problem, I just update to git master on unison, and recompile. Unfortunately, this fails at sync time because the version of ocaml used to compile on the mac (4.08.1) is different from the one used to compile on the other machine (4.07.1). Sigh. Okay, use opam magic to install 4.07.1 on my machine. Everything should be fine, right? No!

Here's the error:

Connected [//zzzmyhost//home/clements/unison-home -> //zzzmyotherhost//Users/clements/clements]
Looking for changes
Uncaught exception Failure("input_value: ill-formed message")
Raised at file "/private/tmp/unison/src/lwt/lwt.ml", line 126, characters 16-23
Called from file "/private/tmp/unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/private/tmp/unison/src/update.ml" (inlined), line 2105, characters 2-69
Called from file "/private/tmp/unison/src/uitext.ml", line 978, characters 16-56
Called from file "/private/tmp/unison/src/uitext.ml", line 1066, characters 6-90
Called from file "/private/tmp/unison/src/uitext.ml", line 1088, characters 19-66
Called from file "/private/tmp/unison/src/uitext.ml", line 1144, characters 21-43

What's going on?

John Clements
  • 16,895
  • 3
  • 37
  • 52

3 Answers3

11

Sigh... the problem here (very non-obvious) is actually with a corrupted/wrong-format syncronization file, created when doing the failed sync in the earlier test.

The solution is just to go into ~/Library/Application Support/Unison (on a UNIX machine this path would presumably live in ~/.unison and delete the archive file that's causing the problem (probably the most recent one). In a pinch, just delete all of the archive files and start over.

John Clements
  • 16,895
  • 3
  • 37
  • 52
  • 1
    Would you have any further reference, e.g., to some bug report? Any hindsight on what caused the corruption? – Tom Hirschowitz Jan 27 '20 at 10:35
  • 1
    Oh, sure! I believe that in an earlier test, I was using a newer version of unison. Not surprisingly, that newer version of unison created an archive file that was in a newer format. Dropping back to the older version, it could see that the most recent synchronization file was written in an unrecognized format, and so it gave up. Honestly, it's not a bug, it's the right behavior, it's just that the error message could be more helpful; for instance, IIUC, unison could catch this error and report the name of the file with the unrecognized format. – John Clements Feb 05 '20 at 00:15
  • 2
    Deleting archive stat files did not help me. I suspect the issue is in some lib unison uses, because I upgraded one side to ubuntu 20.04 recently (the other remains ubuntu 18.04). – Arie Skliarouk May 20 '20 at 06:52
  • 3
    @ArieSkliarouk I have the same issue with Ubuntu 20.04. – kalj Jun 05 '20 at 13:03
  • 1
    @ArieSkliarouk Me too, Ubuntu 20.04 and 18.04 incompatibility. – Ratbert Jun 20 '20 at 17:31
  • This worked for me. I deleted all files in my ~/.unison directory. – calvin Aug 19 '20 at 16:02
4

I've got the same problem between Windows and Ubuntu 20.04 after upgrading from Ubuntu 18.04. I tried the binary from Ubuntu 18.04 in 20.04, which still fails, so the incompatibility is likely inside one of the dependencies.

As a workaround I created a Docker image based on Ubuntu 18.04:

FROM ubuntu:18.04

RUN apt-get update && apt-get dist-upgrade -y
RUN apt-get install unison -y
RUN useradd martin --home /home/martin

WORKDIR /home/martin
USER martin

Building it with docker build -t unison:18.04 .

And then I added a wrapper to ~/bin/unison-2.48.4-docker:

#!/bin/bash

docker run --rm -i \
  -v /home/martin/dirtosync:/home/martin/dirtosync \
  -v /home/martin/.unison:/home/martin/.unison \
  --hostname $(hostname) \
  unison:18.04 unison "$@"

Setting the --hostname is important, since the hostname is part of the archive file.

Inside the profile on my Windows machine I configured:

servercmd = ~/bin/unison-2.48.4-docker
Martin C.
  • 12,140
  • 7
  • 40
  • 52
  • 1
    I think that's a different problem than the OP. Nevertheless, I have the same problem as you and Docker is a good idea for a workaround. The root cause of your and my problem seems on Ubuntu side. Ubuntu 20.04 uses oldish Unison 2.48 but compiled with a recent OCaml compiler with serialization incompatible to older OCaml compilers. The bug causes even incompatibility between Ubuntu 18.04 vs 20.04 although both have unison 2.48. See here: https://bugs.launchpad.net/ubuntu/+source/unison/+bug/1875475 – sema Jan 10 '21 at 17:03
0

In my setup with two windows clients and one Ubuntu 18.04 server, connected by ssh, the problem startet with a second server running on Ubuntu 20.04. Neither the old server nor the windows clients could sync with the new machine.

My solution: Copying the binary from Ubuntu 18.04 to a new directory in the Ubuntu 20.04 machine. This new file is referenced in the "authorized_keys" file of ssh on the new machine.

So far, everything works great with unison 2.48.4.

Alex.
  • 1