First Sync

For an initial sync, I will be assuming the following initial scenario. The file tree to be synchronized is completely filled on the server; on the client, it is completely empty, except for the Unison profiles in ~/.unison/ and the SSH certificate in ~/.ssh/. In this ideal state, the server thus exclusively acts as the source, and the client exclusively acts as the sync target.

If another state exists, you need to prepare for a longer session, because then many conflicts can occur on the first attempt. All of them need to be handled with the greatest care – otherwise you could easily shoot yourself in the foot. Under no circumstances must the client contain the remains of any Unison sync archives in the directory ~/.unison/.

You trigger this initial sync in the same way as for mobile devices in the following section. You will then see the warning shown in Figure 2 in response. In it, Unison announces that this is obviously an initial sync, which could take a little longer.

Figure 2: During the first sync, a warning appears. You can only press Ok here in an ideal case (i.e., if the client has no files).

Mobile Operation

The mode for mobile operation is mainly – but, as explained later, not exclusively – intended for devices like the mobile.myprovider.tld laptop in Figure 1. For this simple operating mode, a quite straightforward profile (Listing 4) is all you need; you can save this as mobile.prf. It ensures that the unison-fsmonitor filesystem monitor does not launch under any circumstances (line 7) and that only the basic sync takes place in line with the specifications from Listing 3 (line 11 in Listing 4).

To start the synchronization, it makes sense to launch the graphical application. At the command line, type unison-gtk mobile. Since running the program from the prompt is not entirely intuitive, you will want to create an appropriate shortcut on the desktop, in the taskbar, or in the application menu.

After starting Unison, wait until the application shows you the differences between the two replicas (Figure 3). In the simplest case, if the sync suggested by the green arrows is what you expected, then press Go and wait for the end of the synchronization run. Even in the case of conflicts marked with red question marks, you can start the sync with a clear conscience: Unison then only processes the updates with the green arrows and leaves the conflicts untouched.

Figure 3: A typical representation of the state between two replicas in the Unison GUI.

Authentication

Whenever it is called, Unison prompts you for the passphrase of the certificate for the SSH connection (Figure 4). As long as you do not close the unison-gtk user interface after you have entered your data, you can perform as many syncs as you like without having to re-enter it. This is a pretty ugly hack, though.

Figure 4: Without further preparation, Unison directly prompts you for the passphrase for the SSH connection.

It makes far more sense to integrate the unison-mobile.sh shell script in Listing 5 into the desktop environment so that it is called automatically at login time. Then the passphrase request is only made once in order to release the SSH certificate for the server for the duration of the session. It is then available for any number of syncs – and for regular SSH sessions.

If you not only enter the passphrase, but also check the Save Password box as shown in Figure 5, the desktop stores the passphrase in its wallet, and you will not need to query it again for future logins.

Figure 5: Transferring the passphrase to the desktop wallet (here on KDE Plasma) saves typing for future syncs.