Unison synchronization problem. Roots are not identical after synchronization.
- by binary255
Hi. When I synchronize two folders using Unison, only one of the roots seems to be affected. Below are all the information I would think is necessary to figure out why it is working like it is.
I'm using
$ unison -version
unison version 2.27.57
From the Ubuntu repositories.
My work laptop:
$ echo $UNISONLOCALHOSTNAME
worklaptop
$ pwd
/home/userfoo
$ ls -lAR .unison*
.unison:
total 8
drwxr-xr-x 2 userfoo userfoo 4096 2010-04-26 11:39 backups
-rw-r--r-- 1 userfoo userfoo 231 2010-04-26 11:38 default.prf
.unison/backups:
total 0
.unisonroot:
total 0
$ cat .unison/default.prf
# Roots of the synchronization
root = /home/userfoo/.unisonroot
root = ssh://devel//home/userbar/.unisonroot
path = *
backuplocation = central
backupdir = /home/.unison/backups
backupprefix = $VERSION.bak
$ mkdir .unisonroot/aDirectoryFrom-$UNISONLOCALHOSTNAME
$ echo something >.unisonroot/aFileFrom-$UNISONLOCALHOSTNAME
$ ls .unisonroot/
aDirectoryFrom-worklaptop aFileFrom-worklaptop
And the Ubuntu server I want to synchronize with:
$ echo $UNISONLOCALHOSTNAME
workcmpuserbardevel
$ pwd
/home/userbar
$ ls -lAR .unison*
.unison:
total 4
drwxr-xr-x 2 userbar userbar 4096 2010-04-26 11:38 .unison
.unison/.unison:
total 0
.unisonroot:
total 0
$ mkdir .unisonroot/aDirectoryFrom-$UNISONLOCALHOSTNAME
$ echo something >.unisonroot/aFileFrom-$UNISONLOCALHOSTNAME
$ ls .unisonroot/
aDirectoryFrom-workcmpuserbardevel aFileFrom-workcmpuserbardevel
I perform the unison synchronization:
$ echo $UNISONLOCALHOSTNAME
worklaptop
$ unison
Contacting server...
Connected [//worklaptop//home/userfoo/.unisonroot -> //workcmpuserbardevel//home/userbar/.unisonroot]
Looking for changes
Warning: No archive files were found for these roots, whose canonical names are:
/home/userfoo/.unisonroot
//workcmpuserbardevel//home/userbar/.unisonroot
This can happen either
because this is the first time you have synchronized these roots,
or because you have upgraded Unison to a new version with a different
archive format.
Update detection may take a while on this run if the replicas are
large.
Unison will assume that the 'last synchronized state' of both replicas
was completely empty. This means that any files that are different
will be reported as conflicts, and any files that exist only on one
replica will be judged as new and propagated to the other replica.
If the two replicas are identical, then no changes will be reported.
If you see this message repeatedly, it may be because one of your machines
is getting its address from DHCP, which is causing its host name to change
between synchronizations. See the documentation for the UNISONLOCALHOSTNAME
environment variable for advice on how to correct this.
Donations to the Unison project are gratefully accepted:
http://www.cis.upenn.edu/~bcpierce/unison
Press return to continue.[<spc>] Waiting for changes from server
Reconciling changes
local workcmps...
dir ----> aDirectoryFrom-worklaptop [f]
file ----> aFileFrom-worklaptop [f]
Proceed with propagating updates? [] y
Propagating updates
UNISON 2.27.57 started propagating changes at 11:49:14 on 26 Apr 2010
[BGN] Copying aDirectoryFrom-worklaptop from /home/userfoo/.unisonroot to //workcmpuserbardevel//home/userbar/.unisonroot
[BGN] Copying aFileFrom-worklaptop from /home/userfoo/.unisonroot to //workcmpuserbardevel//home/userbar/.unisonroot
[END] Copying aDirectoryFrom-worklaptop
[END] Copying aFileFrom-worklaptop
UNISON 2.27.57 finished propagating changes at 11:49:14 on 26 Apr 2010
Saving synchronizer state
Synchronization complete (2 items transferred, 0 skipped, 0 failures)
And then check the .unisonroot directory on the computer I started the synchronization from:
$ ls .unisonroot/
aDirectoryFrom-worklaptop aFileFrom-worklaptop
And on the server:
$ echo $UNISONLOCALHOSTNAME
workcmpuserbardevel
$ ls .unisonroot/
aDirectoryFrom-worklaptop aFileFrom-worklaptop
aDirectoryFrom-workcmpuserbardevel aFileFrom-workcmpuserbardevel
As can be seen above, the contents of the laptop .unisonroot has not changed while the servers .unisonroot has. The desired result would have been that the two folders would have ended up being identical, holding the union of the contents of the two roots.