Unison File Synchronizer

Version 2.9.1

User Manual and Reference


          ·Reporting Bugs
          ·How You Can Help
          ·Downloading Unison
          ·Running Unison
          ·Contributed Ports
          ·Building Unison from Scratch
                  Installation Options
          ·Local Usage
          ·Remote Usage
          ·Remote Shell Method
          ·Socket Method
          ·Using Unison for All Your Files
          ·Going Further
Basic Concepts
          ·What is an Update?
          ·What is a Conflict?
          ·Caveats and Shortcomings
          ·Running Unison
          ·The .unison Directory
          ·Archive Files
          ·Sample Profiles
                  A Minimal Profile
                  A Basic Profile
                  A Power-User Profile
          ·Keeping Backups
          ·Merging Conflicting Versions
          ·The User Interface
          ·Exit code
          ·Path specification
          ·Ignoring Paths
          ·Symbolic Links
          ·Cross-Platform Synchronization
          ·Slow Links
          ·Fast Update Detection
          ·Click-starting Unison
          ·Frequently Asked Questions
          ·Common Problems
          ·Tricks and Tips
Installing Ssh
Changes in Version 2.9.1
Unison is a file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.

Unison shares a number of features with tools such as configuration management packages (CVS, PRCS, etc.), distributed filesystems (Coda, etc.), uni-directional mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc). However, there are several points where it differs: There is a moderated, very-low-volume announcement list for new Unison releases; the archives of this list are available at the above link. There is also a moderated (but higher volume) discussion list for Unison users.




Unison is free software. You are free to change and redistribute it under the terms of the GNU General Public License. Please see the file COPYING in the Unison distribution for more information.

Reporting Bugs

If Unison is not working the way you expect, here are some steps to follow:

How You Can Help

Unison is a part-time project for its developers: we work on it because we enjoy making something that is useful for us and for the community, but we all have other jobs to do. If you like Unison and want to help improve it, your contributions would be very welcome. For more details on how the code is organized, etc., see the file CONTRIB in the source distribution.

If you don't feel like hacking, you can help us by simply letting us know how you like Unison. Even a short note like ``I'm using it; works fine'' or ``I looked at it but it's not quite what I want because...'' will give us valuable information.


Unison is designed to be easy to install. The following sequence of steps should get you a fully working installation in a few minutes. (If you run into trouble, you may find the suggestions in the Advice section helpful.)

Unison can be used with either of two user interfaces:
  1. a simple textual interface, suitable for dumb terminals (and running from scripts), and
  2. a more sophisticated grapical interface, based on Gtk.
You will need to install a copy of Unison on every machine that you want to synchronize. However, you only need the version with a graphical user interface (if you want a GUI at all) on the machine where you're actually going to display the interface (the client machine). Other machines that you synchronize with can get along just fine with the textual version.

Downloading Unison

If a pre-built binary of Unison is available for the client machine's architecture, just download it and put it somewhere in your search path (if you're going to invoke it from the command line) or on your desktop (if you'll be click-starting it).

The executable file for the graphical version (with a name including gtkui) actually provides both interfaces: the graphical one appears by default, while the textual interface can be selected by including -ui text on the command line. The textui executable provides just the textual interface.

If you don't see a pre-built executable for your architecture, you'll need to build it yourself. See the Building Unison section. (There are also a small number of ``contributed ports'' to other architectures that are not maintained by us. See the Contributed Ports section to check what's available.)

Check to make sure that what you have downloaded is really executable. Either click-start it, or type unison -version at the command line.

Unison can be used in several different modes: with different directories on a single machine, with a remote machine over a direct socket connection, with a remote machine using rsh (on Unix systems), or with a remote Unix system (from either a Unix or a Windows client) using ssh for authentication and secure transfer. If you intend to use the last option, you may need to install ssh; see the Installing Ssh section.

Running Unison

Once you've got Unison installed on at least one system, read the Tutorial section of the user manual (or type unison -doc tutorial) for instructions on how to get started.


Upgrading to a new version of Unison should be as simple as throwing away the old binary and installing the new one.

Before upgrading, it is a good idea to use the old version to make sure all your replicas are completely synchronized. A new version of Unison will sometimes introduce a different format for the archive files used to remember information about the previous state of the replicas. In this case, the old archive will be ignored (not deleted --- if you roll back to the previous version of Unison, you will find the old archives intact), which means that any differences between the replicas will show up as conflicts and need to be resolved manually.

Contributed Ports

A few people have offered to maintain pre-built executables, easy installation scripts, etc., for particular architectures. They are not maintained by us and are not guaranteed to work, be kept up to date with our latest releases, etc., but you may find them useful. Here's what's available at the moment:

Building Unison from Scratch

If a pre-built image is not available, you will need to compile it from scratch; the sources are available from the same place as the binaries.

In principle, Unison should work on any platform to which OCaml has been ported and on which the Unix module is fully implemented. In particular, it has been tested on many flavors of Windows (98, NT, 2000) and Unix (Solaris, Linux, FreeBSD, MacOS X), and on both 32- and 64-bit architectures.

Unison does not work (and probably never will) on MacOS versions 8 or 9.


You'll need the Objective Caml compiler (version 3.04 or later1), which is available from its official site http://caml.inria.fr. Building and installing OCaml on Unix systems is very straightforward; follow the instructions in the distribution. You'll probably want to build the native-code compiler in addition to the bytecode compiler, but this is not absolutely necessary.

(Quick start: on many systems, the following sequence of commands will get you a working and installed compiler: first do make world opt, then su to root, then do make install.)

You'll also need the GNU make utility, standard on many Unix systems. (Type make --version to check that you've got the GNU version.)

Once you've got OCaml installed, grab a copy of the Unison sources, unzip and untar them, change to the new unison directory, and type
            make UISTYLE=text
The result should be an executable file called unison.

Type ./unison to make sure the program is executable. You should get back a usage message.

If you want to build a graphical user interface, choose one of the following: If this step does not work, don't worry: Unison works fine with the textual interface.

Put the unison executable somewhere in your search path, either by adding the Unison directory to your PATH variable or by copying the executable to some standard directory where executables are stored.


Although the binary distribution should work on any version of Windows, some people may want to build Unison from scratch on those systems too.

Bytecode version:
The simpler but slower compilation option to build a Unison executable is to build a bytecode version. You need first install Windows version of the OCaml compiler (version 3.04 or later, available from http://caml.inria.fr). Then grab a copy of Unison sources and type
       make UISTYLE=text NATIVE=false
to compile the bytecode. The result should be an executable file called unison.exe.

Native version:
To build a more efficient, native version of Unison on Windows, you can choose between two options. Both options require the OCaml distribution version 3.04 as well as the Cygwin layer, which provides certain GNU tools. The two options differ in the C compiler employed: MS Visual C++ (MSVC) vs. Cygwin GNU C.

The tradeoff? The files ``INSTALL.win32-msvc'' and ``INSTALL.win32-cygwin-gnuc'' describe the building procedures for the respective options.

Installation Options

The Makefile in the distribution includes several switches that can be used to control how Unison is built. Here are the most useful ones:



Unison can be used with either of two user interfaces:
  1. a straightforward textual interface and
  2. a more sophisticated graphical interface
The textual interface is more convenient for running from scripts and works on dumb terminals; the graphical interface is better for most interactive use. For this tutorial, you can use either.

The command-line arguments to both versions are identical. The graphical version can be run directly by clicking on its icon, but this requires a little set-up (see the Click-starting Unison section). For this tutorial, we assume that you're starting it from the command line.

Unison can synchronize files and directories on a single machine, or between two machines on network. (The same program runs on both machines; the only difference is which one is responsible for displaying the user interface.) If you're only interested in a single-machine setup, then let's call that machine the client. If you're synchronizing two machines, let's call them client and server.

Local Usage

Let's get the client machine set up first, and see how to synchronize two directories on a single machine.

Follow the instructions in the Installation section to either download or build an executable version of Unison, and install it somewhere on your search path. (If you just want to use the textual user interface, download the appropriate textui binary. If you just want to the graphical interface---or if you will use both interfaces [the gtkui binary actually has both compiled in]---then download the gtkui binary.)

Create a small test directory a.tmp containing a couple of files and/or subdirectories, e.g.,
       mkdir a.tmp
       touch a.tmp/a a.tmp/b
       mkdir a.tmp/d
       touch a.tmp/d/f
Copy this directory to b.tmp:
       cp -r a.tmp b.tmp
Now try synchronizing a.tmp and b.tmp. (Since they are identical, synchronizing them won't propagate any changes, but Unison will remember the current state of both directories so that it will be able to tell next time what has changed.) Type:
       unison a.tmp b.tmp

Textual Interface:
Graphical Interface:Next, make some changes in a.tmp and/or b.tmp. For example:
        rm a.tmp/a
        echo "Hello" > a.tmp/b
        echo "Hello" > b.tmp/b
        date > b.tmp/c
        echo "Hi there" > a.tmp/d/h
        echo "Hello there" > b.tmp/d/h
Run Unison again:
       unison a.tmp b.tmp
This time, the user interface will display only the files that have changed. If a file has been modified in just one replica, then it will be displayed with an arrow indicating the direction that the change needs to be propagated. For example,
                 <---  new file   c  [f]
indicates that the file c has been modified only in the second replica, and that the default action is therefore to propagate the new version to the first replica. To follw Unison's recommendation, press the ``f'' at the prompt.

If both replicas are modified and their contents are different, then the changes are in conflict: <-?-> is displayed to indicate that Unison needs guidance on which replica should override the other.
     new file  <-?->  new file   d/h  []
By default, neither version will be propagated and both replicas will remain as they are.

If both replicas have been modified but their new contents are the same (as with the file b), then no propagation is necessary and nothing is shown. Unison simply notes that the file is up to date.

These display conventions are used by both versions of the user interface. The only difference lies in the way in which Unison's default actions are either accepted or overriden by the user.

Textual Interface:
Graphical Interface:

Remote Usage

Next, we'll get Unison set up to synchronize replicas on two different machines.

Follow the instructions in the Installation section to download or build an executable version of Unison on the server machine, and install it somewhere on your search path. (It doesn't matter whether you install the textual or graphical version, since the copy of Unison on the server doesn't need to display any user interface at all.)

It is important that the version of Unison installed on the server machine is the same as the version of Unison on the client machine. But some flexibility on the version of Unison at the client side can be achieved by using the -addversionno option; see the Preferences section.

Now there is a decision to be made. Unison provides two methods for communicating between the client and the server: Decide which of these you want to try, and continue with the Remote Shell Method section or the Socket Method section, as appropriate.

Remote Shell Method

The standard remote shell facility on Unix systems is rsh. A drop-in replacement for rsh is ssh, which provides the same functionality but much better security. (Ssh is available from ftp://ftp.cs.hut.fi/pub/ssh/; up-to-date binaries for some architectures can also be found at ftp://ftp.faqs.org/ssh/contrib. See section A.2 for installation instructions for the Windows version.) Both rsh and ssh require some coordination between the client and server machines to establish that the client is allowed to invoke commands on the server; please refer to the rsh or ssh documentation for information on how to set this up. The examples in this section use ssh, but you can substitute rsh for ssh if you wish.

First, test that we can invoke Unison on the server from the client. Typing
        ssh remotehostname unison -version
should print the same version information as running
        unison -version
locally on the client. If remote execution fails, then either something is wrong with your ssh setup (e.g., ``permission denied'') or else the search path that's being used when executing commands on the server doesn't contain the unison executable (e.g., ``command not found'').

Create a test directory a.tmp in your home directory on the client machine.

Test that the local unison client can start and connect to the remote server. Type
          unison -testServer a.tmp ssh://remotehostname/a.tmp
Now cd to your home directory and type:
          unison a.tmp ssh://remotehostname/a.tmp
The result should be that the entire directory a.tmp is propagated from the client to your home directory on the server.

After finishing the first synchronization, change a few files and try synchronizing again. You should see similar results as in the local case.

If your user name on the server is not the same as on the client, you need to specify it on the command line:
          unison a.tmp ssh://username@remotehostname/a.tmp

Socket Method

To run Unison over a socket connection, you must start a Unison ``daemon'' process on the server. This process runs continuously, waiting for connections over a given socket from client machines running Unison and processing their requests in turn.

Warning: The socket method is insecure: not only are the texts of your changes transmitted over the network in unprotected form, it is also possible for anyone in the world to connect to the server process and read out the contents of your filesystem! (Of course, to do this they must understand the protocol that Unison uses to communicate between client and server, but all they need for this is a copy of the Unison sources.)
To start the daemon, type
       unison -socket NNNN
on the server machine, where NNNN is the socket number that the daemon should listen on for connections from clients. (NNNN can be any large number that is not being used by some other program; if NNNN is already in use, Unison will exit with an error message.) Note that paths specified by the client will be interpreted relative to the directory in which you start the server process; this behavior is different from the ssh case, where the path is relative to your home directory on the server.

Create a test directory a.tmp in your home directory on the client machine. Now type:
       unison a.tmp socket://remotehostname:NNNN/a.tmp
The result should be that the entire directory a.tmp is propagated from the client to the server (a.tmp will be created on the server in the directory that the server was started from). After finishing the first synchronization, change a few files and try synchronizing again. You should see similar results as in the local case.

Using Unison for All Your Files

Once you are comfortable with the basic operation of Unison, you may find yourself wanting to use it regularly to synchronize your commonly used files. There are several possible ways of going about this:

  1. Synchronize your whole home directory, using the Ignore facility (see the Ignore section) to avoid synchronizing temporary files and things that only belong on one host.
  2. Create a subdirectory called shared (or current, or whatever) in your home directory on each host, and put all the files you want to synchronize into this directory.
  3. Create a subdirectory called shared (or current, or whatever) in your home directory on each host, and put links to all the files you want to synchronize into this directory. Use the follow preference (see the Symbolic Links section) to make sure that all these links are treated transparently by Unison.
  4. Make your home directory the root of the synchronization, but tell Unison to synchronize only some of the files and subdirectories within it. This can be accomplished by using the -path switch on the command line:
           unison /home/username ssh://remotehost//home/username -path shared
    The -path option can be used as many times as needed, to synchronize several files or subdirectories:
           unison /home/username ssh://remotehost//home/username \
              -path shared \
              -path pub \
              -path .netscape/bookmarks.html
    These -path arguments can also be put in your preference file. See the Preferences section for an example.
When you synchronize a large directory structure (e.g. your home directory) for the first time, Unison will need to spend a lot of time walking over all the files and building its internal data structures. You'll probably save time if you start off focusing Unison's attention on just a subset of your files, by including the option -path some/small/subdirectory on the command line. When this is working to your satisfaction, take away the -path option and go get lunch while Unison works.

If your replicas are large and at least one of them is on a Windows system, you may find that Unison's default method for detecting changes (which involves scanning the full contents of every file on every sync---the only completely safe way to do it under Windows) is too slow. In this case, you may be interested in the fastcheck preference, documented in the Fast Update Checking section.

Most people find that they only need to maintain a profile (or profiles) on one of the hosts that they synchronize, since Unison is always initiated from this host. (For example, if you're synchronizing a laptop with a fileserver, you'll probably always run Unison on the laptop.) This is a bit different from the usual situation with asymmetric mirroring programs like rdist, where the mirroring operation typically needs to be initiated from the machine with the most recent changes. the Profile section covers the syntax of Unison profiles, together with some sample profiles.

Going Further

On-line documentation for the various features of Unison can be obtained either by typing
        unison -doc topics
at the command line, or by selecting the Help menu in the graphical user interface. The on-line information is essentially identical to this manual.

There are two email lists for users of unison. Visit
for more details.

Basic Concepts

Unison deals in a few straightforward concepts. (A more mathematical development of these concepts can be found in ``What is a File Synchronizer?'' by Sundar Balasubramaniam and Benjamin Pierce [MobiCom 1998]. A more up-to-date version can be found in a recent set of slides.)


A replica's root tells Unison where to find a set of files to be synchronized, either on the local machine or on a remote host. For example,
specifies a local root relative to the directory where Unison is started, while
specifies a root relative to the top of the local filesystem, independent of where Unison is running. Remote roots can begin with ssh://, rsh:// to indicate that the remote server should be started with rsh or ssh:
If the remote server is already running (in the socket mode), then the syntax
is used to specify the hostname and the port that the client Unison should use to contact it.

The syntax for roots is based on that of URIs (described in RFC 2396). The full grammar is:
  replica ::= [protocol:]//[user@][host][:port][/path]
           |  path

  protocol ::= file
            |  socket
            |  ssh
            |  rsh

  user ::= [-_a-zA-Z0-9]+

  host ::= [-_a-zA-Z0-9.]+

  port ::= [0-9]+
When path is given without any protocol prefix, the protocol is assumed to be file:. Under Windows, it is possible to synchronize with a remote directory using the file: protocol over the Windows Network Neighborhood. For example,
       unison foo //host/drive/bar
synchronizes the local directory foo with the directory drive:\bar on the machine host, provided that host is accessible via Network Neighborhood. When the file: protocol is used in this way, there is no need for a Unison server to be running on the remote host. (However, running Unison this way is only a good idea if the remote host is reached by a very fast network connection, since the full contents of every file in the remote replica will have to be transferred to the local machine to detect updates.)

The names of roots are canonized by Unison before it uses them to compute the names of the corresponding archive files, so //saul//home/bcpierce/common and //saul.cis.upenn.edu/common will be recognized as the same replica under different names.


A path refers to a point within a set of files being synchronized; it is specified relative to the root of the replica.

Formally, a path is just a sequence of names, separated by /. Note that the path separator character is always a forward slash, no matter what operating system Unison is running on. Forward slashes are converted to backslashes as necessary when paths are converted to filenames in the local filesystem on a particular host. (For example, suppose that we run Unison on a Windows system, synchronizing the local root c:\pierce with the root ssh://saul.cis.upenn.edu/home/bcpierce on a Unix server. Then the path current/todo.txt refers to the file c:\pierce\current\todo.txt on the client and /home/bcpierce/current/todo.txt on the server.)

The empty path (i.e., the empty sequence of names) denotes the whole replica. Unison displays the empty path as ``[root].''

If p is a path and q is a path beginning with p, then q is said to be a descendant of p. (Each path is also a descendant of itself.)

What is an Update?

The contents of a path p in a particular replica could be a file, a directory, a symbolic link, or absent (if p does not refer to anything at all in that replica). More specifically: Unison keeps a record of the contents of each path after each successful synchronization of that path (i.e., it remembers the contents at the last moment when they were the same in the two replicas).

We say that a path is updated (in some replica) if its current contents are different from its contents the last time it was successfully synchronized.

(What Unison actually calculates is a slight approximation to this definition; see the Caveats and Shortcomings section.)

What is a Conflict?

A path is said to be conflicting if
  1. it has been updated in one replica,
  2. it or any of its descendants has been updated in the other replica, and
  3. its contents in the two replicas are not identical.


Unison operates in several distinct stages:
  1. On each host, it compares its archive file (which records the state of each path in the replica when it was last synchronized) with the current contents of the replica, to determine which paths have been updated.
  2. It checks for ``false conflicts'' --- paths that have been updated on both replicas, but whose current values are identical. These paths are silently marked as synchronized in the archive files in both replicas.
  3. It displays all the updated paths to the user. For updates that do not conflict, it suggests a default action (propagating the new contents from the updated replica to the other). Conflicting updates are just displayed. The user is given an opportunity to examine the current state of affairs, change the default actions for nonconflicting updates, and choose actions for conflicting updates.
  4. It performs the selected actions, one at a time. Each action is performed by first transferring the new contents to a temporary file on the receiving host, then atomically moving them into place.
  5. It updates its archive files to reflect the new state of the replicas.


Given the importance and delicacy of the job that it performs, it is important to understand both what a synchronizer does under normal conditions and what can happen under unusual conditions such as system crashes and communication failures.

Unison is careful to protect both its internal state and the state of the replicas at every point in this process. Specifically, the following guarantees are enforced: The upshot is that it is safe to interrupt Unison at any time, either manually or accidentally.

If an interruption happens while it is propagating updates, then there may be some paths for which an update has been propagated but which have not been marked as synchronized in Unison's archives. This is no problem: the next time Unison runs, it will detect changes to these paths in both replicas, notice that the contents are now equal, and mark the paths as successfully updated when it writes back its private state at the end of this run.

If Unison is interrupted, it may sometimes leave temporary working files (with suffix .tmp) in the replicas. It is safe to delete these files. Also, if the (deprecated) backups flag is set, Unison will leave around old versions of files, with names like file.0.unison.bak. These can be deleted safely, when they are no longer wanted.

Unison is not bothered by clock skew between the different hosts on which it is running. It only performs comparisons between timestamps obtained from the same host, and the only assumption it makes about them is that the clock on each system always runs forward.

If Unison finds that its archive files have been deleted (or that the archive format has changed and they cannot be read, or that they don't exist because this is the first run of Unison on these particular roots), it takes a conservative approach: it behaves as though the replicas had both been completely empty at the point of the last synchronization. The effect of this is that, on the first run, files that exist in only one replica will be propagated to the other, while files that exist in both replicas but are unequal will be marked as conflicting.

Touching a file without changing its contents should never affect Unison's behavior. (On Unix, it uses file modtimes for a quick first pass to tell which files have definitely not changed; then for each file that might have changed it computes a fingerprint of the file's contents and compares it against the last-synchronized contents.)

It is safe to ``brainwash'' Unison by deleting its archive files on both replicas. The next time it runs, it will assume that all the files it sees in the replicas are new.

It is safe to modify files while Unison is working. If Unison discovers that it has propagated an out-of-date change, or that the file it is updating has changed on the target replica, it will signal a failure for that file. Run Unison again to propagate the latest change.

Changes to the ignore patterns from the user interface (e.g., using the `i' key) are immediately reflected in the current profile.

Caveats and Shortcomings

Here are some things to be careful of when using Unison. A complete list of bugs can be found in the file BUGS.txt in the source distribution.


This section covers the features of Unison in detail.

Running Unison

There are several ways to start Unison.

The .unison Directory

Unison stores a variety of information in a private directory on each host. If the environment variable UNISON is defined, then its value will be used as the name of this directory. If UNISON is not defined, then the name of the directory depends on which operating system you are using. In Unix, the default is to use $HOME/.unison. In Windows, if the environment variable USERPROFILE is defined, then the directory will be $USERPROFILE\.unison; otherwise if HOME is defined, it will be $HOME\.unison; otherwise, it will be c:\.unison.

The archive file for each replica is found in the .unison directory on that replica's host. Profiles (described below) are always taken from the .unison directory on the client host.

Note that Unison maintains a completely different set of archive files for each pair of roots.

We do not recommend synchronizing the whole .unison directory, as this will involve frequent propagation of large archive files. It should be safe to do it, though, if you really want to. (Synchronizing the profile files in the .unison directory is definitely OK.)

Archive Files

The name of the archive file on each replica is calculated from This method should work well for most users. However, it is occasionally useful to change the way archive names are generated. Unison provides two ways of doing this.

The function that finds the canonical hostname of the local host (which is used, for example, in calculating the name of the archive file used to remember which files have been synchronized) normally uses the gethostname operating system call. However, if the environment variable UNISONLOCALHOSTNAME is set, its value will be used instead. This makes it easier to use Unison in situations where a machine's name changes frequently (e.g., because it is a laptop and gets moved around a lot).

A more powerful way of changing archive names is provided by the rootalias preference. The preference file may contain any number of lines of the form:
    rootalias = //hostnameA//path-to-replicaA -> //hostnameB//path-to-replicaB
When calculating the name of the archive files for a given pair of roots, Unison replaces any root that matches the left-hand side of any rootalias rule by the corresponding right-hand side.

So, if you need to relocate a root on one of the hosts, you can add a rule of the form:
    rootalias = //new-hostname//new-path -> //old-hostname//old-path
Warning: The rootalias option is dangerous and should only be used if you are sure you know what you're doing. In particular, it should only be used if you are positive that either (1) both the original root and the new alias refer to the same set of files, or (2) the files have been relocated so that the original name is now invalid and will never be used again. (If the original root and the alias refer to different sets of files, Unison's update detector could get confused.) After introducing a new rootalias, it is a good idea to run Unison a few times interactively (with the batch flag off, etc.) and carefully check that things look reasonable---in particular, that update detection is working as expected.


Many details of Unison's behavior are configurable by user-settable ``preferences.''

Some preferences are boolean-valued; these are often called flags. Others take numeric or string arguments, indicated in the preferences list by n or xxx. Most of the string preferences can be given several times; the arguments are accumulated into a list internally.

There are two ways to set the values of preferences: temporarily, by providing command-line arguments to a particular run of Unison, or permanently, by adding commands to a profile in the .unison directory on the client host. The order of preferences (either on the command line or in preference files) is not significant.

To set the value of a preference p from the command line, add an argument -p (for a boolean flag) or -p n or -p xxx (for a numeric or string preference) anywhere on the command line. There is currently no way to set a boolean flag to false on the command line (all the boolean preferences default to false, so this is only a restriction if you've set one to true in your profile and want to reset it temporarily to false from the command line).

Here are all the preferences supported by Unison. (This list can be obtained by typing unison -help.)
Usage: unison [options]
    or unison root1 root2 [options]
    or unison profilename [options]

  -addprefsto xxx     file to add new prefs to
  -addversionno       add version number to name of unison executable on server
  -auto               automatically accept default actions
  -backup xxx         add a regexp to the backup list
  -backups            keep backup copies of files (deprecated: use 'backup')
  -batch              batch mode: ask no questions at all
  -contactquietly      Suppress the 'contacting server' message during startup
  -debug xxx          debug module xxx ('all' -> everything, 'verbose' -> more)
  -doc xxx            show documentation ('-doc topics' lists topics)
  -dumbtty            do not try to change terminal settings in text UI
  -editor xxx         command for displaying the output of the merge program
  -fastcheck xxx      do fast update detection (`true', `false', or `default')
  -follow xxx         add a regexp to the follow list
  -force xxx          force changes from this replica to the other
  -group              synchronize group
  -height n           height (in lines) of main window in graphical interface
  -ignore xxx         add a regexp to the ignore list
  -ignorecase         ignore upper/lowercase spelling of filenames
  -ignorenot xxx      add a regexp to the ignorenot list
  -key xxx            define a keyboard shortcut for this profile
  -killserver         kill server when done (even when using sockets)
  -label xxx          provide a descriptive string label for this profile
  -log                record actions in file specified by logfile preference
  -logfile xxx        Log file name
  -maxbackups n       number of backed up versions of a file
  -merge xxx          command for merging conflicting files
  -merge2 xxx         command for merging files (when no common version exists)
  -numericids         don't map uid/gid values by user/group names
  -owner              synchronize owner
  -path xxx           path to synchronize
  -perms n            part of the permissions which is synchronized
  -prefer xxx         choose this replica's version for conflicting changes
  -root xxx           root of a replica
  -rootalias xxx      Register alias for canonical root names
  -rshargs xxx        other arguments (if any) for remote shell command
  -rshcmd xxx         path to the rsh executable
  -servercmd xxx      name of unison executable on remote server
  -silent             print nothing (except error messages)
  -socket xxx         act as a server on a socket
  -sortbysize         list changed files by size, not name
  -sortfirst xxx      add a regexp to the sortfirst list
  -sortlast xxx       add a regexp to the sortlast list
  -sortnewfirst       list new before changed files
  -sshcmd xxx         path to the ssh executable
  -statusdepth n      status display depth for local files
  -terse              suppress status messages
  -testserver         exit immediately after the connection to the server
  -times              synchronize modification times
  -ui xxx             select user interface ('text' or 'graphic')
  -version            print version and exit
  -xferbycopying      optimize transfers using local copies, if possible
Here, in more detail, are what they do. Many are discussed in even greater detail in other sections of the manual.
addprefsto xxx
By default, new preferences added by Unison (e.g., new ignore clauses) will be appended to whatever preference file Unison was told to load at the beginning of the run. Setting the preference addprefsto filename makes Unison add new preferences to the file named filename instead.

When this flag is set to true, Unison will use unison-currentversionnumber instead of just unison as the remote server command. This allows multiple binaries for different versions of unison to coexist conveniently on the same server: whichever version is run on the client, the same version will be selected on the server.

When set to true, this flag causes the user interface to skip asking for confirmations except for non-conflicting changes. (More precisely, when the user interface is done setting the propagation direction for one entry and is about to move to the next, it will skip over all non-conflicting entries and go directly to the next conflict.)

backup xxx
Including the preference -backup pathspec causes Unison to make back up for each path that matches pathspec. More precisely, for each path that matches this pathspec, Unison will keep several old versions of a file as a backup whenever a change is propagated. These backup files are left in the directory specified by the environment variable UNISONBACKUPDIR (.unison/backup/ by default). The newest backed up copy willhave the same name as the original; older versions will be named with extensions .n.unibck. The number of versions that are kept is determined by the maxbackups preference.

The syntax of pathspec is described in the Path Specification section.

When this flag is true, Unison will keep the old version of a file as a backup whenever a change is propagated. These backup files are left in the same directory, with extension .bak. This flag is probably less useful for most users than the t backup flag.

When this is set to true, the user interface will ask no questions at all. Non-conflicting changes will be propagated; conflicts will be skipped.

If this flag is set, Unison will skip displaying the `Contacting server' window (which some users find annoying) during startup.

debug xxx
This preference is used to make Unison print various sorts of information about what it is doing internally on the standard error stream. It can be used many times, each time with the name of a module for which debugging information should be printed. Possible arguments for debug can be found by looking for calls to Util.debug in the sources (using, e.g., grep). Setting -debug all causes information from all modules to be printed (this mode of usage is the first one to try, if you are trying to understand something that Unison seems to be doing wrong); -debug verbose turns on some additional debugging output from some modules (e.g., it will show exactly what bytes are being sent across the network).

diff xxx
This preference can be used to control the name (and command-line arguments) of the system utility used to generate displays of file differences. The default is `diff'. The diff program should expect two file names as arguments

doc xxx
The command-line argument -doc secname causes unison to display section secname of the manual on the standard output and then exit. Use -doc all to display the whole manual, which includes exactly the same information as the printed and HTML manuals, modulo formatting. Use -doc topics to obtain a list of the names of the various sections that can be printed.

When set to true, this flag makes the text mode user interface avoid trying to change any of the terminal settings. (Normally, Unison puts the terminal in `raw mode', so that it can do things like overwriting the current line.) This is useful, for example, when Unison runs in a shell inside of Emacs.

When dumbtty is set, commands to the user interface need to be followed by a carriage return before Unison will execute them. (When it is off, Unison recognizes keystrokes as soon as they are typed.)

This preference has no effect on the graphical user interface.

editor xxx
This preference is used when unison wants to display the output of the merge program when its return value is not 0. User changes the file as he wants and then save it, unison will take this version for the synchronisation. By default the value is `emacs'.

fastcheck xxx
When this preference is set to true, Unison will use file creation times as `pseudo inode numbers' when scanning replicas for updates, instead of reading the full contents of every file. Under Windows, this may cause Unison to miss propagating an update if the create time, modification time, and length of the file are all unchanged by the update (this is not easy to achieve, but it can be done). However, Unison will never overwrite such an update with a change from the other replica, since it always does a safe check for updates just before propagating a change. Thus, it is reasonable to use this switch under Windows most of the time and occasionally run Unison once with fastcheck set to false, if you are worried that Unison may have overlooked an update. The default value of the preference is auto, which causes Unison to use fast checking on Unix replicas (where it is safe) and slow checking on Windows replicas. For backward compatibility, yes, no, and default can be used in place of true, false, and auto. See the Fast Checking section for more information.

follow xxx
Including the preference -follow pathspec causes Unison to treat symbolic links matching pathspec as `invisible' and behave as if the object pointed to by the link had appeared literally at this position in the replica. See the Symbolic Links section for more details. The syntax of pathspec> is described in the Path Specification section.

force xxx
Including the preference -force root causes Unison to resolve all differences (even non-conflicting changes) in favor of root. This effectively changes Unison from a synchronizer into a mirroring utility.

You can also specify -force newer (or -force older) to force Unison to choose the file with the later (earlier) modtime. In this case, the -times preference must also be enabled.

This preference should be used only if you are sure you know what you are doing!

When this flag is set to true, the group attributes of the files are synchronized. Whether the group names or the group identifiers are synchronizeddepends on the preference numerids.

height n
Used to set the height (in lines) of the main window in the graphical user interface.

ignore xxx
Including the preference -ignore pathspec causes Unison to completely ignore paths that match pathspec (as well as their children). This is useful for avoiding synchronizing temporary files, object files, etc. The syntax of pathspec is described in the Path Specification section, and further details on ignoring paths is found in the Ignoring Paths section.

When set to true, this flag causes Unison to use the Windows semantics for capitalization of filenames---i.e., files in the two replicas whose names differ in (upper- and lower-case) `spelling' are treated as the same file. This flag is set automatically when either host is running Windows. In rare circumstances it is also useful to set it manually (e.g. when running Unison on a Unix system with a FAT [Windows] volume mounted).

ignorenot xxx
This preference overrides the preference ignore. It gives a list of patterns (in the same format as ignore) for paths that should definitely not be ignored, whether or not they happen to match one of the ignore patterns.

Note that the semantics of t ignore and ignorenot is a little counter-intuitive. When detecting updates, Unison examines paths in depth-first order, starting from the roots of the replicas and working downwards. Before examining each path, it checks whether it matches t ignore and does not match t ignorenot; in this case it skips this path and all its descendants. This means that, if some parent of a given path matches an ignore pattern, then it will be skipped even if the path itself matches an ignorenot pattern. In particular, putting ignore = Path * in your profile and then using t ignorenot to select particular paths to be synchronized will not work. Instead, you should use the path preference to choose particular paths to synchronize.

key xxx
Used in a profile to define a numeric key (0-9) that can be used in the graphical user interface to switch immediately to this profile.

When set to true, this flag causes Unison to kill the remote server process when the synchronization is finished. This behavior is the default for ssh connections, so this preference is not normally needed when running over ssh; it is provided so that socket-mode servers can be killed off after a single run of Unison, rather than waiting to accept future connections. (Some users prefer to start a remote socket server for each run of Unison, rather than leaving one running all the time.)

label xxx
Used in a profile to provide a descriptive string documenting its settings. (This is useful for users that switch between several profiles, especially using the `fast switch' feature of the graphical user interface.)

When this flag is set, Unison will log all changes to the filesystems on a file.

logfile xxx
By default, logging messages will be appended to the file unison.log in your HOME directory. Set this preference if you prefer another file.

maxbackups n
This preference specifies the number of backup versions that will be kept by unison, for each path that matches the predicate backup. The default is 2.

merge xxx
This preference can be used to run a merge program which will create a new version of the file with the last backup and the both replicas. This new version will be used for the synchronization. See the Merging Conflicting Versions section for further detail.

merge2 xxx
This preference can be used to run a merge program which will create a new version of the file with the last backup and the both replicas. This new version will be used for the synchronization. See the Merging Conflicting Versions section for further detail.

When this flag is set to true, groups and users are synchronized numerically, rather than by name.

The special uid 0 and the special group 0 are never mapped via user/group names even if this preference is not set.

When this flag is set to true, the owner attributes of the files are synchronized. Whether the owner names or the owner identifiers are synchronizeddepends on the preference extttnumerids.

path xxx
When no path preference is given, Unison will simply synchronize the two entire replicas, beginning from the given pair of roots. If one or more path preferences are given, then Unison will synchronize only these paths and their children. (This is useful for doing a fast synch of just one directory, for example.) Note that path preferences are intepreted literally---they are not regular expressions.

perms n
The integer value of this preference is a mask indicating which permission bits should be synchronized. It is set by default to 0o1777: all bits but the set-uid and set-gid bits are synchronised (synchronizing theses latter bits can be a security hazard). If you want to synchronize all bits, you can set the value of this preference to -1.

prefer xxx
Including the preference -prefer root causes Unison always to resolve conflicts in favor of root, rather than asking for guidance from the user. (The syntax of root is the same as for the root preference, plus the special values newer and older.)

This preference should be used only if you are sure you know what you are doing!

root xxx
Each use of this preference names the root of one of the replicas for Unison to synchronize. Exactly two roots are needed, so normal modes of usage are either to give two values for root in the profile, or to give no values in the profile and provide two on the command line. Details of the syntax of roots can be found in the Roots section.

The two roots can be given in either order; Unison will sort them into a canonical order before doing anything else. It also tries to `canonize' the machine names and paths that appear in the roots, so that, if Unison is invoked later with a slightly different name for the same root, it will be able to locate the correct archives.

rootalias xxx
When calculating the name of the archive files for a given pair of roots, Unison replaces any roots matching the left-hand side of any rootalias rule by the corresponding right-hand side.

rshargs xxx
The string value of this preference will be passed as additional arguments (besides the host name and the name of the Unison executable on the remote system) to the ssh or rsh command used to invoke the remote server. (This option is used for passing arguments to both rsh or ssh---that's why its name is rshargs rather than sshargs.)

rshcmd xxx
This preference can be used to explicitly set the name of the rsh executable (e.g., giving a full path name), if necessary.

servercmd xxx
This preference can be used to explicitly set the name of the Unison executable on the remote server (e.g., giving a full path name), if necessary.

When this preference is set to true, the textual user interface will print nothing at all, except in the case of errors. Setting silent to true automatically sets the batch preference to true.

When this flag is set, the user interface will list changed files by size (smallest first) rather than by name. This is useful, for example, for synchronizing over slow links, since it puts very large files at the end of the list where they will not prevent smaller files from being transferred quickly.

This preference (as well as the other sorting flags, but not the sorting preferences that require patterns as arguments) can be set interactively and temporarily using the 'Sort' menu in the graphical user interface.

sortfirst xxx
Each argument to sortfirst is a pattern pathspec, which describes a set of paths. Files matching any of these patterns will be listed first in the user interface. The syntax of pathspec is described in the Path Specification section.

sortlast xxx
Similar to sortfirst, except that files matching one of these patterns will be listed at the very end.

When this flag is set, the user interface will list newly created files before all others. This is useful, for example, for checking that newly created files are not `junk', i.e., ones that should be ignored or deleted rather than synchronized.

sshcmd xxx
This preference can be used to explicitly set the name of the ssh executable (e.g., giving a full path name), if necessary.

sshversion xxx
This preference can be used to control which version of ssh should be used to connect to the server. Legal values are 1 and 2, which will cause unison to try to use ssh1 orssh2 instead of just ssh to invoke ssh. The default value is empty, which will make unison use whatever version of ssh is installed as the default `ssh' command.

statusdepth n
This preference suppresses the display of status messages during update detection on the local machine for paths deeper than the specified cutoff. (Displaying too many local status messages can slow down update detection somewhat.)

When this preference is set to true, the user interface will not print status messages.

Setting this flag on the command line causes Unison to attempt to connect to the remote server and, if successful, print a message and immediately exit. Useful for debugging installation problems. Should not be set in preference files.

When this flag is set to true, file modification times (but not directory modtimes) are propagated.

ui xxx
This preference selects either the graphical or the textual user interface. Legal values are graphic or text.

If the Unison executable was compiled with only a textual interface, this option has no effect. (The pre-compiled binaries are all compiled with both interfaces available.)

Print the current version number and exit. (This option only makes sense on the command line.)

When this preference is set, Unison will try to avoid transferring file contents across the network by recognizing when a file with the required contents already exists in the target replica. This usually allows file moves to be propagated very quickly. The default value is exttttrue.


A profile is a text file that specifies permanent settings for roots, paths, ignore patterns, and other preferences, so that they do not need to be typed at the command line every time Unison is run. Profiles should reside in the .unison directory on the client machine. If Unison is started with just one argument name on the command line, it looks for a profile called name.prf in the .unison directory. If it is started with no arguments, it scans the .unison directory for files whose names end in .prf and offers a menu (provided that the Unison executable is compiled with the graphical user interface). If a file named default.prf is found, its settings will be offered as the default choices.

To set the value of a preference p permanently, add to the appropriate profile a line of the form
        p = true
for a boolean flag or
        p = <value>
for a preference of any other type.

Whitespaces around p and xxx are ignored. A profile may also include blank lines, and lines beginning with #; both kinds of lines are ignored.

When Unison starts, it first reads the profile and then the command line, so command-line options will override settings from the profile.

Profiles may also include lines of the form include name, which will cause the file name (or name.prf, if name does not exist in the .unison directory) to be read at the point, and included as if its contents, instead of the include line, was part of the profile. Include lines allows settings common to several profiles to be stored in one place.

A profile may include a preference `label = desc' to provide a description of the options selected in this profile. The string desc is listed along with the profile name in the profile selection dialog, and displayed in the top-right corner of the main Unison window in the graphical user interface.

The graphical user-interface also supports one-key shortcuts for commonly used profiles. If a profile contains a preference of the form `key = n', where n is a single digit, then pressing this digit key will cause Unison to immediately switch to this profile and begin synchronization again from scratch. In this case, all actions that have been selected for a set of changes currently being displayed will be discarded.

Sample Profiles

A Minimal Profile

Here is a very minimal profile file, such as might be found in .unison/default.prf:
    # Roots of the synchronization
    root = /home/bcpierce
    root = ssh://saul//home/bcpierce

    # Paths to synchronize 
    path = current
    path = common
    path = .netscape/bookmarks.html

A Basic Profile

Here is a more sophisticated profile, illustrating some other useful features.
    # Roots of the synchronization
    root = /home/bcpierce
    root = ssh://saul//home/bcpierce

    # Paths to synchronize 
    path = current
    path = common
    path = .netscape/bookmarks.html

    # Some regexps specifying names and paths to ignore
    ignore = Name temp.*
    ignore = Name *~
    ignore = Name .*~
    ignore = Path */pilot/backup/Archive_*
    ignore = Name *.o
    ignore = Name *.tmp

    # Window height
    height = 37

    # Keep a backup copy of the entire replica
    backup = Name *

    # Use this command for displaying diffs
    diff = diff -y -W 79 --suppress-common-lines

    # Log actions to the terminal
    log = true

A Power-User Profile

When Unison is used with large replicas, it is often convenient to be able to synchronize just a part of the replicas on a given run (this saves the time of detecting updates in the other parts). This can be accomplished by splitting up the profile into several parts --- a common part containing most of the preference settings, plus one ``top-level'' file for each set of paths that need to be synchronized. (The include mechanism can also be used to allow the same set of preference settings to be used with different roots.)

The collection of profiles implementing this scheme might look as follows. The file default.prf is empty except for an include directive:
    # Include the contents of the file common
    include common
Note that the name of the common file is common, not common.prf; this prevents Unison from offering common as one of the list of profiles in the opening dialog (in the graphical UI).

The file common contains the real preferences:
    # (... other preferences ...)

    # If any new preferences are added by Unison (e.g. 'ignore'
    # preferences added via the graphical UI), then store them in the
    # file 'common' rathen than in the top-level preference file
    addprefsto = common

    # regexps specifying names and paths to ignore
    ignore = Name temp.*
    ignore = Name *~
    ignore = Name .*~
    ignore = Path */pilot/backup/Archive_*
    ignore = Name *.o
    ignore = Name *.tmp
Note that there are no path preferences in common. This means that, when we invoke Unison with the default profile (e.g., by typing 'unison default' or just 'unison' on the command line), the whole replicas will be synchronized. (If we never want to synchronize the whole replicas, then default.prf would instead include settings for all the paths that are usually synchronized.)

To synchronize just part of the replicas, Unison is invoked with an alternate preference file---e.g., doing 'unison papers', where the preference file papers.prf contains
    path = current/papers
    path = older/papers
    include common
causes Unison to synchronize just the subdirectories current/papers and older/papers.

The key preference can be used in combination with the graphical UI to quickly switch between different sets of paths. For example, if the file mail.prf contains
    path = Mail
    batch = true
    key = 2
    include common
then pressing 2 will cause Unison to look for updates in the Mail subdirectory and (because the batch flag is set) immediately propagate any that it finds.

Keeping Backups

Unison can maintain full backups of the last-synchronized versions of some of the files in each replica; these function both as backups in the usual sense and as the ``common version'' when invoking external merge programs.

The backed up files are stored in a directory ~/.unison/backup on each host. The name of this directory can be changed by setting the environment variable UNISONBACKUPDIR. Files are added to the backup directory whenever unison updates its archive. This means that It is safe to manually delete files from the backup directory (or to throw away the directory itself). Before unison uses any of these files for anything important, it checks that its fingerprint matches the one that it expects.

The preference backup controls which files are actually backed up: for example, giving the preference `backup = Path *' causes backing up of all files. The preference backupversions controls how many previous versions of each file are kept. The default is value 2 (i.e., the last synchronized version plus one backup). For backward compatibility, the backups preference is also still supported, but backup is now preferred.

Merging Conflicting Versions

Both user interfaces offer a `merge' command that can be used to interactively merge conflicting versions of a file. It is invoked by selecting a conflicting file and pressing `m'.

The actual merging is performed by an external program. The preferences merge and merge2 control how this program is invoked. If a backup exists for this file (see the backup preference), then the merge preference is used for this purpose; otherwise merge2 is used. In both cases, the value of the preference should be a string representing the command that should be passed to a shell to invoke the merge program. Within this string, the special substrings CURRENT1, CURRENT2, NEW, and OLD may appear at any point. Unison will substitute these substrings as follows before invoking the command: For example, on Unix systems setting the merge preference to
   merge = diff3 -m CURRENT1 OLD CURRENT2 > NEW
will tell Unison to use the external diff3 program for merging. A large number of external merging programs are available. For example, emacs users may find the following settings convenient:
    merge2 = emacs -q --eval '(ediff-merge-files "CURRENT1" "CURRENT2" 
               nil "NEW")' 
    merge = emacs -q --eval '(ediff-merge-files-with-ancestor 
               "CURRENT1" "CURRENT2" "OLD" nil "NEW")' 
(These commands are displayed here on two lines to avoid running off the edge of the page. In your preference file, each command should be written on a single line.)

If the external program exits without leaving any file at the path NEW, Unison considers the merge to have failed. If the merge program writes a file called NEW but exits with a non-zero status code, then Unison considers the merge to have succeeded but to have generated conflicts. In this case, it attempts to invoke an external editor so that the user can resolve the conflicts. The value of the editor preference controls what editor is invoked by Unison. The default is emacs.

Please send us suggestions for other useful values of the merge2 and merge preferences---we'd like to give several examples in the manual.)

The User Interface

Both the textual and the graphical user interfaces are intended to be mostly self-explanatory. Here are just a few tricks:

Exit code

When running in the textual mode, Unison returns an exit status, which describes whether, and at which level, the synchronization was successful. The exit status could be useful when Unison is invoked from a script. Currently, there are four possible values for the exit status: The graphical interface does not return any useful information through the exit status.

Path specification

Several Unison preferences (e.g., ignore/ignorenot, follow, sortfirst/sortlast, backup) specify individual paths or sets of paths. These preferences share a common syntax based on regular-expressions. Each preference is associated with a list of path patterns; the paths specified are those that match any one of the path pattern.

Some examples of path patterns appear in the Ignoring Paths section.

Ignoring Paths

Most users of Unison will find that their replicas contain lots of files that they don't ever want to synchronize --- temporary files, very large files, old stuff, architecture-specific binaries, etc. They can instruct Unison to ignore these paths using patterns introduced in the Path Patterns section.

For example, the following pattern will make Unison ignore any path containing the name CVS or a name ending in .cmo:
             ignore = Name {CVS,*.cmo}
The next pattern makes Unison ignore the path a/b:
             ignore = Path a/b
This pattern makes Unison ignore any path beginning with a/b and ending with a name ending by .ml.
             ignore = Regex a/b/.*\.ml
Note that regular expression patterns are ``anchored'': they must match the whole path, not just a substring of the path.

Here are a few extra points regarding the ignore preference.

Symbolic Links

Ordinarily, Unison treats symbolic links in Unix replicas as ``opaque'': it considers the contents of the link to be just the string specifying where the link points, and it will propagate changes in this string to the other replica.

It is sometimes useful to treat a symbolic link ``transparently,'' acting as though whatever it points to were physically in the replica at the point where the symbolic link appears. To tell Unison to treat a link in this manner, add a line of the form
             follow = pathspec
to the profile, where pathspec is a path pattern as described in the Path Patterns section.

Windows file systems do not support symbolic links; Unison will refuse to propagate an opaque symbolic link from Unix to Windows and flag the path as erroneous. When a Unix replica is to be synchronized with a Windows system, all symbolic links should match either an ignore pattern or a follow pattern.


Synchronizing the permission bits of files is slightly tricky when two different filesytems are involved (e.g., when synchronizing a Windows client and a Unix server). In detail, here's how it works:

Cross-Platform Synchronization

If you use Unison to synchronize files between Windows and Unix systems, there are a few special issues to be aware of.

Case conflicts. In Unix, filenames are case sensitive: foo and FOO can refer to different files. In Windows, on the other hand, filenames are not case sensitive: foo and FOO can only refer to the same file. This means that a Unix foo and FOO cannot be synchronized onto a Windows system --- Windows won't allow two different files to have the ``same'' name. Unison detects this situation for you, and reports that it cannot synchronize the files.

You can deal with a case conflict in a couple of ways. If you need to have both files on the Windows system, your only choice is to rename one of the Unix files to avoid the case conflict, and re-synchronize. If you don't need the files on the Windows system, you can simply disregard Unison's warning message, and go ahead with the synchronization; Unison won't touch those files. If you don't want to see the warning on each synchronization, you can tell Unison to ignore the files (see the Ignore section).

Illegal filenames. Unix allows some filenames that are illegal in Windows. For example, colons (`:') are not allowed in Windows filenames, but they are legal in Unix filenames. This means that a Unix file foo:bar can't be synchronized to a Windows system. As with case conflicts, Unison detects this situation for you, and you have the same options: you can either rename the Unix file and re-synchronize, or you can ignore it.

Slow Links

Unison is built to run well even over relatively slow links such as modems and DSL connections.

Unison uses the ``rsync protocol'' designed by Andrew Tridgell and Paul Mackerras to greatly speed up transfers of large files in which only small changes have been made. More information about the rsync protocol can be found at the rsync web site (http://samba.anu.edu.au/rsync/).

If you are using Unison with ssh, you may get some speed improvement by enabling ssh's compression feature. Do this by adding the option ``-rshargs -C'' to the command line or ``rshargs = -C'' to your profile.

Fast Update Detection

If your replicas are large and at least one of them is on a Windows system, you may find that Unison's default method for detecting changes (which involves scanning the full contents of every file on every sync---the only completely safe way to do it under Windows) is too slow. Unison provides a preference fastcheck that, when set to yes, causes it to use file creation times as 'pseudo inode numbers' when scanning replicas for updates, instead of reading the full contents of every file.

When fastcheck is set to no, Unison will perform slow checking---re-scanning the contents of each file on each synchronization---on all replicas. When fastcheck is set to default (which, naturally, is the default), Unison will use fast checks on Unix replicas and slow checks on Windows replicas.

This strategy may cause Unison to miss propagating an update if the create time, modification time, and length of the file are all unchanged by the update (this is not easy to achieve, but it can be done). However, Unison will never overwrite such an update with a change from the other replica, since it always does a safe check for updates just before propagating a change. Thus, it is reasonable to use this switch most of the time and occasionally run Unison once with fastcheck set to no, if you are worried that Unison may have overlooked an update.

Click-starting Unison

On Windows NT/2k systems, the graphical version of Unison can be invoked directly by clicking on its icon. On Windows 95/98 systems, click-starting also works, as long as you are not using ssh. Due to an incompatibility with ocaml and Windows 95/98 that is not under our control, you must start Unison from a DOS window in Windows 95/98 if you want to use ssh.

When you click on the Unison icon, two windows will be created: Unison's regular window, plus a console window, which is used only for giving your password to ssh (if you do not use ssh to connect, you can ignore this window). When your password is requested, you'll need to activate the console window (e.g., by clicking in it) before typing. If you start Unison from a DOS window, Unison's regular window will appear and you will type your password in the DOS window you were using.

To use Unison in this mode, you must first create a profile (see the Profile section). Use your favorite editor for this.


Frequently Asked Questions

(See the Common Problems section and the Tips and Tricks section for further suggestions.)

Common Problems

If you're having problems with Unison, the suggestions in this section may help.

A general recommendation is that, if you've gotten into a state you don't understand, deleting the archive files on both replicas (files with names like arNNNNNNNNNNNNNNN in the .unison directory) will return you to a blank slate. If the replicas are identical, then deleting the archives is always safe. If they are not identical, then deleting the archives will cause all files that exist on one side but not the other to be copied, and will report conflicts for all non-identical files that do exist on both sides.

(If you think the behavior you're observing is an actual bug, then you might consider moving the archives to somewhere else instead of deleting them, so that you can try to replicate the bad behavior and tell us what more clearly happened.)

Tricks and Tips

Installing Ssh

Your local host will need just an ssh client; the remote host needs an ssh server (or daemon), which is available on Unix systems.2 Unison is known to work with ssh version 1.2.27 (Unix) and version 1.2.14 (Windows); other versions may or may not work.


  1. Install ssh.
    1. Become root. (If you do not have administrator permissions, ask your system manager to install an ssh client and an ssh server for you and skip this section.)
    2. Download ssh-1.2.27.tar.gz from ftp://ftp.ssh.com/pub/ssh/.
    3. Install it:
      • Unpack the archive (gunzip ssh-1.2.27.tar.gz and then tar xvf ssh-1.2.27.tar.gz).
      • following instructions in INSTALL, enter ./configure, make, and make install.
      • to run the ssh daemon:
        • find the server daemon sshd (e.g., /usr/local/sbin/sshd on RedHat-Linux systems).
        • put its full pathname in the system initialization script to have it run at startup (this script is called /etc/rc.d/rc.sysinit on RedHat-Linux, for example).
    4. Once a server is running on the remote host and a client is available on the local host, you should be able to connect with ssh in the same way as with rsh (e.g., ssh foobar, then enter your password).
  2. If you like, you can now set up ssh so that you only need to type your password once per X session, rather than every time you run Unison (this is not necessary for using ssh with Unison, but it saves typing).
    1. Build your keys :
      • enter ssh-keygen and type a passphrase as required.
      • your private key is now in ~/.ssh/identity (this file must remain private) and your public key in ~/.ssh/identity.pub.
    2. Allow user-mode secure connection.
      • append contents of the local file ~/.ssh/identity.pub to the file ~/.ssh/authorized_keys on the remote system.
      • Test that you can connect by starting ssh and giving the passphrase you just chose instead of your remote password.
    3. Create an agent to manage authentication for you :
      • start ssh-agent with the parent program whose children will be granted automatic connections (e.g., ssh-agent bash or ssh-agent startx).
      • enter ssh-add to enter your passphrase and enable automatic login for connections to come.
      • you should now be able to run Unison using SSH without giving any passphrase or password.
      • to kill the agent, enter ssh-agent -k, or simply exit the program you launched using ssh-agent.


Many Windows implementations of ssh only provide graphical interfaces, but Unison requires an ssh client that it can invoke with a command-line interface. A suitable version of ssh can be installed as follows.

  1. Download an ssh executable. Warning: there are many implementations and ports of ssh for Windows, and not all of them will work with Unison. We have gotten Unison to work with Cygwin's port of openssh, and we suggest you use that one. Here's how to install it:
    1. First, create a new folder on your desktop to hold temporary installation files. It can have any name you like, but in these instructions we'll assume that you call it Foo.
    2. Direct your web browser to www.cygwin.com, and click on the ``Install now!'' link. This will download a file, setup.exe; save it in the directory Foo. The file setup.exe is a small program that will download the actual install files from the Internet when you run it.
    3. Start setup.exe (by double-clicking). This brings up a series of dialogs that you will have to go through. Select ``Install from Internet.'' For ``Local Package Directory'' select the directory Foo. For ``Select install root directory'' we recommend that you use the default, C:\cygwin. The next dialog asks you to select the way that you want to connect to the network to download the installation files; we have used ``Use IE5 Settings'' successfully, but you may need to make a different selection depending on your networking setup. The next dialog gives a list of mirrors; select one close to you. Next you are asked to select which packages to install. The default settings in this dialog download a lot of packages that are not strictly necessary to run Unison with ssh. If you don't want to install a package, click on it until ``skip'' is shown. For a minimum installation, select only the packages ``cygwin'' and ``openssh,'' which come to about 1900KB; the full installation is much larger.

      Note that you are plan to build unison using the free CygWin GNU C compiler, you need to install essential development packages such as ``gcc'', ``make'', ``fileutil'', etc; we refer to the file ``INSTALL.win32-cygwin-gnuc'' in the source distribution for further details.
      After the packages are downloaded and installed, the next dialog allows you to choose whether to ``Create Desktop Icon'' and ``Add to Start Menu.'' You make the call.
    4. You can now delete the directory Foo and its contents.

  2. You must set the environment variables HOME and PATH. Ssh will create a directory .ssh in the directory given by HOME, so that it has a place to keep data like your public and private keys. PATH must be set to include the Cygwin bin directory, so that Unison can find the ssh executable.
  3. Test ssh from a DOS shell by typing
          ssh <remote host> -l <login name>
    You should get a prompt for your password on <remote host>, followed by a working connection.
  4. Note that ssh-keygen may not work (fails with ``gethostname: no such file or directory'') on some systems. This is OK: you can use ssh with your regular password for the remote system.
  5. You should now be able to use Unison with an ssh connection. If you are logged in with a different user name on the local and remote hosts, provide your remote user name when providing the remote root (i.e., //username@host/path...).

Changes in Version 2.9.1

Changes since 2.8.19: Changes since 2.8.1: Changes since 2.7.78: Changes since 2.7.39: Changes since 2.7.7: Changes since 2.7.4: Changes since 2.7.1: Changes since 2.6.59: Changes since 2.6.38: Changes since 2.6.11: Changes since 2.6.1: Changes since 2.5.31: Changes since 2.5.25: Changes since 2.5.1: Changes since 2.4.1: Changes since 2.3.12: Changes since 2.3.1: Changes since 2.2: Changes since 2.1: Changes since 1.292: Changes since 1.231: Changes since 1.219: Changes since 1.200: Changes since 1.190: Changes since 1.180: Changes since 1.169: Changes since 1.146: Changes since 1.142: Changes since 1.139: Changes since 1.111:
If you are compiling Unison 2.7.7 or an earlier version, you need to
The Cygwin port (the Installing Ssh on Windows section) of openssh includes a ssh server program for the Windows platform, but we have not yet tested Unison with this ssh server.

This document was translated from LATEX by HEVEA.