Overview
Preface
•People
•Mailing Lists and Bug Reporting
•Development Status
•Copying
•Acknowledgements
Installation
•Downloading Unison
•Running Unison
•Upgrading
•Building Unison from Scratch
Unix
Mac OS X
Windows
Installation Options
Tutorial
•Preliminaries
•Local Usage
•Remote Usage
•Remote Shell Method
•Socket Method
•Using Unison for All Your Files
•Using Unison to Synchronize More Than Two Machines
•Going Further
Basic Concepts
•Roots
•Paths
•What is an Update?
•What is a Conflict?
•Reconciliation
•Invariants
•Caveats and Shortcomings
Reference Guide
•Running Unison
•The .unison Directory
•Archive Files
•Preferences
•Profiles
•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
•Permissions
•Cross-Platform Synchronization
•Slow Links
•Making Unison Faster on Large Files
•Fast Update Detection
•Mount Points and Removable Media
•Click-starting Unison
Installing Ssh
•Unix
•Windows
Changes in Version 2.51.2
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:
Benjamin Pierce leads the Unison project. The current version of Unison was designed and implemented by Trevor Jim, Benjamin Pierce, and Jérôme Vouillon, with Alan Schmitt, Malo Denielou, Zhe Yang, Sylvain Gommier, and Matthieu Goulay. The Mac user interface was started by Trevor Jim and enormously improved by Ben Willmore. Our implementation of the rsync protocol was built by Norman Ramsey and Sylvain Gommier. It is based on Andrew Tridgell’s thesis work and inspired by his rsync utility. The mirroring and merging functionality was implemented by Sylvain Roy, improved by Malo Denielou, and improved yet further by Stéphane Lescuyer. Jacques Garrigue contributed the original Gtk version of the user interface; the Gtk2 version was built by Stephen Tse. Sundar Balasubramaniam helped build a prototype implementation of an earlier synchronizer in Java. Insik Shin and Insup Lee contributed design ideas to this implementation. Cedric Fournet contributed to an even earlier prototype.
Moderated mailing lists are available for bug reporting, announcements of new versions, discussions among users, and discussions among developers. See
http://www.cis.upenn.edu/~bcpierce/unison/lists.html
for more information.
Unison is no longer under active development as a research project. (Our research efforts are now focused on a follow-on project called Boomerang, described at http://www.cis.upenn.edu/~bcpierce/harmony.) At this point, there is no one whose job it is to maintain Unison, fix bugs, or answer questions.
However, the original developers are all still using Unison daily. It will continue to be maintained and supported for the foreseeable future, and we will occasionally release new versions with bug fixes, small improvements, and contributed patches.
Reports of bugs affecting correctness or safety are of interest to many people and will generally get high priority. Other bug reports will be looked at as time permits. Bugs should be reported to the users list at unison-users@yahoogroups.com.
Feature requests are welcome, but will probably just be added to the ever-growing todo list. They should also be sent to unison-users@yahoogroups.com.
Patches are even more welcome. They should be sent to unison-hackers@lists.seas.upenn.edu. (Since safety and robustness are Unison’s most important properties, patches will be held to high standards of clear design and clean coding.) If you want to contribute to Unison, start by downloading the developer tarball from the download page. For some details on how the code is organized, etc., see the file CONTRIB.
This file is part of Unison.
Unison is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
Unison is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
The GNU Public License can be found at http://www.gnu.org/licenses. A copy is also included in the Unison source distribution in the file COPYING.
Work on Unison has been supported by the National Science Foundation under grants CCR-9701826 and ITR-0113226, Principles and Practice of Synchronization, and by University of Pennsylvania’s Institute for Research in Cognitive Science (IRCS).
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 on the Frequently Asked Questions page helpful. Pre-built binaries are available for a variety of platforms.
Unison can be used with either of two user interfaces:
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.
The Unison download site lives under http://www.cis.upenn.edu/~bcpierce/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 from Scratch section. There are also a small number of contributed ports to other architectures that are not maintained by us. See the Contributed Ports page 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 three different modes: with different directories on a single machine, with a remote machine over a direct socket connection, or with a remote machine 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.
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 is as simple as throwing away the old binary and installing the new one.
Before upgrading, it is a good idea to run the old version one last time, 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 that need to be resolved manually.
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. It has
been tested on many flavors of Windows (98, NT, 2000, XP) and Unix (OS X,
Solaris, Linux, FreeBSD), and on both 32- and 64-bit architectures.
Unison can be built with or without a graphical user interface (GUI). The build system will decide automatically depending on the libraries installed on your system, but you can also type make UISTYLE=text to build Unison without GUI.
You’ll need the Objective Caml compiler, available from http://caml.inria.fr. OCaml is available from most package managers Building and installing OCaml on Unix systems is very straightforward; just follow the instructions in the distribution. You’ll probably want to build the native-code compiler in addition to the bytecode compiler, as Unison runs much faster when compiled to native code, 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 and do make install.)
You’ll also need the GNU make utility, which is standard on most Unix systems. Unison’s build system is not parallelizable, so don’t use flags that cause it to start processes in parallel (e.g. -j).
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 the graphical user interface, you will need to install some additional things:
Type make to build Unison. If Gtk2 is available on the system, Unison with a GUI will be built automatically.
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. Or just
type make install to install Unison to $HOME/bin/unison.
To build the text-only user interface, follow the instructions above for building on Unix systems. You should do this first, even if you are also planning on building the GUI, just to make sure it works.
To build the basic GUI version, you’ll first need to download and install the XCode developer tools from Apple. Once this is done, just type make in the src directory, and if things go well you should get an application that you can move from uimac14/build/Default/Unison.app to wherever you want it.
Although the binary distribution should work on any version of Windows, some people may want to build Unison from scratch on those systems too.
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.07 or later, available from http://caml.inria.fr). Then grab a copy of Unison sources and type
make NATIVE=false
to compile the bytecode. The result should be an executable file called
unison.exe.
Building a more efficient, native version of Unison on Windows requires a little more work. See the file INSTALL.win32 in the source code distribution.
The Makefile in the distribution includes several switches that
can be used to control how Unison is built. Here are the most useful
ones:
NATIVE=true uses the native-code OCaml
compiler, yielding an executable that will run quite a bit faster. We use
this for building distribution versions.
make DEBUGGING=true generates debugging
symbols.
make STATIC=true generates a (mostly)
statically linked executable. We use this for building distribution
versions, for portability.
Unison can be used with either of two user interfaces:
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. If you are running Unison from the command line, just typing unison will select either the text or the graphical interface, depending on which has been selected as default when the executable you are running was built. You can force the text interface even if graphical is the default by adding -ui text. The other command-line arguments to both versions are identical.
The graphical version can also be run directly by clicking on its icon, but this may require 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 a 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.
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
(You may need to add -ui text, depending how your unison binary was built.)
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 follow 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 overridden by the user.
Textual Interface:
<” or “>” to force
the change to be propagated from right to left or from left to right,
or else press “/” to skip this file and leave both replicas alone.
When it reaches the end of the list of modified files, Unison will ask
you one more time whether it should proceed with the updates that have
been selected.When Unison stops to wait for input from the user, pressing “?”
will always give a list of possible responses and their meanings.
Graphical Interface:
<” key (to cause the version in b.tmp to
propagate to a.tmp) or the right-arrow or “>” key (which makes the a.tmp
version override b.tmp).Every keyboard command can also be invoked from the menus at the top of the user interface. (Conversely, each menu item is annotated with its keyboard equivalent, if it has one.)
When you are satisfied with the directions for the propagation of changes as shown in the main window, click the “Go” button to set them in motion. A check sign will be displayed next to each filename when the file has been dealt with.
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:
ssh.
This method is more convenient (since there is no need to manually
start a “unison server” process on the server) and also more
secure (especially if you use ssh).Decide which of these you want to try, and continue with the Remote Shell Method section or the Socket Method section, as appropriate.
The standard remote shell facility on Unix systems is ssh, which provides the
same functionality as the older rsh but much better security. Ssh is available from
http://www.openssh.org. See section A.2
for installation instructions for the Windows version.
Running
ssh requires 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 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
Notes:
a.tmp some place other than your home
directory on the remote host, you can give an absolute path for it by
adding an extra slash between remotehostname and the beginning
of the path:
unison a.tmp ssh://remotehostname//absolute/path/to/a.tmp
unison executable
on the server by using the command-line option -servercmd
/full/path/name/of/unison or adding
servercmd=/full/path/name/of/unison to your profile (see
the Profiles section). Similarly, you can specify a
explicit path for the ssh program using the -sshcmd
option.
Extra arguments can be passed to ssh by setting the
-sshargs preference.
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.) The socket
method is provided only for expert users with specific needs; everyone
else should use the ssh 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.
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.
Since the socket method is not used by many people, its functionality is rather limited. For example, the server can only deal with one client at a time.
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:
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.
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 Profiles section
covers the syntax of Unison profiles, together with some sample profiles.
Some tips on improving Unison’s performance can be found on the Frequently Asked Questions page.
Unison is designed for synchronizing pairs of replicas. However, it is possible to use it to keep larger groups of machines in sync by performing multiple pairwise synchronizations.
If you need to do this, the most reliable way to set things up is to organize the machines into a “star topology,” with one machine designated as the “hub” and the rest as “spokes,” and with each spoke machine synchronizing only with the hub. The big advantage of the star topology is that it eliminates the possibility of confusing “spurious conflicts” arising from the fact that a separate archive is maintained by Unison for every pair of hosts that it synchronizes.
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 and the printed manual are essentially identical.
If you use Unison regularly, you should subscribe to one of the mailing lists, to receive announcements of new versions. See the Mailing Lists and Bug Reporting section.
To understand how Unison works, it is necessary to discuss a few straightforward concepts. These concepts are developed more rigorously and at more length in a number of papers, available at http://www.cis.upenn.edu/~bcpierce/papers. But the informal presentation here should be enough for most users.
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,
relative/path/of/root
specifies a local root relative to the directory where Unison is started, while
/absolute/path/of/root
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:
ssh://remotehost//absolute/path/of/root
rsh://user@remotehost/relative/path/of/root
If the remote server is already running (in the socket mode), then the syntax
socket://remotehost:portnum//absolute/path/of/root
socket://remotehost:portnum/relative/path/of/root
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.)
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:
p refers to an ordinary file, then the
contents of p are the actual contents of this file (a string of bytes)
plus the current permission bits of the file.
p refers to a symbolic link, then the contents of p
are just the string specifying where the link points.
p refers to a directory, then the
contents of p are just the token “DIRECTORY” plus the current
permission bits of the directory.
p does not refer to anything in this replica, then the
contents of p are the token “ABSENT.”
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. Note that whether a path is updated has nothing to do with its last modification time—Unison considers only the contents when determining whether an update has occurred. This means that touching a file without changing its contents will not be recognized as an update. A file can even be changed several times and then changed back to its original contents; as long as Unison is only run at the end of this process, no update will be recognized.
What Unison actually calculates is a close approximation to this definition; see the Caveats and Shortcomings section.
A path is said to be conflicting if the following conditions all hold:
Unison operates in several distinct stages:
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. [Caveat: the above is almost true there are occasionally brief periods where it is not (and, because of shortcoming of the Posix filesystem API, cannot be); in particular, when it is copying a file onto a directory or vice versa, it must first move the original contents out of the way. If Unison gets interrupted during one of these periods, some manual cleanup may be required. In this case, a file called DANGER.README will be left in your home directory, containing information about the operation that was interrupted. The next time you try to run Unison, it will notice this file and warn you about it.]
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 backups flag is set, Unison will
leave around old versions of files that it overwrites, 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 whether or
not Unison does an update. (When running with the fastcheck preference set
to true—the default on Unix systems—Unison 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. Also, the
-times option allows you to synchronize file times, but it does not
cause identical files to be changed; Unison will only modify the file
times.)
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.
Here are some things to be careful of when using Unison.
In particular, the Unix implementation does not compare the actual contents of files to their previous contents, but simply looks at each file’s inode number and modtime; if neither of these have changed, then it concludes that the file has not been changed.
Under normal circumstances, this approximation is safe, in the sense
that it may sometimes detect “false updates” but will never miss a real
one. However, it is possible to fool it, for example by using
retouch to change a file’s modtime back to a time in the past.
You can control this by setting your umask on both computers to
something like 022, masking out the “world write” and “group write”
permission bits.
Unison does not synchronize the setuid and setgid bits, for
security.
For example, suppose Unison is synchronizing directory A between the two machines called the “local” and the “remote” machine; suppose directory A contains a subdirectory D; and suppose D on the local machine contains a file or subdirectory P that matches an ignore directive in the profile used to synchronize. Thus path A/D/P exists on the local machine but not on the remote machine.
If D is renamed to D’ on the remote machine, and this change is propagated to the local machine, all such files or subdirectories P will be deleted. This is because Unison sees the rename as a delete and a separate create: it deletes the old directory (including the ignored files) and creates a new one (not including the ignored files, since they are completely invisible to it).
This section covers the features of Unison in detail.
There are several ways to start Unison.
.unison
directory. If this file does not specify a pair of roots, Unison will
prompt for them and add them to the information specified by the profile.
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. On OS X, $HOME/.unison will be used if it is present, but $HOME/Library/Application Support/Unison will be created and used by default.
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 just the profile files in the .unison directory is definitely OK.
The name of the archive file on each replica is calculated from
saul are converted into full addresses like saul.cis.upenn.edu),
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
Note that root aliases are case-sensitive, even on case-insensitive file systems.
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. Some string arguments take the backslash as an escape to include the next character literally; this is mostly useful to escape a space or the backslash; a trailing backslash is ignored and is useful to protect a trailing whitespace in the string that would otherwise be trimmed. 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. On the command line, preferences and other arguments (the profile name and roots) can be intermixed in any order.
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. To set a
boolean flag to false on the command line, use -p=false.
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]
Basic options:
-auto automatically accept default (nonconflicting) actions
-batch batch mode: ask no questions at all
-doc xxx show documentation ('-doc topics' lists topics)
-fat use appropriate options for FAT filesystems
-group synchronize group attributes
-ignore xxx add a pattern to the ignore list
-ignorenot xxx add a pattern to the ignorenot list
-nocreation xxx prevent file creations on one replica
-nodeletion xxx prevent file deletions on one replica
-noupdate xxx prevent file updates and deletions on one replica
-owner synchronize owner
-path xxx path to synchronize
-perms n part of the permissions which is synchronized
-root xxx root of a replica (should be used exactly twice)
-silent print nothing except error messages
-terse suppress status messages
-testserver exit immediately after the connection to the server
-times synchronize modification times
-version print version and exit
Advanced options:
-addprefsto xxx file to add new prefs to
-addversionno add version number to name of unison on server
-atomic xxx add a pattern to the atomic list
-backup xxx add a pattern to the backup list
-backupcurr xxx add a pattern to the backupcurr list
-backupcurrnot xxx add a pattern to the backupcurrnot list
-backupdir xxx directory for storing centralized backups
-backuploc xxx where backups are stored ('local' or 'central')
-backupnot xxx add a pattern to the backupnot list
-backupprefix xxx prefix for the names of backup files
-backups keep backup copies of all files (see also 'backup')
-backupsuffix xxx a suffix to be added to names of backup files
-clientHostName xxx set host name of client
-confirmbigdel ask about whole-replica (or path) deletes (default true)
-confirmmerge ask for confirmation before committing results of a merge
-contactquietly suppress the 'contacting server' message during startup
-copymax n maximum number of simultaneous copyprog transfers
-copyonconflict keep copies of conflicting files
-copyprog xxx external program for copying large files
-copyprogrest xxx variant of copyprog for resuming partial transfers
-copyquoterem xxx add quotes to remote file name for copyprog (true/false/default)
-copythreshold n use copyprog on files bigger than this (if >=0, in Kb)
-debug xxx debug module xxx ('all' -> everything, 'verbose' -> more)
-diff xxx set command for showing differences between files
-dontchmod when set, never use the chmod system call
-dumbtty do not change terminal settings in text UI
-fastcheck xxx do fast update detection (true/false/default)
-fastercheckUNSAFE skip computing fingerprints for new files (experts only!)
-follow xxx add a pattern to the follow list
-force xxx force changes from this replica to the other
-forcepartial xxx add a pattern to the forcepartial list
-halfduplex force half-duplex communication with the server
-height n height (in lines) of main window in graphical interface
-host xxx bind the socket to this host name in server socket mode
-ignorearchives ignore existing archive files
-ignorecase xxx identify upper/lowercase filenames (true/false/default)
-ignoreinodenumbers ignore inode number changes when detecting updates
-ignorelocks ignore locks left over from previous run (dangerous!)
-immutable xxx add a pattern to the immutable list
-immutablenot xxx add a pattern to the immutablenot list
-key xxx define a keyboard shortcut for this profile (in some UIs)
-killserver kill server when done (even when using sockets)
-label xxx provide a descriptive string label for this profile
-links xxx allow the synchronization of symbolic links (true/false/default)
-log record actions in logfile (default true)
-logfile xxx logfile name
-maxbackups n number of backed up versions of a file
-maxerrors n maximum number of errors before a directory transfer is aborted
-maxsizethreshold n prevent transfer of files bigger than this (if >=0, in Kb)
-maxthreads n maximum number of simultaneous file transfers
-merge xxx add a pattern to the merge list
-mountpoint xxx abort if this path does not exist
-nocreationpartial xxx add a pattern to the nocreationpartial list
-nodeletionpartial xxx add a pattern to the nodeletionpartial list
-noupdatepartial xxx add a pattern to the noupdatepartial list
-numericids don't map uid/gid values by user/group names
-prefer xxx choose this replica's version for conflicting changes
-preferpartial xxx add a pattern to the preferpartial list
-repeat xxx synchronize repeatedly (text interface only)
-retry n re-try failed synchronizations N times (text ui only)
-rootalias xxx register alias for canonical root names
-rsrc xxx synchronize resource forks (true/false/default)
-rsync activate the rsync transfer mode (default true)
-selftest run internal tests and exit
-servercmd xxx name of unison executable on remote server
-showarchive show 'true names' (for rootalias) of roots and archive
-socket xxx act as a server on a socket
-sortbysize list changed files by size, not name
-sortfirst xxx add a pattern to the sortfirst list
-sortlast xxx add a pattern to the sortlast list
-sortnewfirst list new before changed files
-sshargs xxx other arguments (if any) for remote shell command
-sshcmd xxx path to the ssh executable
-stream use a streaming protocol for transferring file contents (default true)
-ui xxx select UI ('text' or 'graphic'); command-line only
-unicode xxx assume Unicode encoding in case insensitive mode
-watch when set, use a file watcher process to detect changes (default true)
-xferbycopying optimize transfers using local copies (default true)
Here, in more detail, is what they do. Many are discussed in greater detail in other sections of the manual.
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.unison as the remote server command (note that the minor version number is dropped – e.g., unison-2.51). 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.backuplocation preference. The backups are named according to the backupprefix and backupsuffix preferences. The number of versions that are kept is determined by the maxbackups preference.The syntax of pathspec is described in the Path Specification section.
merge preference. For more details, see the Merging Conflicting Versions section.The syntax of pathspec is described in the Path Specification section.
backupcurr, like the ignorenot preference.central. It is checked after the UNISONBACKUPDIR environment variable.local, backups will be kept in the same directory as the original files, and if set to central, backupdir will be used instead.NAME is created, it is stored in a directory specified by backuplocation, in a file called backupprefixNAMEbackupsuffix. backupprefix can include a directory name (causing Unison to keep all backup files for a given directory in a subdirectory with this name), and both backupprefix and backupsuffix can contain the string$VERSION, which will be replaced by the age of the backup (1 for the most recent, 2 for the second most recent, and so on...). This keyword is ignored if it appears in a directory name in the prefix; if it does not appear anywhere in the prefix or the suffix, it will be automatically placed at the beginning of the suffix. One thing to be careful of: If the backuploc preference is set to local, Unison will automatically ignore all files whose prefix and suffix match backupprefix and backupsuffix. So be careful to choose values for these preferences that are sufficiently different from the names of your real files.
Name *.-repeat watch and -prefer newer preferences.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 -u CURRENT2 CURRENT1’. If the value of this preference contains the substrings CURRENT1 and CURRENT2, these will be replaced by the names of the files to be diffed. If not, the two filenames will be appended to the command. In both cases, the filenames are suitably quoted.-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.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.
true, Unison will use the modification time and length of a file as a
‘pseudo inode number’ when scanning replicas for updates, instead of reading the full contents of every file. (This does not apply to the very first run, when Unison will always scan all files regarless of this switch). Under Windows, this may cause Unison to miss propagating an update if the modification time and length of the file are both unchanged by the update. 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. For backward compatibility, yes, no, and default can be used in place of true, false, and auto. See the Fast Update Detection section for more information.When this flag is set to true, Unison will compute a ’pseudo-fingerprint’ the first time it sees a file (either because the file is new or because Unison is running for the first time). This enormously speeds update detection, but it must be used with care, as it can cause Unison to miss conflicts: If a given path in the filesystem contains files on both sides that Unison has not yet seen, and if those files have the same length but different contents, then Unison will not notice the presence of a conflict. If, later, one of the files is changed, the changed file will be propagated, overwriting the other.
Moreover, even when the files are initially identical, setting this flag can lead to potentially confusing behavior: if a newly created file is later touched without being modified, Unison will treat this conservatively as a potential change (since it has no record of the earlier contents) and show it as needing to be propagated to the other replica.
Most users should leave this flag off – the small time savings of not fingerprinting new files is not worth the cost in terms of safety. However, it can be very useful for power users with huge replicas that are known to be already synchronized (e.g., because one replica is a newly created duplicate of the other, or because they have previously been synchronized with Unison but Unison’s archives need to be rebuilt). In such situations, it is recommended that this flag be set only for the initial run of Unison, so that new archives can be created quickly, and then turned off for normal use.
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 is overridden by the forcepartial preference.
This preference should be used only if you are sure you know what you are doing!
You can also specify forcepartial PATHSPEC -> newer (or forcepartial PATHSPEC 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!
true, the group attributes of the files are synchronized. Whether the group names or the group identifiers are synchronized depends on the preference numerids.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 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 ignore and does not match 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 ignorenot to select particular paths to be synchronized will not work. Instead, you should use the path preference to choose particular paths to synchronize.
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.)unison.log in your HOME directory. Set this preference if
you prefer another file.backup. The default is 2.This preference can be included twice, once for each root, if you want to prevent any creation.
This preference can be included twice, once for each root, if you want to prevent any deletion.
This preference can be included twice, once for each root, if you want to prevent any update.
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.
true, the owner attributes of the files are synchronized. Whether the owner names or the owner identifiers are synchronizeddepends on the preference numerids.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 sync of just one directory, for example.) Note that path preferences are intepreted literally—they are not regular expressions.root preference, plus the special values newer and older.) This preference is overridden by the preferpartial preference.
This preference should be used only if you are sure you know what you are doing!
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!
watch, Unison relies on an external file monitoring process to synchronize whenever a change happens.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.
rsh command used to invoke the remote server. The backslash is an escape character.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, except that files matching one of these patterns will be listed at the very end.ssh command used to invoke the remote server. The backslash is an escape character.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.true, file modification times (but not directory modtimes) are propagated.graphic or text. Because this option is processed specially during Unison’s start-up sequence, it can only be used on the command line. In preference files it has no effect.
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.)
-repeat watch preference. Setting this flag to false disable the use of this process.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 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. In name the backslash is an escape
character.
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.
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
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 every file in a central location
backuplocation = central
backupdir = /home/bcpierce/backups
backup = Name *
backupprefix = $VERSION.
backupsuffix =
# Use this command for displaying diffs
diff = diff -y -W 79 --suppress-common-lines
# Log actions to the terminal
log = true
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:
# Roots of the synchronization
root = /home/bcpierce
root = ssh://saul//home/bcpierce
# (... 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' rather than in the top-level preference file
addprefsto = common
# 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 workingset’, where the preference file workingset.prf contains
path = current/papers
path = Mail/inbox
path = Mail/drafts
include common
causes Unison to synchronize just the listed subdirectories.
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.
When Unison overwrites (or deletes) a file or directory while propagating changes from the other replica, it can keep the old version around as a backup. There are several preferences that control precisely where these backups are stored and how they are named.
To enable backups, you must give one or more backup preferences.
Each of these has the form
backup = <pathspec>
where <pathspec> has the same form as for the ignore
preference. For example,
backup = Name *
causes Unison to keep backups of all files and directories. The
backupnot preference can be used to give a few exceptions: it
specifies which files and directories should not be backed up, even if
they match the backup pathspec.
It is important to note that the pathspec is matched against the path
that is being updated by Unison, not its descendants. For example, if you
set backup = Name *.txt and then delete a whole directory named
foo containing some text files, these files will not be backed up
because Unison will just check that foo does not match *.txt.
Similarly, if the directory itself happened to be called foo.txt,
then the whole directory and all the files in it will be backed up,
regardless of their names.
Backup files can be stored either centrally or locally. This
behavior is controlled by the preference backuplocation, whose value
must be either central or local. (The default is
central.)
When backups are stored locally, they are kept in the same directory as the original.
When backups are stored centrally, the directory used to hold them is
controlled by the preference backupdir and the
environment variable UNISONBACKUPDIR. (The environment variable is
checked first.) If neither of these are set, then the directory
.unison/backup in the user’s home directory is used.
The preference maxbackups controls how many previous versions of
each file are kept (including the current version).
By default, backup files are named .bak.VERSION.FILENAME,
where FILENAME is the original filename and VERSION is the
backup number (1 for the most recent, 2 for the next most recent,
etc.). This can be changed by setting the preferences backupprefix
and/or backupsuffix. If desired, backupprefix may include a
directory prefix; this can be used with backuplocation = local to put all
backup files for each directory into a single subdirectory. For example, setting
backuplocation = local
backupprefix = .unison/$VERSION.
backupsuffix =
will put all backups in a local subdirectory named .unison. Also,
note that the string $VERSION in either backupprefix or
backupsuffix (it must appear in one or the other) is replaced by
the version number. This can be used, for example, to ensure that backup
files retain the same extension as the originals.
For backward compatibility, the backups preference is also supported.
It simply means backup = Name * and backuplocation = local.
Unison can invoke external programs to merge conflicting versions of a file.
The preference merge controls this process.
The merge preference may be given once or several times in a
preference file (it can also be given on the command line, of course, but
this tends to be awkward because of the spaces and special characters
involved). Each instance of the preference looks like this:
merge = <PATHSPEC> -> <MERGECMD>
The <PATHSPEC> here has exactly the same format as for the
ignore preference (see the Path Specification section). For example,
using “Name *.txt” as the <PATHSPEC> tells Unison that this
command should be used whenever a file with extension .txt needs to
be merged.
Many external merging programs require as inputs not just the two files that
need to be merged, but also a file containing the last synchronized
version. You can ask Unison to keep a copy of the last synchronized
version for some files using the backupcurrent preference. This
preference is used in exactly the same way as backup and its meaning
is similar, except that it causes backups to be kept of the current
contents of each file after it has been synchronized by Unison, rather than
the previous contents that Unison overwrote. These backups are kept
on both replicas in the same place as ordinary backup files—i.e.
according to the backuplocation and backupdir preferences.
They are named like the original files if backupslocation is set to
’central’ and otherwise, Unison uses the backupprefix and
backupsuffix preferences and assumes a version number 000 for these
backups.
The <MERGECMD> part of the preference specifies what external command
should be invoked to merge files at paths matching the <PATHSPEC>.
Within this string, several special substrings are recognized; these will be
substituted with appropriate values before invoking a sub-shell to execute
the command.
CURRENT1 is replaced by the name of (a temporary copy of)
the local variant of the file.
CURRENT2 is replaced by the name of a temporary
file, into which the contents of the remote variant of the file have
been transferred by Unison prior to performing the merge.
CURRENTARCH is replaced by the name of the backed up copy
of the original version of the file (i.e., the file saved by Unison
if the current filename matches the path specifications for the
backupcurrent preference, as explained above), if one exists.
If no archive exists and CURRENTARCH appears in the
merge command, then an error is signalled.
CURRENTARCHOPT is replaced by the name of the backed up copy
of the original version of the file (i.e., its state at the end of
the last successful run of Unison), if one exists, or the empty
string if no archive exists.
NEW is replaced by the name of a temporary file
that Unison expects to be written by the merge program when it
finishes, giving the desired new contents of the file.
PATH is replaced by the path (relative to the roots of
the replicas) of the file being merged.
NEW1 and NEW2 are replaced by the names of temporary files
that Unison expects to be written by the merge program when it
is only able to partially merge the originals; in this case, NEW1
will be written back to the local replica and NEW2 to the remote
replica; NEWARCH, if present, will be used as the “last common
state” of the replicas. (These three options are provided for
later compatibility with the Harmony data synchronizer.)
To accommodate the wide variety of programs that users might want to use for merging, Unison checks for several possible situations when the merge program exits:
NEW has been created, it is written back to both
replicas (and stored in the backup directory). Similarly, if just the
file NEW1 has been created, it is written back to both
replicas.
NEW nor NEW1 have been created, then Unison
examines the temporary files CURRENT1 and CURRENT2 that
were given as inputs to the merge program. If either has been changed (or
both have been changed in identical ways), then its new contents are written
back to both replicas. If either CURRENT1 or CURRENT2 has
been deleted, then the contents of the other are written back to
both replicas.
NEW1, NEW2, and NEWARCH have all
been created, they are written back to the local replica, remote replica,
and backup directory, respectively. If the files NEW1, NEW2 have
been created, but NEWARCH has not, then these files are written back to the
local replica and remote replica, respectively. Also, if NEW1 and
NEW2 have identical contents, then the same contents are stored as
a backup (if the backupcurrent preference is set for this path) to
reflect the fact that the path is currently in sync.
NEW1 and NEW2 (resp. CURRENT1 and
CURRENT2) are created (resp. overwritten) with different contents
but the merge command did not fail (i.e., it exited with status code 0),
then we copy NEW1 (resp. CURRENT1) to the other replica and
to the archive.This behavior is a design choice made to handle the case where a merge command only synchronizes some specific contents between two files, skipping some irrelevant information (order between entries, for instance). We assume that, if the merge command exits normally, then the two resulting files are “as good as equal.” (The reason we copy one on top of the other is to avoid Unison detecting that the files are unequal the next time it is run and trying again to merge them when, in fact, the merge program has already made them as similar as it is able to.)
If the confirmmerge preference is set and Unison is not run in
batch mode, then Unison will always ask for confirmation before
actually committing the results of the merge to the replicas.
A large number of external merging programs are available.
For example, on Unix systems setting the merge preference to
merge = Name *.txt -> diff3 -m CURRENT1 CURRENTARCH CURRENT2
> NEW || echo "differences detected"
will tell Unison to use the external diff3 program for merging.
Alternatively, users of emacs may find the following settings convenient:
merge = Name *.txt -> emacs -q --eval '(ediff-merge-files-with-ancestor
"CURRENT1" "CURRENT2" "CURRENTARCH" 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.)
Users running emacs under windows may find something like this useful:
merge = Name * -> C:\Progra~1\Emacs\emacs\bin\emacs.exe -q --eval
"(ediff-files """CURRENT1""" """CURRENT2""")"
Users running Mac OS X (you may need the Developer Tools installed to get the opendiff utility) may prefer
merge = Name *.txt -> opendiff CURRENT1 CURRENT2 -ancestor CURRENTARCH -merge NEW
Here is a slightly more involved hack. The opendiff program can operate either with or without an archive file. A merge command of this form
merge = Name *.txt ->
if [ CURRENTARCHOPTx = x ];
then opendiff CURRENT1 CURRENT2 -merge NEW;
else opendiff CURRENT1 CURRENT2 -ancestor CURRENTARCHOPT -merge NEW;
fi
(still all on one line in the preference file!) will test whether an archive file exists and use the appropriate variant of the arguments to opendiff.
Linux users may enjoy this variant:
merge = Name * -> kdiff3 -o NEW CURRENTARCHOPT CURRENT1 CURRENT2
Ordinarily, external merge programs are only invoked when Unison is not running in batch mode. To specify an external merge program that should be used no matter the setting of the batch flag, use the mergebatch preference instead of merge.
Please post suggestions for other useful values of the
merge preference to the unison-users mailing list—we’d like
to give several examples here.
Both the textual and the graphical user interfaces are intended to be mostly self-explanatory. Here are just a few tricks:
>” to tell Unison to
propagate a file from left to right, rather than “> Enter.”)There are some situations, though, where this will not work — for
example, when Unison is running in a shell window inside Emacs.
Setting the dumbtty preference will force Unison to leave the
terminal alone and process input a line at a time.
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.
Several Unison preferences (e.g., ignore/ignorenot,
follow, sortfirst/sortlast, backup,
merge, etc.)
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.
ignore = pattern
adds pattern to the list of patterns to be ignored.Regex. (The collating sequences and character classes of
full Posix regexps are not currently supported).
Regex regexp
For convenience, three other styles of pattern are also recognized:
Name name
matches any path in which the last component matches name,
Path path
matches exactly the path path, and
BelowPath path
matches the path path and any path below.
The name and path arguments of the latter forms of
patterns are not regular expressions. Instead,
standard “globbing” conventions can be used in name and
path:
* matches any sequence of characters not including /
(and not beginning with ., when used at the beginning of a
name)
? matches any single character except / (and leading
.)
[xyz] matches any character from the set {x,
y, z }
{a,bb,ccc} matches any one of a, bb, or
ccc. (Be careful not to put extra spaces after the commas:
these will be interpreted literally as part of the strings to be matched!)
Some examples of path patterns appear in the Ignoring Paths section.
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 Specification 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
Path patterns do not skip filenames beginning with . (as Name
patterns do). For example,
ignore = Path */tmp
will include .foo/tmp in the set of ignore directories, as it is a
path, not a name, that is ignored.
The following 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.
include directive to include a common
collection of preferences in several top-level preference files, you will
probably also want to set the addprefsto preference to the name of
this file. This will cause any new ignore patterns that you add from
inside Unison to be appended to this file, instead of whichever top-level
preference file you started Unison with.-ignore 'Name temp.txt'.ignorenot preference, which specifies a set of
patterns for paths that should not be ignored, even if they match an
ignore pattern. However, the interaction of these two sets of
patterns can be a little tricky. Here is exactly how it works:
ignore pattern and does not match an ignorenot pattern, then
the whole replica will be ignored. (For this reason, it is not a good
idea to include Name * as an ignore pattern. If you want to
ignore everything except a certain set of files, use Name ?*.)
ignore pattern and does not match an ignorenot pattern, then
this whole path including everything below it will be ignored.
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 Specification 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 filesystems are involved (e.g., when synchronizing a Windows client and a Unix server). In detail, here’s how it works:
setuid and setgid
bits are not propagated.
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 Ignoring Paths 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.
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 “-sshargs -C” to the command line or “sshargs = -C” to your profile.
Unison’s built-in implementation of the rsync algorithm makes transferring updates to existing files pretty fast. However, for whole-file copies of newly created files, the built-in transfer method is not highly optimized. Also, if Unison is interrupted in the middle of transferring a large file, it will attempt to retransfer the whole thing on the next run.
These shortcomings can be addressed with a little extra work by telling Unison to use an external file copying utility for whole-file transfers. The recommended one is the standalone rsync tool, which is available by default on most Unix systems and can easily be installed on Windows systems using Cygwin.
If you have rsync installed on both hosts, you can make Unison use it simply by setting the copythreshold flag to something non-negative. If you set it to 0, Unison will use the external copy utility for all whole-file transfers. (This is probably slower than letting Unison copy small files by itself, but can be useful for testing.) If you set it to a larger value, Unison will use the external utility for all files larger than this size (which is given in kilobytes, so setting it to 1000 will cause the external tool to be used for all transfers larger than a megabyte).
If you want to use a different external copy utility, set both the copyprog and copyprogrest preferences—the former is used for the first transfer of a file, while the latter is used when Unison sees a partially transferred temp file on the receiving host. Be careful here: Your external tool needs to be instructed to copy files in place (otherwise if the transfer is interrupted Unison will not notice that some of the data has already been transferred, the next time it tries). The default values are:
copyprog = rsync --inplace --compress copyprogrest = rsync --partial --inplace --compress
You may also need to set the copyquoterem preference. When it is set to true, this causes Unison to add an extra layer of quotes to the remote path passed to the external copy program. This is is needed by rsync, for example, which internally uses an ssh connection, requiring an extra level of quoting for paths containing spaces. When this flag is set to default, extra quotes are added if the value of copyprog contains the string rsync. The default value is default, naturally.
If a directory transfer is interrupted, the next run of Unison will automatically skip any files that were completely transferred before the interruption. (This behavior is always on: it does not depend on the setting of the copythreshold preference.) Note, though, that the new directory will not appear in the destination filesystem until everything has been transferred—partially transferred directories are kept in a temporary location (with names like .unison.DIRNAME....) until the transfer is complete.
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
true, 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
modification time and length of the file are both unchanged
by the update.
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.
Fastcheck is (always) automatically disabled for files with extension
.xls or .mpp, to prevent Unison from being confused by the
habits of certain programs (Excel, in particular) of updating files without
changing their modification times.
Using Unison removable media such as USB drives can be dangerous unless you are careful. If you synchronize a directory that is stored on removable media when the media is not present, it will look to Unison as though the whole directory has been deleted, and it will proceed to delete the directory from the other replica—probably not what you want!
To prevent accidents, Unison provides a preference called
mountpoint. Including a line like
mountpoint = foo
in your preference file will cause Unison to check, after it finishes
detecting updates, that something actually exists at the path
foo on both replicas; if it does not, the Unison run will
abort.
On Windows NT/2k/XP 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 Profiles section). Use your favorite editor for this.
Warning: These instructions may be out of date. More current information can be found the Unison Wiki.
Your local host will need just an ssh client; the remote host needs an ssh server (or daemon), which is available on Unix systems. 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.
Most modern Unix installations come with ssh pre-installed.
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.
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 try that one first. Here’s how to install it:
Foo.
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.
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.
Foo and its contents.
Some people have reported problems using Cygwin’s ssh with Unison. If you have trouble, you might try other ones instead:
http://linuxmafia.com/ssh/win32.html
.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.
set PATH=%PATH%;<SSHDIR>
set HOME=<HOMEDIR>
to the file C:\AUTOEXEC.BAT, where <HOMEDIR> is the
directory where you want ssh to create its .ssh directory,
and <SSHDIR> is the directory where the executable
ssh.exe is stored; if you’ve installed Cygwin in the
default location, this is C:\cygwin\bin. You will have to
reboot your computer to take the changes into account.
;<SSHDIR>
to it, where <SSHDIR> is the full name of the directory
that includes the ssh executable; if you’ve installed Cygwin in
the default location, this is C:\cygwin\bin.
ssh <remote host> -l <login name>You should get a prompt for your password on
<remote host>,
followed by a working connection.
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.
//username@host/path...).
Changes since 2.48:
Changes since 2.45:
Changes since 2.40.63:
This feature should still be considered experimental, but it’s ready for other people to try out.
Changes since 2.40.1:
Changes since 2.32:
Also, allow partial transfer of a directory when there was an error deep inside this directory during update detection. At the moment, this is only activated with the text and GTK UIs, which have been modified so that they show that the transfer is going to be partial and so that they can display all errors.
Changes since 2.31:
Changes since 2.27:
On the Unison side, the new behavior is very simple:
To use this to drive Unison "incrementally," just start it in this mode and start up a tool (on each host) to watch for new changes to the filesystem and append the appropriate paths to the watchfile. Hopefully such tools should not be too hard to write.
Changes since 2.17:
mountpoint preference, which can be used to specify
a path that must exist in both replicas at the end of update detection
(otherwise Unison aborts). This can be used to avoid potentially dangerous
situations when Unison is used with removable media such as external hard
drives and compact flash cards.
confirmbigdeletes. Default is true, which gives the same behavior as
previously. (This functionality is at least partly superceded by the
mountpoint preference, but it has been left in place in case it is
useful to some people.)
forcepartial and preferpartial preferences, which
behave like force and prefer but can be specified on a
per-path basis. [Thanks to Alan Schmitt for this.]
mergebatch preference. (It never seemed very useful, and
its semantics were confusing.)
.# to .unison.
-terse flag) to make it easier to interpret the
results when Unison is run several times in succession from a script.
.mpp files to the “never fastcheck” list (like
.xls files).
Changes since 2.13.0:
backupXXX
preferences) for details.
Changes since 2.12.0:
X.Y.Z, but,
from now on, just the major version number (X.Y) will be considered
significant when checking compatibility between client and server versions.
The third component of the version number will be used only to identify
“patch levels” of releases.This change goes hand in hand with a change to the procedure for making new releases. Candidate releases will initially be given “beta release” status when they are announced for public consumption. Any bugs that are discovered will be fixed in a separate branch of the source repository (without changing the major version number) and new tarballs re-released as needed. When this process converges, the patched beta version will be dubbed stable.
modified at hh:mm:ss on dd MMM, yyyy
to modified on yyyy-mm-dd hh:mm:ss
$UNISON for home directory as a last resort
(it was wrongly moved before $HOME and $USERPROFILE in
Unison 2.12.0)
Changes since 2.10.2:
svn co https://cvs.cis.upenn.edu:3690/svnroot/unison/We will also continue to export a “developer tarball” of the current (modulo one day) sources in the web export directory. To receive commit logs for changes to the sources, subscribe to the
unison-hackers list
(http://www.cis.upenn.edu/ bcpierce/unison/lists.html).
O_EXCL
HOME and
USERPROFILE in that order. On Unix and Cygwin systems, HOME is used.
diff preference so that it can be given either as just
the command name to be used for calculating diffs or else a whole command
line, containing the strings CURRENT1 and CURRENT2, which will be replaced
by the names of the files to be diff’ed before the command is called.
Changes since 2.9.20:
Warning: the new merging functionality is not completely compatible with old versions! Check the manual for details.
~/.unison exists, use it
~/Library/Application Support/Unison,
creating it if necessary.
Changes since 2.9.1:
Changes since 2.8.1:
Changes since 2.7.78:
Changes since 2.7.39:
-prefer/-force newer’ works properly now.
(The bug was reported by Sebastian Urbaniak and Sean Fulton.)
[END] messages in log now use a briefer format
Changes since 2.7.7:
Some adjustments to unison are made to accommodate the multi-threaded version. These include, in particular, changes to the user interface and logging, for example:
.#<filename>.<serial>.unison.tmp.
[N.b. This was later changed to .unison.<filename>.<serial>.unison.tmp.]
force=older preference not working).
Changes since 2.7.4:
Changes since 2.7.1:
addprefsto preference, which (when set) controls which
preference file new preferences (e.g. new ignore patterns) are added to.
Changes since 2.6.59:
fastcheck from a boolean to a string preference. Its
legal values are yes (for a fast check), no (for a safe
check), or default (for a fast check—which also happens to be
safe—when running on Unix and a safe check when on Windows). The default
is default.
Changes since 2.6.38:
We’ve added a preference fastcheck that makes Unison look only at
a file’s creation time and last-modified time to check whether it has
changed. This should result in a huge speedup when checking for updates
in large replicas.
When this switch is set, Unison will use file creation times as ’pseudo inode numbers’ when scanning Windows replicas for updates, instead of reading the full contents of every file. 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 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.
Warning: This change is has not yet been thoroughly field-tested. If you
set the fastcheck preference, pay careful attention to what
Unison is doing.
UNISONBACKUPDIR.)
backup controls which files are actually
backed up:
giving the preference ’backup = Path *’ causes backing up
of all files.
backupversions controls how many previous
versions of each file are kept. The default is 2 (i.e., the last
synchronized version plus one backup).
backups preference is also
still supported, but backup is now preferred.
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 as follows before invoking
the command:
CURRENT1 is replaced by the name of the local
copy of the file;
CURRENT2 is replaced by the name of a temporary
file, into which the contents of the remote copy of the file have
been transferred by Unison prior to performing the merge;
NEW is replaced by the name of a temporary
file that Unison expects to be written by the merge program when
it finishes, giving the desired new contents of the file; and
OLD is replaced by the name of the backed up
copy of the original version of the file (i.e., its state at the
end of the last successful run of Unison), if one exists
(applies only to merge, not merge2).
merge preference to
merge = diff3 -m CURRENT1 OLD CURRENT2 > NEWwill 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 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 should be written on a single line.)
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.merge2 and merge preferences – we’d like to give several
examples in the manual.
.prf’ to the included file by default. If a file with
precisely the given name exists in the .unison directory, it will be used;
otherwise Unison will
add .prf, as it did before. (This change means that included
preference files can be named blah.include instead of
blah.prf, so that unison will not offer them in its ’choose
a preference file’ dialog.)
force and prefer preferences, which were
getting the propagation direction exactly backwards.
~/.unison/default.prf) does not exist.
src/DEPENDENCIES.ps, to help new prospective developers with
navigating the code.
Changes since 2.6.11:
defaultpath preference has been removed. Its effect can be
approximated by using multiple profiles, with include directives
to incorporate common settings. All uses of defaultpath in
existing profiles should be changed to path.Another change in startup behavior that will affect some users is that it is no longer possible to specify roots both in the profile and on the command line.
You can achieve a similar effect, though, by breaking your profile into two:
default.prf =
root = blah
root = foo
include common
common.prf =
<everything else>
Now do
unison common root1 root2
when you want to specify roots explicitly.
-prefer and -force options have been extended to
allow users to specify that files with more recent modtimes should be
propagated, writing either -prefer newer or -force newer.
(For symmetry, Unison will also accept -prefer older or
-force older.) The -force older/newer options can only be
used when -times is also set.The graphical user interface provides access to these facilities on a
one-off basis via the Actions menu.
key = n’, where n is a single digit, then pressing this
key will cause Unison to immediately switch to this profile and begin
synchronization again from scratch. (Any actions that may have been
selected for a set of changes currently being displayed will be
discarded.)label = <string>’ giving a
descriptive string that described the options selected in this profile.
The string is listed along with the profile name in the profile selection
dialog, and displayed in the top-right corner of the main Unison window.
DISPLAY variable and, if it is not set, automatically fall back
to the textual user interface.
path preferences) are now matched
against the ignore preferences. So if a path is both specified in a
path preference and ignored, it will be skipped.
Changes since 2.6.1:
include <name>, which will cause name.prf to be read
at that point.CYGWIN=binmode in now added to the environment
so that the Cygwin port of OpenSSH works properly in a non-Cygwin
context.servercmd and addversionno preferences can now
be used together: -addversionno appends an appropriate
-NNN to the server command, which is found by using the value
of the -servercmd preference if there is one, or else just
unison.'-pref=val' and '-pref val' are now allowed for
boolean values. (The former can be used to set a preference to false.)Changes since 2.5.31:
log preference is now set to true by default,
since the log file seems useful for most users.
Changes since 2.5.25:
Changes since 2.5.1:
These new features are controlled by a set of new preferences, all of
which are currently false by default.
times preference is set to true, file
modification times are propaged. (Because the representations of time
may not have the same granularity on both replicas, Unison may not always
be able to make the modtimes precisely equal, but it will get them as
close as the operating systems involved allow.)
owner preference is set to true, file
ownership information is synchronized.
group preference is set to true, group
information is synchronized.
numericIds preference is set to true, owner
and group information is synchronized numerically. By default, owner and
group numbers are converted to names on each replica and these names are
synchronized. (The special user id 0 and the special group 0 are never
mapped via user/group names even if this preference is not set.)
perms that can be used to
control the propagation of permission bits. The 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.log preference (default false), which makes
Unison keep a complete record of the changes it makes to the replicas.
By default, this record is written to a file called unison.log in
the user’s home directory (the value of the HOME environment
variable). If you want it someplace else, set the logfile
preference to the full pathname you want Unison to use.ignorenot preference that maintains a set of patterns
for paths that should definitely not be ignored, whether or not
they match an ignore pattern. (That is, a path will now be ignored
iff it matches an ignore pattern and does not match any ignorenot patterns.)
batch preference is set, the graphical user interface no
longer waits for user confirmation when it displays a warning message: it
simply pops up an advisory window with a Dismiss button at the bottom and
keeps on going.
statusdepth controls the maximum
depth for paths on the local machine (longer paths are not displayed, nor
are non-directory paths). The value should be an integer; default is 1.
trace and silent preferences. They did
not seem very useful, and there were too many preferences for controlling
output in various ways.
<return>) instead of all
available commands. Typing ? will print the full list of
possibilities.
gethostname operating system call. However, if the environment
variable UNISONLOCALHOSTNAME is set, its value will now 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).
lablgtk, which
means we can throw away our local patched version.If you’re compiling the GTK version of unison from sources, you’ll need to update your copy of lablgtk to the developers release. (Warning: installing lablgtk under Windows is currently a bit challenging.)
debug preference now prints quite a bit of additional
information that should be useful for identifying sources of problems.
ignore) is now case-insensitive
when Unison is in case-insensitive mode (i.e., when one of the replicas
is on a windows machine).
Changes since 2.4.1:
sortnewfirst preference to true causes
newly created files to be displayed before changed files.
sortbysize causes files to be displayed in
increasing order of size.
sortfirst=<pattern> (where
<pattern> is a path descriptor in the same format as ’ignore’ and ’follow’
patterns, causes paths matching this pattern to be displayed first.
sortlast=<pattern>
causes paths matching this pattern to be displayed last.
sortnewfirst and sortbysize flags can also be accessed
from the ’Sort’ menu in the grpahical user interface.prefer with argument <root>
(by adding -prefer <root> to the command line or prefer=<root>)
to your profile) means that, if there is a conflict, the contents of
<root>
should be propagated to the other replica (with no questions asked).
Non-conflicting changes are treated as usual.
force with argument <root>
will make unison resolve all differences in favor of the given
root, even if it was the other replica that was changed.
rsync preference has been removed (it was used to
activate rsync compression for file transfers, but rsync compression is
now enabled by default).
====> instead of ---->). This
matches the behavior of the graphical interface, which displays such
arrows in a different color.
Changes since 2.3.12:
Changes since 2.3.1:
Changes since 2.2:
The final component of a -path argument may now be the wildcard
specifier *. When Unison sees such a path, it expands this path on
the client into into the corresponding list of paths by listing the
contents of that directory.
Note that if you use wildcard paths from the command line, you will probably need to use quotes or a backslash to prevent the * from being interpreted by your shell.
If both roots are local, the contents of the first one will be used for expanding wildcard paths. (Nb: this is the first one after the canonization step – i.e., the one that is listed first in the user interface – not the one listed first on the command line or in the preferences file.)
Changes since 2.1:
rsync protocol. This protocol achieves much faster
transfers when only a small part of a large file has been changed by
sending just diffs. This feature is mainly helpful for transfers over
slow links—on fast local area networks it can actually degrade
performance—so we have left it off by default. Start unison with
the -rsync option (or put rsync=true in your preferences
file) to turn it on.If you want to play with the multi-threaded version, you’ll need to
recompile Unison from sources (as described in the documentation),
setting the THREADS flag in Makefile.OCaml to true. Make sure that
your OCaml compiler has been installed with the -with-pthreads
configuration option. (You can verify this by checking whether the
file threads/threads.cma in the OCaml standard library
directory contains the string -lpthread near the end.)
Changes since 1.292:
Changes since 1.231:
rsync protocol, built by Sylvain Gommier and Norman Ramsey.
This protocol achieves much faster transfers when only a small part of
a large file has been changed by sending just diffs. The rsync
feature is off by default in the current version. Use the
-rsync switch to turn it on. (Nb. We still have a lot of
tuning to do: you may not notice much speedup yet.)make THREADS=true.)
Native thread support from the compiler is required. Use the option
-threads N to select the maximal number of concurrent
threads (default is 5). Multi-threaded
and single-threaded clients/servers can interoperate.uitk and myfileselect have been changed to
use labltk instead of camltk. To compile the Tk interface in Windows,
you must have ocaml-3.00 and tk8.3. When installing tk8.3, put it in
c:\Tcl rather than the suggested c:\Program Files\Tcl,
and be sure to install the headers and libraries (which are not
installed by default).-addversionno switch, which causes unison to
use unison-<currentversionnumber> instead of just unison
as the remote server command. This allows multiple 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.
Changes since 1.219:
Changes since 1.200:
Changes since 1.190:
Changes since 1.180:
Changes since 1.169:
.tmp are no longer ignored automatically. If you want
to ignore such files, put an appropriate ignore pattern in your profile.ignore = <regexp>in your profile (.unison/default.prf), you should put:
ignore = Regex <regexp>Moreover, two other styles of pattern are also recognized:
ignore = Name <name>matches any path in which one component matches
<name>, while
ignore = Path <path>matches exactly the path
<path>.Standard “globbing” conventions can be used in <name> and
<path>:
? matches any single character except /
* matches any sequence of characters not including /
[xyz] matches any character from the set {x,
y, z }
{a,bb,ccc} matches any one of a, bb, or
ccc.
See the user manual for some examples.
Changes since 1.146:
Changes since 1.142:
Changes since 1.139:
-debug command line flag, which controls debugging
of various modules. Say -debug XXX to enable debug tracing for
module XXX, or -debug all to turn on absolutely everything.
Changes since 1.111:
REGEXP in ignore should
become a line of the form ignore = REGEXP in default.prf.
unison profilename(i.e. with just one “anonymous” command-line argument), then the file
~/.unison/profilename.prf will be loaded instead of
default.prf.This document was translated from LATEX by HEVEA.