Using unison-2.48.3 in batch mode with the option 'copy on conflict', I obtain an error message when a file has been deleted in one repository and changed in another.

Steps for reproducing the error

1. Create a new file test.txt in 'local' folder.
2. Run unison, so that it copies this file to the 'remote' folder.
3. Delete the file test.txt in the 'remote' folder.
4. Edit the file test.txt in the 'local' folder (fill it with some content).
5. Run unison again, with the options

batch = true
prefer = newer
copyonconflict = true

I get the following error message:

UNISON 2.48.3 started propagating changes at 21:41:01.66 on 01 Apr 2016
[BGN] Copying test.txt from [[/home/localfolder]] to [[//server//home/remotefolder]]
100%  00:00 ETAUnison failed: Uncaught exception File "/build/unison-HIcI1m/unison-2.48.3/copy.ml", line 1007, characters 17-23: Assertion failed
Raised at file "/build/unison-HIcI1m/unison-2.48.3/copy.ml", line 1007, characters 17-29
Called from file "/build/unison-HIcI1m/unison-2.48.3/copy.ml", line 1010, characters 2-22
Called from file "/build/unison-HIcI1m/unison-2.48.3/files.ml", line 87, characters 4-55
Called from file "/build/unison-HIcI1m/unison-2.48.3/files.ml", line 311, characters 17-57
Called from file "/build/unison-HIcI1m/unison-2.48.3/remote.ml", line 764, characters 4-24
Called from file "/build/unison-HIcI1m/unison-2.48.3/lwt/lwt.ml", line 75, characters 20-23
Re-raised at file "/build/unison-HIcI1m/unison-2.48.3/lwt/lwt.ml", line 135, characters 12-13
Called from file "list.ml", line 73, characters 12-15
Called from file "/build/unison-HIcI1m/unison-2.48.3/lwt/lwt.ml", line 31, characters 2-37
Called from file "/build/unison-HIcI1m/unison-2.48.3/lwt/lwt.ml", line 83, characters 17-46
Called from file "/build/unison-HIcI1m/unison-2.48.3/lwt/generic/lwt_unix_impl.ml", line 147, characters 6-40
Called from file "/build/unison-HIcI1m/unison-2.48.3/main.ml", line 202, characters 6-24
Called from file "/build/unison-HIcI1m/unison-2.48.3/main.ml", line 131, characters 4-9

[Client and server both run 64-bit versions of Ubuntu 14.04 and use identical builds of unison-2.48.3.]

I tried to subscribe to the mailinglist but it doesn't work.
Please see the error messag from mailserver

[email protected]: connect to
groups.yahoo.com[188.125.93.101]:25: Connection timed out

When syncing file times (the file content is identical) from an external USB drive to an NFS directory, Unison fails with an error:
transport failure • Error in setting modification time: Operation not permitted [utimes(/network/data/bla.tsv)]
Changing the times manually works though:
$ touch /network/data/bla.tsv
If touch can do this, Unison should be able to change the times as well.

I received the error

Fatal error Invalid argument: String.blit / Bytes.blit_string

after completing the first run of a local synchronisation on a Mac running 10.11.16 and Unison 2.48.15.

Any ideas?

Summary:
Unison failed to remove a directory after a rename operation. This appeared to result in the archives being out of sync with the disk. Unison then crashed each time it ran until I manually deleted the directory that unison had failed to delete. Normal operation then resumed.
Attached:
Used profile (Sync.prf) and unison log file.
Configuration:
Unison 2.48.4 compiled with OCaml 4.02.1 running on linux mint 17.2 as client
Unison 2.48.4 binaries for windows downloaded from https://www.irif.fr/~vouillon/unison/ running on windows 10 as server
Native client using attached profile Sync.prf via OpenSSH 6.6. Server (win10) running latest cygwin64 and unison windows native binaries (ie. not using cygwin).
Client log file also attached.
Details:
User renamed directory "2017_01_25" to "2017_01_25 - Long Tailed Tit".
Unison responded as shown in the log file:
UNISON 2.48.4 started propagating changes at 14:15:44.69 on 25 Jan 2017
[BGN] Copying 2017_01_25 - Long Tailed Tit from /home/mispy/Pictures to //MJP-Images/D:/Magda/Pictures
Shortcut: copied D:/Magda/Pictures/2017_01_25 - Long Tailed Tit/IMG_0533.JPG from local file D:/Magda/Pictures/2017_01_25/IMG_0533.JPG
Shortcut: copied D:/Magda/Pictures/2017_01_25 - Long Tailed Tit/IMG_0539.JPG from local file D:/Magda/Pictures/2017_01_25/IMG_0539.JPG
Shortcut: copied D:/Magda/Pictures/2017_01_25 - Long Tailed Tit/IMG_0541.JPG from local file D:/Magda/Pictures/2017_01_25/IMG_0541.JPG
Shortcut: copied D:/Magda/Pictures/2017_01_25 - Long Tailed Tit/IMG_0542.JPG from local file D:/Magda/Pictures/2017_01_25/IMG_0542.JPG
Shortcut: copied D:/Magda/Pictures/2017_01_25 - Long Tailed Tit/IMG_0543.JPG from local file D:/Magda/Pictures/2017_01_25/IMG_0543.JPG
Shortcut: copied D:/Magda/Pictures/2017_01_25 - Long Tailed Tit/Long Tailed Tit IMG_0541.tif from local file D:/Magda/Pictures/2017_01_25/Long Tailed Tit IMG_0541.tif
[END] Copying 2017_01_25 - Long Tailed Tit
[BGN] Deleting 2017_01_25 from //MJP-Images/D:/Magda/Pictures
Failed: Error in deleting:
Directory not empty [rmdir(D:/Magda/Pictures/2017_01_25)]
UNISON 2.48.4 finished propagating changes at 14:15:49.70 on 25 Jan 2017
Synchronization incomplete at 14:15:49 (1 item transferred, 0 skipped, 1 failed)
failed: 2017_01_25
UNISON 2.48.4 started propagating changes at 14:15:50.84 on 25 Jan 2017
[BGN] Copying 2017_01_25 from //MJP-Images/D:/Magda/Pictures to /home/mispy/Pictures
Uncaught exception File "/home/phil/Downloads/Unison/src/copy.ml", line 1007, characters 17-23: Assertion failed
Raised at file "/home/phil/Downloads/Unison/src/lwt/lwt.ml", line 126, characters 22-23
Called from file "/home/phil/Downloads/Unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 490, characters 2-113
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 556, characters 38-66
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 718, characters 6-47
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 756, characters 6-125
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 804, characters 8-47
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 870, characters 21-43

UNISON 2.48.4 started propagating changes at 14:16:05.17 on 25 Jan 2017
[BGN] Copying 2017_01_25 from //MJP-Images/D:/Magda/Pictures to /home/mispy/Pictures
Uncaught exception File "/home/phil/Downloads/Unison/src/copy.ml", line 1007, characters 17-23: Assertion failed
Raised at file "/home/phil/Downloads/Unison/src/lwt/lwt.ml", line 126, characters 22-23
Called from file "/home/phil/Downloads/Unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 490, characters 2-113
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 556, characters 38-66
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 718, characters 6-47
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 756, characters 6-125
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 804, characters 8-47
Called from file "/home/phil/Downloads/Unison/src/uitext.ml", line 870, characters 21-43

Please note: a similar renaming operation completed successfully and may be seen in an earlier part of the log file.

These failures continued each time unison was restarted (cron job) until I spotted the error and manually deleted the directory ("2017_01_25") on the windows machine. It was empty at the time. At the end of the log file the result can be seen - unison recovers, suggesting that the archives state
may have been the problem.

unisonlog.txt
syncprf.txt

Currently Unison moves files by copying them to their new location and then performing delete/backup.
It would be nice to have an option to enforce actual move operation.

That option will help immensely when big files are moved or folders are renamed.

I'm trying to sync a directory mounted on acd_cli (https://github.com/yadayada/acd_cli) but every file fails with

incorrectly transferred  (fingerprint mismatch in file contents) -- temp file saved

All the files are being transferred to the acd mount (rather than from it). I believe that the inode, mtime and perms are used to fingerprint? (the file itself is identical, checked with diff)

I am running with perms=0 so hope that means it is only inode and mtime. These seem to both work and be sensible values on the mount.

Any ideas on what might be going wrong, or even how I might figure out why it is failing?

I'm running v2.48.3

Hi there!

I've rencently been trying to use unison, and I keep running into this issue when it tries to sync my files.

Looking for changes
Reconciling changes
Nothing to do: replicas have not changed since last sync.
Looking for changes
Reconciling changes
new file ---->            Heriot Watt  
Desktop/ING3 : new file           modified on 2016-09-18 at 16:36:02  size 1121376   unknown permissions fdrp MACS
Cours/ING3   : absent
Propagating updates
UNISON 2.48.4 started propagating changes at 15:33:47.95 on 11 Oct 2016
[BGN] Copying Heriot Watt from /Users/thomas/Desktop/ING3 to /Users/thomas/thomas-benguigui/Cours/ING3
Failed: Failed to set modification time of file /Users/thomas/thomas-benguigui/Cours/ING3/.unison.Heriot Watt.2f58f5e2916244a5cbd47ffec295f8b1.unison.tmp to 2016-09-18 at 16:36:02 (1474212962.000000): the time was set to 2016-10-11 at 17:33:49 (1476203629.000000) instead
100%  00:00 ETAFailed [Heriot Watt]: Failed to set modification time of file /Users/thomas/thomas-benguigui/Cours/ING3/.unison.Heriot Watt.2f58f5e2916244a5cbd47ffec295f8b1.unison.tmp to 2016-09-18 at 16:36:02 (1474212962.000000): the time was set to 2016-10-11 at 17:33:49 (1476203629.000000) instead
UNISON 2.48.4 finished propagating changes at 15:33:52.28 on 11 Oct 2016
Saving synchronizer state
Synchronization incomplete at 15:33:52  (0 items transferred, 0 skipped, 1 failed)

Do you guys know what happens, if this is a bug, or just me missing something?

PS: I'm on OSX El Capitan.

Correct steps would be (roughly)

• use 'make' for text UI
• use src/uimac14/*.xcodeproj (+ build in xcode) for graphical UI

Current documentation (and also Makefiles) have e.g. references to uimac09, uimacnew, both of which seem to be gone.

Hi, when cloning the repo, and building on Windows 10 using msys2 / mingw32, the build process succeeds. However, the test (-selftest) seems to fail.

build commands:
make OSARCH=win32gnuc

The build succeeds, the tests don't:

% src/unison.exe -version
unison version 2.50.0 (ocaml 4.02.3)
 % src/unison.exe -selftest
The system cannot find the path specified.
Uncaught exception End_of_file
Raised at file "pervasives.ml", line 384, characters 20-31
Called from file "./uicommon.ml", line 499, characters 13-26
Called from file "./uicommon.ml", line 553, characters 17-41
Called from file "./uicommon.ml", line 736, characters 2-86
Called from file "./uitext.ml", line 839, characters 4-543

compiler / OS versions:

% gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 6.1.0
 % uname
MINGW32_NT-10.0
% ocaml -version
The OCaml toplevel, version 4.02.3

Am I doing something wrong here ?

Thanks in advance,

Peter

Especially useful when unison is running with "-repeat watch" setting in the background. While in the foreground progress it displays what file/directory is currently being processed. On large roots or high system load it can take 10-20 minutes to accomplish.

Having some periodic information in the log is preferable to ensure it's running properly and when to expect new changes applied.

hello all,

unfortunately I have to bring up the topic up ocaml version issue again: My setup consists of 2x PC running Ubuntu 16.04LTS with a NAS running Raspbian Jessie. Most of the time syncing via Unison works great (thanks Benjamin!). However, for some files the operation fails consistently with "lost connection to server" and "input_value: bad bigarray kind". I understand that this might be due to a version mismatch of ocaml...?

For all I know the versions of Unison are identical:

• on both PCs unison-gtk was installed via Software Center from the standard repository. Output of "unison-gtk -version" is "unison version 2.48.3"
• on raspberry I installed via apt-get. Since the "stable" repository contains "2.40.102" I had to install from the "testing". Output of "apt list --installed unison" is "unison/testing,now 2.48.3-1 armhf [installed]"

In the past days I did a bit of digging and found that not only do the unison versions have to match, but also the ocaml versions. Since (again to best of my knowledge) ocaml is not installed on any of my machines, I assume the lib is statically linked into unison...?

First of all, how can I determine the respective ocaml versions on the different machines? And, as a second step, how can I solve this issue, preferably without installing ocaml and then recompiling unison on each machine?

One remark: if my above assumption is correct, wouldn't it be better if the apt repositories contained a unison binary which uses dynamic libs? Then the issue could be solved within apt, i.e. keeping the system update mechanism intact.

In any case thanks a lot for your support!

Regards,
Georg

Hi!

I'm a long-time user of Unison. Most often, I use a diff tool with a GUI such as meld:

diff = meld --label="Local <-> Remote"

When showing the diffs, obviously meld opens its GUI and I can do the merging. However, when I leave, there is still an empty window left open. This displays the results for a command line diff utility, but in my case it is superfluous (and a bit annoying when I have to do a lot of diffing).

I propose adding a new option diff-ui that runs the command, but does not open a result window. Another idea would be to auto-close the result window, but I think that might easily mislead users in certain situations.

Thanks,

Martin

I have to deal with a large amount of excel files that I know that have not been modified. Unfortunately, I have no way to tell unison about the files being safe for fastcheck.

A brave/dirty hex-edition of the binary has helped this user but I could not make it work for me, since Windows must keep some checksum that prevented the dirty hack from running.

I've built unison version unison-2.49.543 and unison-2.48.4 (from http://www.seas.upenn.edu/~bcpierce/unison/download/releases/ ) on Fedora 25.

I built it using simply "make UISTYLE=text" on both the client side and the server side. Both machines were recently upgraded or wiped/installed to Fedora 25.

When sync'ing a large replica (~1TB), after some time, the client always segfaults:

===SNIP===
Shortcut: copied /home/alex/MacBuild/unison/unison-2.48.3/path.ml from local file /home/alex/.unison.Build.7f78c97b4bc1aea68cc67a71dd2bde7f.unison.tmp/unison-2.48.3/path.ml
Shortcut: copied /home/alex/MacBuild/unison/unison-2.48.3/path.mli from local file /home/alex/.unison.Build.7f78c97b4bc1aea68cc67a71dd2bde7f.unison.tmp/unison-2.48.3/path.mli
 52%  90:58 ETASegmentation fault (core dumped)

The kernel buffer:

[ 6658.933941] unison[2475]: segfault at 0 ip 00000000004e346b sp 00007fff1efc9200 error 4 in unison[400000+121000]

Any ideas? I am definitely grasping at straws here.

make -j1 UISTYLE=text THREADS=true NATIVE=true unison unison-fsmonitor
...
ocamlopt -g -I lwt -I ubase -I system -I fsmonitor -I fsmonitor/linux -I fsmonitor/windows -I system/generic -I lwt/generic -c /tmp/unison/src/unison-2.48.3/system.ml
File "/tmp/unison/src/unison-2.48.3/system.ml", line 1:
Error: The implementation /tmp/unison/src/unison-2.48.3/system.ml
does not match the interface system.cmi:
Values do not match:
val symlink : ?to_dir:bool -> string -> string -> unit
is not included in
val symlink : string -> fspath -> unit
Makefile.OCaml:434: recipe for target 'system.cmx' failed
make: *** [system.cmx] Error 2

Same with unison 2.49.543. Both unison version build just fine with ocaml 4.02.x

Setup

Workstation running Unison 2.48 on Ubuntu MATE 16.04 (from Ubuntu repo).
Server running Unison 2.48 (among others) on Raspbian (installed from Raspbian testing repo).

Steps to reproduce

1. Set up sync between client and server like this:

# Unison preferences
label = Home dir
root = /home/me
root = ssh://me@fileserver//srv/file/me
sshargs = -C
addversionno = true
dontchmod = true
perms = 0
path = Documents
path = Pictures

2. Run sync once (using the GTK GUI) to ensure both roots are in sync.
3. Change a file on the workstation, then run sync and propagate changes.
4. Change a file on the server, then run sync and propagate changes.

Expected and actual behavior

I’d expect changes to be detected and reported in each sync run, and to be propagated when I click Go in the GUI. This works correctly for (3). In step (4), changes are shown correctly (one file changed on the server). However, when I click Go, I get the following error:

Fatal error

Lost connection with the server.

Since both discovery of changes and client-to-server propagation work, I would rule out basic issues such as incorrect path names, SSH connectivity issues or a version mismatch. I suspect this to be a bug in Unison.

Here is an example script which demonstrates the problem.
-batch and -auto are just for convenience of the script.

!/bin/bash

set -x
d=$(mktemp -d)
cd $d
mkdir -p root1/dir/bin
touch root1/dir/bin/bin
ln -s /usr/bin/bin root1
x="/usr/bin/unison-2.48 -root root1 -root root2"
HOME=$PWD $x -backupcurr "Regex ." -batch
tree -a # just to show what files exist
rm root1/bin
mv root1/dir/bin root1
HOME=$PWD $x -backupcurr "Regex ." -batch -auto
echo $? # prints 2
tree -a # files synced despite error, but backup dir is unchanged
touch root1/otherfile # test syncing some file now
HOME=$PWD $x -backupcurr "Regex .*" -batch -auto
echo $? # prints 3
tree -a # now files did not sync, backup dir is unchanged
cd; rm -rf $d # cleanup temp dir

I just set up everything needed to build the software (gtk2, lablgtk2).

When running make, I get the desired result: An unison executable.
But when I run make UISTYLE=gtk2, I get the following output:

[maurice unison]$ make UISTYLE=gtk2
make -C src UISTYLE=text
make[1]: Verzeichnis „/home/maurice/dev/unison/src“ wird betreten
UISTYLE = text
Building for Unix
NATIVE = true
THREADS = false
STATIC = false
OSTYPE =
OSARCH = Linux
make tags
make[2]: Verzeichnis „/home/maurice/dev/unison/src“ wird betreten
if [ -f "`which etags`" ]; then \
    etags *.mli */*.mli *.ml */*.ml */*.m *.c */*.c *.txt \
          ; fi 
which: no etags in (/home/maurice/Android/android-studio/bin/:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/maurice/.gem/ruby/2.3.0/bin/)
make[2]: Verzeichnis „/home/maurice/dev/unison/src“ wird verlassen
make[1]: Verzeichnis „/home/maurice/dev/unison/src“ wird verlassen

What I don't understand is why it's still called with UISTYLE=text although I specify gtk2.

I'm running an up-to-date Arch system.
Did I miss something or?

As a first-time user of unison, it was a little difficult to find the latest Windows binaries. (For my debian systems it was easy to get from the distribution). The binaries are strewn across various websites. There is also the issue of trusting a third-party. I had to check the website details and eventually came to realize that they are contributors to this project.

It would be easier if the binaries were hosted here on github itself. FYI, the releases page allows you to attach files to every release, along with change descriptions.

As the files can only be attached by contributors they are easy to trust, and as they reside near the code they are easy to find.

Hi!

There is a nice feature in some visual diff tools that I would love to see in Unison: naming the roots. So, by setting

root = some/path/ -> local
root = other/path/ -> remote

you wouldn't see, say some/path/file.txt and other/path/file.txt, but local/file.txt and remote/file.txt. This would make diffing much easier, especially if you don't remember the exact file paths involved.

I hope that made some sense. Otherwise, please feel free to ask and I'll try to explain myself. :)

Thanks!

Martin

Some gui-version (Mac?) of unision use a tree-view to display the differences before a sync.

The gtk-version doesn't. It would be very helpfull to have tree view where we can (un)fold some parts.

This error seems to be caused by installing the unison executable in
/usr/local/bin/unison
instead of
/usr/bin/unison
because of macOS's rootless mode.

Non-macOS platform ----- (ssh) -----> macOS platform

`` `
non-macOS $ ssh account @ macOS bash
unison

If you run unison, it looks like you are browsing to / usr / bin rather than looking for an executable in / usr / local / bin.

The 2.48.4 tarfile contains a tree src/, while 2.48.3 contained 2.48.3/. The latter format for the file tree in the archive should be preferred, i.e. unison-m.nn.o, where m is major version, nn is minor and o indicates bugfix versions.

Following instructions in
https://unix.stackexchange.com/questions/233504/how-to-use-multiple-versions-of-unison-on-one-system
(How to use multiple versions of unison on one system?)

I have installed unison-all and used

unison -addversionno

to sync a Debian and Raspbian system. But I received this error

Contacting server...
Fatal error: Received unexpected header from the server:
expected "Unison 2.48\n" but received "bash: unison-2.48: command not found\n",
which differs at "b".
:

It seems like the same versions are found but misinterpreted as incompatible.

I assume unison could be improved to understands the version number correctly.

I have reported this problem also at

https://unix.stackexchange.com/questions/330870/unison-addversionno-received-unexpected-header-from-the-server

Hi.

I have some server with low RAM memory.
Unison consume all RAM memory (a lot RAM) and pulls me down servers.
Please How i can limit the RAM memory for Unison?.

Server with 100% of RAM and Unison consume 50%.
Example: Server with 1GB of RAM and Unison consume ~500MB or >500MB.
Example: Server with 3GB of RAM and Unison consume ~1.5GB or >1.5GB.

I start the server then unison have low consume of RAM. When the server fails (There is insufficient memory) then i see high consume of RAM of unison.

Regards.

The fact that different unison versions can't inter-operate seems to create a lot of problems for people in practice. This means in particular that every time we add a new preference, we break compatibility between the development version and whatever version other people may have installed.

Fixing this completely would be quite difficult because the low-level mechanisms that Unison uses to communicate preferences from client to server is based on untyped marshaling. However, most new preferences are only needed on the client (because they affect only the GUI or the reconciliation process, not change detection or propagation), and there's no reason to bump the version number when they are added. It would be fairly easy to mark such preferences as client-local where they are created and tell the preference dumping and reloading mechanism to ignore them. (We'd want to make any dynamic references to them on the server side be fatal errors, just for the sake of paranoia.) This way a client should be able to communicate with a slightly older (or, indeed, slightly newer) server without problems.

I am not sure if this works in other gui-versions so I write about gtk here.

It should be possible to sort for all columns. I miss to sort for "Actions".

And beside of it there should be a way to sort by clicking on the head of each column. This is a usual behaviour in the most gui-frameworks.

I need to run unison with a user that does not have permissions to this folder. Is it possible to specify a different folder?

I've installed Unison on CentOS 6.7 and on Cygwin, both using the git clone method and building from scratch but unison -version responds with 2.49.543 on CentOS and 2.40.102 on Cygwin.

When I try to sync, I receive the error, "Fatal error: Received unexpected header from the server:
expected "Unison 2.40\n" but received "Unison 2.49\n\000\000\000\000\017",
which differs at "Unison 2.49"."

Also, the instructions have changed slightly in Cygwin from what was in INSTALL.win32-cygwin-gnuc. Ocaml has moved from the Interpreters category into their own Ocaml category. In order to compile, I needed ocaml, ocaml-base and ocaml-compiler-libs which are located there, and also flexdll from the Devel category.

Hello, after some investigation I was happy to see that unison uses an intelligent algorithm which transfers only the modified part e.g. of a 15GB large virtual disk image.

But still, the progress is quite slow and generates a lot of I/O.

My test scenario:

• A 15GB virtual machine disk image on my local machine
• Already transfered once via unison to a remote machine
• Local start and shutdown of the virtual machine to provoke changes in the disk image file
• Running unison again.

This process takes more than 10 minutes although only a few megabytes of data are transferred over the network.
Therefore I monitored I/O on both machines and the network traffic.
Here is what I found:

• Unison detects changes to the local file -> good.
• Full read of the 15GB file on the local machine -> ok, surly necessary to detect changes
• Full read of the 15GB file on the remote machine -> for comparison and changeset calculation?
• Network-transfer of the changed data (just a few MB) and simultaneous creation of a temp 15GB file on the remote machine. Since only little data is transferred over the network I assume most of the data is copied from the original remote file. This creates massive I/O on the target machine, since 15GB are read and written to the same disk... -> why isn't there a rsync-like "inplace" option?
• Full read of the 15GB file on the local side and full read of the 15GB file on the target side -> why? verify? This is very time and I/O consuming...

Apropos rsync - in reference to "Making Unison Faster on Large Files" (http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#speeding):

Regarding the "copyprog" option: I couldn't detect any reference to rsync in the debug output (debug=all), or as a separate process. How can I make sure Unison is delegating sync of large files to rsync?

Furthermore, as I understand, rsync is only used for the initial first-time transfer. Is it possible to use rsync also for subsequent syncs?

Thanks!

Mac OS X El Capitan 10.11.5 (15F34), unison 2.48.15
2 volumes: external disk mounted via USB, with recent clone thereof mounted via SMB

In the GUI, Unison will quickly compare the two disks until crashing, with no log output.
On the command line, the following error is shown:

$ unison media
2016-06-08 17:41:58.725 Unison[2173:307171] Roots are not set on the command line
2016-06-08 17:41:58.737 Unison[2173:307171] Connecting to media...
about to parse command linePreferences:
…
[pred] forcepartial 'iTunes/sentinel' = false
[pred] preferpartial 'iTunes/sentinel' = false
<>!Illegal instruction: 4
$

Contents of media.prf:

# Unison preferences file
root = /Volumes/media-1
root = /Volumes/media
path = iTunes

ignore = Name {.DS_Store,*archive*}
#ignore = Name { archive}
ignore = Name .FBCIndex
ignore = Name .FBCLockFolder
ignore = Name .FBCLockFolder]
ignore = Name .Apple*
ignore = Name {Cache*,.Trash*,.VolumeIcon.icns,.HSicon,Temporary*,.Temporary*,TheFindByContentFolder}
ignore = Name {TheVolumeSettingsFolder,.Metadata,.filler.idsff,.Spotlight,.DS_Store,.CFUserTextEncoding}
ignore = Path .*
ignore = Name .*
ignore = Name Thumbs.db
ignore = Name *.tmp
ignore = Name misc

fastcheck = true
sortnewfirst = true
confirmbigdeletes = true
mountpoint = iTunes
times = true
#rsrc = false

#to test
confirmmerge = true
perms = 0
dontchmod = true
links = false

copythreshold = 1000000

#speed up initial comparison; run only once
fastercheckUNSAFE = true
ignorelocks = true

log = true
#debug = verbose
debug = all

Currently Unison backs up all "changed" files which is great as a default behavior but it would helpful to have an option to exclude duplicate files from the backup, such as:

• Moved files
• Copied files
• Files with only metadata being changed

On other hand, some people might prefer linking (symlink/hardlink) those files instead of just excluding them from the backup.

I was doing a sync which had lots of files with permission changes.

[pred] preferpartial 'q/p/c/treetowl.default/webappsstore.sqlite-shm' = false
[pred] forcepartial 'q/p/c/treetowl.default/webappsstore.sqlite-wal' = false
[pred] preferpartial 'q/p/c/treetowl.default/webappsstore.sqlite-wal' = false
<>!<Growing heap to 654360k bytes
Growing heap to 655352k bytes
>!<Growing heap to 656344k bytes
Growing heap to 657336k bytes
Growing heap to 658328k bytes
>!<Growing heap to 659320k bytes
Growing heap to 660312k bytes
>!<Growing heap to 661304k bytes
Growing heap to 662296k bytes
>!<Growing heap to 663288k bytes
Growing heap to 664280k bytes
>!<Growing heap to 665272k bytes
Growing heap to 666264k bytes
>!<Growing heap to 667256k bytes
Growing heap to 668248k bytes
>Growing gray_vals to 2048k bytes
!<Growing heap to 669240k bytes
Growing heap to 670232k bytes
>!<Growing heap to 671224k bytes
>!<Growing heap to 672216k bytes
Growing heap to 673208k bytes
>!<Growing heap to 674200k bytes
Growing heap to 675192k bytes
Growing heap to 676184k bytes
>!Growing heap to 680192k bytes
<>!Uncaught exception Stack overflow
Raised by primitive operation at file "array.ml", line 111, characters 14-41
Called from file "/tmp/buildd/unison-2.48.3/uigtk2.ml", line 3401, characters 12-55
Called from file "/tmp/buildd/unison-2.48.3/uigtk2.ml", line 156, characters 18-22
Called from file "/tmp/buildd/unison-2.48.3/uigtk2.ml", line 3919, characters 4-37
Called from file "/tmp/buildd/unison-2.48.3/uigtk2.ml", line 4276, characters 4-16

Using unison-gtk 2.48.3-1 in debian.

Hi,

On Linux,
I have locally created a symlink to an existing directory..
When I synchronize, Unison says that the symlink is new on the distant host, and so delete the symlink.

It occurs when using times=true and force=newer (or force=older !)
Tested on 2.40.61 and 2.49.543

See below the test. I have created the local symlink TEST_LINK

See also :
http://unix.stackexchange.com/questions/160058/unison-replacing-newer-symlinks-with-older-files-using-the-option-force-newer

Is there a workaround ? I is a problem, I am using Unison in a cron.

Thank you

The output whis -debug all :

unison -version
unison version 2.49.543 (ocaml 4.02.3)

[startup] Preferences:
ui = graphic
host =
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = XXXX
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat =
contactquietly = false
key =
label =
expert = false
height = 15
auto = false
maxthreads = 0
maxsizethreshold = -1
prefer =
force = newer
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
copyonconflict = false
backupdir =
maxbackups = 2
backups = false
backupsuffix =
backupprefix = .bak.$VERSION.
backuploc = central
copymax = 1
copyquoterem = default
copythreshold = -1
copyprogrest = rsync --partial --append-verify --compress
copyprog = rsync --partial --inplace --compress
rsync = true
fastcheck = default
ignorelocks = false
dumparchives = false
showarchive = false
rootsName =
ignorearchives = false
fastercheckUNSAFE = false
fat = false
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
confirmbigdel = true
batch = false
root = ssh://XXXX//home/francis/Documents/SYNC/PNY_EXT3
root = /SYNC/PNY_EXT3
killserver = false
halfduplex = false
stream = true
addversionno = false
servercmd =
sshargs =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
clientHostName = YYY
ignoreinodenumbers = false
links-aux = true
links = default
times = true
group = false
owner = false
numericids = false
dontchmod = false
perms = 1023
watch = true
rsrc-aux = false
rsrc = default
maxerrors = 1
unicodeCS = false
unicodeEnc = false
unicode = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = XXXX
log = true
debugtimes = false
debug = all
addprefsto =
Contacting server...

[pred] ignore 'pub/TEST_LINK' = false
[update] buildUpdateRec: /SYNC/PNY_EXT3/pub/TEST_LINK
[pred] follow 'pub/TEST_LINK' = false
[update] buildUpdate -> New symlink unison

[pred] sortlast 'pub/TEST_LINK' = false
[pred] sortfirst 'pub/TEST_LINK' = false
[sort] pub/TEST_FILE <= pub/TEST_LINK --> -1
[pred] sortlast 'pub/TEST_LINK' = false
[pred] sortfirst 'pub/TEST_LINK' = false
[sort] pub/TEST_LINK <= pub/unison/unison --> -1
[pred] forcepartial 'pub/TEST_LINK' = false
[pred] preferpartial 'pub/TEST_LINK' = false

new link <==== pub/TEST_LINK [f]

SHOULD BE :

new link ==== > pub/TEST_LINK [f]

The same without option "-force newer"

[startup] Preferences:
ui = graphic
host =
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = YYYYY
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat =
contactquietly = false
key =
label =
expert = false
height = 15
auto = false
maxthreads = 0
maxsizethreshold = -1
prefer =
force =
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
copyonconflict = false
backupdir =
maxbackups = 2
backups = false
backupsuffix =
backupprefix = .bak.$VERSION.
backuploc = central
copymax = 1
copyquoterem = default
copythreshold = -1
copyprogrest = rnc --partial --append-verify --compress
copyprog = rsync --partial --inplace --compress
rsync = true
fastcheck = default
ignorelocks = false
dumparchives = false
showarchive = false
rootsName =
ignorearchives = false
fastercheckUNSAFE = false
fat = false
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
confirmbigdel = true
batch = false
root = ssh://XXXX//home/francis/Documents/SYNC/PNY_EXT3
root = /SYNC/PNY_EXT3
killserver = false
halfduplex = false
stream = true
addversionno = false
servercmd =
sshargs =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
clientHostName = XX
ignoreinodenumbers = false
links-aux = true
links = default
times = true
group = false
owner = false
numericids = false
dontchmod = false
perms = 1023
watch = true
rsrc-aux = false
rsrc = default
maxerrors = 1
unicodeCS = false
unicodeEnc = false
unicode = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = XX
log = true
debugtimes = false
debug = all
addprefsto =
Contacting server...

[pred] ignore 'pub/TEST_LINK' = false
[update] buildUpdateRec: /SYNC/PNY_EXT3/pub/TEST_LINK
[pred] follow 'pub/TEST_LINK' = false

[recon] reconcileAll
[recon] reconcile: 1 results
[update] Marking 0 paths equal
[pred] forcepartial 'pub/TEST_LINK' = false
[pred] preferpartial 'pub/TEST_LINK' = false

local presario-...
new link ----> pub/TEST_LINK [f] ls/DSAextract.py, fp=(54a845617ceca1d3f4412ebc9886f3d3,)

Good direction !

Since a recent updated to my Debian/Jessie systems Unison fails to work any more with the error message "Protocol error: corrupted message received". Running unison with the "-debug all" option does not give my any further information. Looking at the Debian change log I see that the updated involved an update to the openssh-client. I suspect this is the problem since I am using unison with ssh urls. The openssh-client version being used is the Debian version 1:6-7p1-5+debu8u3 . The prior version (1:6-7p1-5) worked with Unison. I have no easy way to downgrade this and confirm.

How does fastcheck work and is it stable in 2.48.3 (version in Ubuntu 16.04) and 2.48.4 (latest windows release)?

I just found that a particular file refused to sync although their MD5 sum was different on the source and destination. After adding -fastcheck false the file synced fine.

Just updated to unison-2.48.3, which comes with Ubuntu 16.04. Getting this behavior reliably:

$ unison puffin
Contacting server...
Connected [//firefly//home/selinger -> //puffin.mathstat.dal.ca//home/selinger]
Looking for changes
Waiting for changes from server
Reconciling changes

local puffin.ma...
changed ----> docs/info.txt [f]
<---- changed docs/magellan/20160818/log [f]
<---- changed docs/magellan/20160818/m-index.html [f]
changed ----> hint [f]
changed ----> root/root-log-firefly [f]
changed ----> vital/pins.cpt [f]
changed ----> vital/todo [f]

Proceed with propagating updates? [] y
Propagating updates

UNISON 2.48.3 started propagating changes at 16:41:08.60 on 18 Aug 2016
[BGN] Updating file docs/info.txt from /home/selinger to //puffin.mathstat.dal.ca//home/selinger
[BGN] Updating file docs/magellan/20160818/log from //puffin.mathstat.dal.ca//home/selinger to /home/selinger
[BGN] Updating file docs/magellan/20160818/m-index.html from //puffin.mathstat.dal.ca//home/selinger to /home/selinger
Unison failed: Uncaught exception Failure("input_value: bad bigarray kind")
Raised by primitive operation at file "/tmp/unison-2.48.3/remote.ml", line 453, characters 18-45
Called from file "/tmp/unison-2.48.3/remote.ml", line 459, characters 23-61
Called from file "/tmp/unison-2.48.3/lwt/lwt.ml", line 75, characters 20-23
Re-raised at file "/tmp/unison-2.48.3/lwt/lwt.ml", line 135, characters 12-13
Called from file "list.ml", line 73, characters 12-15
Called from file "/tmp/unison-2.48.3/lwt/lwt.ml", line 31, characters 2-37
Called from file "/tmp/unison-2.48.3/lwt/lwt.ml", line 83, characters 17-46
Called from file "/tmp/unison-2.48.3/lwt/generic/lwt_unix_impl.ml", line 147, characters 6-40
Called from file "/tmp/unison-2.48.3/main.ml", line 202, characters 6-24
Called from file "/tmp/unison-2.48.3/main.ml", line 131, characters 4-9

Fatal error: Lost connection with the server

This is with current HEAD (d860a69):

─> gdb --args ./src/unison data-0k -servercmd ~/.bin/unison    
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./src/unison...done.
(gdb) r
Starting program: /tmp/unison/src/unison data-0k -servercmd /home/whirm/.bin/unison
Unison 2.50.0 (ocaml 4.04.0): Contacting server...
Connected [//0k//var/data -> //1k//var/data]
Looking for changes

Program received signal SIGSEGV, Segmentation fault.
0x00005555557124c0 in intern_rec (dest=0x7ffff111f6e8, dest@entry=0x7fffffffd1f8) at intern.c:430
430	intern.c: No such file or directory.
(gdb) bt
#0  0x00005555557124c0 in intern_rec (dest=0x7ffff111f6e8, dest@entry=0x7fffffffd1f8) at intern.c:430
#1  0x0000555555712ccf in caml_input_val_core (chan=chan@entry=0x555555af21c0, outside_heap=outside_heap@entry=0)
    at intern.c:734
#2  0x0000555555712e67 in caml_input_val (chan=0x555555af21c0) at intern.c:749
#3  caml_input_value (vchan=<optimized out>) at intern.c:759
#4  0x0000555555659636 in camlUpdate__fun_4498 () at /tmp/unison/src/update.ml:335
#5  0x000055555569a251 in camlUtil__convertUnixErrorsToExn_1955 () at /tmp/unison/src/ubase/util.ml:170
#6  0x000055555565b48e in camlUpdate__fun_4710 () at /tmp/unison/src/update.ml:722
#7  0x0000555555668917 in camlGlobals__fun_2050 () at /tmp/unison/src/globals.ml:121
#8  0x000055555569248d in camlLwt__apply_1225 () at /tmp/unison/src/lwt/lwt.ml:75
#9  0x000055555569274e in camlLwt__fun_1451 () at /tmp/unison/src/lwt/lwt.ml:94
#10 0x00005555556ba741 in camlList__iter_1252 () at list.ml:77
#11 0x000055555569216e in camlLwt__restart_1211 () at /tmp/unison/src/lwt/lwt.ml:31
#12 0x000055555568e5d2 in camlLwt_unix_impl__restart_threads_1278 () at /tmp/unison/src/lwt/lwt.ml:83
#13 0x000055555568eca1 in camlLwt_unix_impl__run_1579 () at /tmp/unison/src/lwt/generic/lwt_unix_impl.ml:147
#14 0x000055555563d5b8 in camlUitext__synchronizeOnce_1968 () at /tmp/unison/src/update.ml:2096
#15 0x000055555563df8a in camlUitext__loop_2237 () at /tmp/unison/src/uitext.ml:788
#16 0x000055555563e18d in camlUitext__synchronizeUntilDone_2242 () at /tmp/unison/src/uitext.ml:810
#17 0x000055555563e437 in camlUitext__start_2249 () at /tmp/unison/src/uitext.ml:870
#18 0x0000555555635c3a in camlMain__Body_1550 () at /tmp/unison/src/main.ml:241
#19 0x00005555556350d3 in camlLinktext__entry () at /tmp/unison/src/linktext.ml:19
#20 0x00005555556319a9 in caml_program ()
#21 0x000055555571cc94 in caml_start_program ()
#22 0x000055555571d015 in caml_main (argv=0x7fffffffd6d8) at startup.c:145
#23 0x000055555563126c in main (argc=<optimized out>, argv=<optimized out>) at main.c:37
(gdb) 

The unison binary was scp'ed to the remote host.

Note that Debian's packaged version (2.48.3) is segfaulting too but I don't have debugging symbols for it so I can't check if the stack trace is the same one.

Please let me know if I can provide any more info that may help.

Thanks!

Unison 2.48.3
Windows 10 64-bit

When setting up a new profile and slecting the first directory to sync, Unison crashes. Console says:

(unison 2.48.3 GTK.exe:1992): Gtk-CRITICAL **: gtk_tree_model_filter_get_value: assertion 'GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed

Under an OPAM system, Unison fails to find the proper lablgtk2 path, as this recipe:

OCAMLLIBDIR=$(shell ocamlc -v | tail -1 | sed -e 's/.* //g' | tr '\\' '/' | tr -d '\r')

doesn't quite work under OPAM as it uses a different library layout.

My preferred solution to locate Ocaml dependencies using ocamlfind, however that would add a new dependency to Unison's build.

If you'd be willing to accept that new dependency I'd be happy to provide a patch, another solution would be to detect if ocamlfind is installed and use it, however, my Make-foo is not so good to implement that reliable.

While installing the command line tool (for Mac OS X El Capitan), you get informed that the binary will
be installed in /usr/bin, but in fact it will be installed in /usr/local/bin

Would it be good to change default behaviour to create path if it does not exist on one replica ?

I usually want to just run unison on empty replica and I want to fetch all data from remote one and creating all paths first is problematic as there is no easy way to get path/root combination without merging all includes first. And because I want unison to be as efficient as I want I keep my profiles small and run 1-5 unisons in watch mode at the same time. So I have like 15 root/path combinations.

Hi!

When you do a synchronisation with Unison and some files weren't synchronised, a summary window is opened. This is great, but the summary window should get the focus. Right now, you have to either use the mouse to close this window or, in order to use the ESC key, Alt-Tab away from Unison and then Alt-Tab back . Could you please fix this?

Thanks!

Martin

I have two external drives that I use for backup. The intention is that both drives have identical content. Yesterday I had to re-create their synchronization profile. Each drive stores ~320GB of data, so the scanning took several hours. Synchronizing them went quite fast, as most files were identical. In the process Unison's memory usage went up to 1GB. I suppose that given the amount of synchronized data this might be justified. Then I made changes on one of the disks and decided to re-scan the profile for changes. Surprise: Unison did not free that 1GB of allocated memory but instead began allocating more memory. Is this expected? Does Unison keep the result of previous scans in memory to make subsequent scans faster? Or is it an unintended memory leak?

Steps to reproduce:

1. Open Unison
2. Click "Open" button
3. Get this.

OS X 10.11.6
Unison 2.48.15 binary retrieved from GitHub right now.

When syncing unison check the version string of the other side and give an error if there is a difference. This only works for the unison version itself.

There should be a check vor the version of the used ocaml compiler/lib, too.

We know that there are often reported problems about some errors (e.g. "bad bigarray kind"), when the same unison version is build with different Ocaml versions. e.g. This happen when using Unision from Ubuntu Xenial with and Unision from Debian unstable.

It is impossible to change integer or text values (e.g. for properties
perms, key) in profiles using the GUI (unison-gtk). Instead, the values
become empty if one tries to change them.
The error seems to be around line 1820 in uigtk2.ml.

I'm trying to synchronise a unison 2.48.3 client on Ubuntu 16.04 (presumuably compiled with ocaml 4.02.3, which comes with Ubuntu) with a unison 2.48.3 client on Scientific Linux 7, which I have compiled using the 4.01.1+dev2-2013-12-18+CLOSED version of ocaml.

I can compare differences with files fine, but when it comes to pressing "Go", if there are any files which are new on both sides, I get the error output below:

Unison failed: Uncaught exception Failure("input_value: bad bigarray kind")
Raised by primitive operation at file "${ROOT}/unison-2.48.3/remote.ml", line 453, characters 18-45
Called from file "${ROOT}/unison-2.48.3/remote.ml", line 459, characters 23-61
Called from file "${ROOT}/unison-2.48.3/lwt/lwt.ml", line 75, characters 20-23
Re-raised at file "${ROOT}/unison-2.48.3/lwt/lwt.ml", line 135, characters 12-13
Called from file "list.ml", line 73, characters 12-15
Called from file "${ROOT}/unison-2.48.3/lwt/lwt.ml", line 31, characters 2-37
Called from file "${ROOT}/unison-2.48.3/lwt/lwt.ml", line 83, characters 17-46
Called from file "${ROOT}/unison-2.48.3/lwt/generic/lwt_unix_", line 147, characters 6-40
Called from file "${ROOT}/unison-2.48.3/main.ml", line 202, characters 6-24
Called from file "${ROOT}/unison-2.48.3/main.ml", line 131, characters 4-9