[Unison-hackers] backup bug with backuplocation being only a directory?

[Alan Schmitt]

Hello,

I’m setting up some unison backups and I think I have stumbled upon
a bug. The problem is when the backupprefix preference is a directory:
after the backup directory is created, it is proposed to be synchronized
for the following sync.

Here is a detailed example:

With this profile

--8<---------------cut here---------------start------------->8---
root = /Users/schmitta/tmp/unison_test/a
root = /Users/schmitta/tmp/unison_test/b

backup = Name *

backuplocation = local
backupprefix = .unisonbak/
backupsuffix = .$VERSION
--8<---------------cut here---------------end--------------->8---

If I do the following (I assume a and b are created and empty):

% unison testbak
Contacting server...
Looking for changes
Reconciling changes
Nothing to do: replicas have not changed since last sync.

% touch a/foo

% unison testbak -batch
Contacting server...
Looking for changes
Reconciling changes
new file ---->            foo
a            : new file           modified on 2016-01-30 at 15:22:39  size 0         rw-r--r--
b            : absent
Propagating updates
UNISON 2.48.3 started propagating changes at 15:22:52.16 on 30 Jan 2016
[BGN] Copying foo from /Users/schmitta/tmp/unison_test/a to /Users/schmitta/tmp/unison_test/b
[END] Copying foo
UNISON 2.48.3 finished propagating changes at 15:22:52.16 on 30 Jan 2016
Saving synchronizer state
Synchronization complete at 15:22:52  (1 item transferred, 0 skipped, 0 failed)

% ls -al a b
a:
total 0
drwxr-xr-x+ 3 schmitta  staff  102 Jan 30 15:22 .
drwxr-xr-x+ 4 schmitta  staff  136 Jan 30 15:21 ..
-rw-r--r--+ 1 schmitta  staff    0 Jan 30 15:22 foo

b:
total 0
drwxr-xr-x+ 3 schmitta  staff  102 Jan 30 15:22 .
drwxr-xr-x+ 4 schmitta  staff  136 Jan 30 15:21 ..
-rw-r--r--+ 1 schmitta  staff    0 Jan 30 15:22 foo

% echo hello > a/foo; unison testbak -batch
Contacting server...
Looking for changes
Reconciling changes
changed  ---->            foo
a            : changed file       modified on 2016-01-30 at 15:23:49  size 6         rw-r--r--
b            : unchanged file     modified on 2016-01-30 at 15:22:39  size 0         rw-r--r--
Propagating updates
UNISON 2.48.3 started propagating changes at 15:23:50.46 on 30 Jan 2016
[BGN] Updating file foo from /Users/schmitta/tmp/unison_test/a to /Users/schmitta/tmp/unison_test/b
[END] Updating file foo
UNISON 2.48.3 finished propagating changes at 15:23:50.46 on 30 Jan 2016
Saving synchronizer state
Synchronization complete at 15:23:50  (1 item transferred, 0 skipped, 0 failed)

% ls -al a b
a:
total 8
drwxr-xr-x+ 3 schmitta  staff  102 Jan 30 15:22 .
drwxr-xr-x+ 4 schmitta  staff  136 Jan 30 15:21 ..
-rw-r--r--+ 1 schmitta  staff    6 Jan 30 15:23 foo

b:
total 8
drwxr-xr-x+ 4 schmitta  staff  136 Jan 30 15:23 .
drwxr-xr-x+ 4 schmitta  staff  136 Jan 30 15:21 ..
drwxr-xr-x+ 3 schmitta  staff  102 Jan 30 15:23 .unisonbak
-rw-r--r--+ 1 schmitta  staff    6 Jan 30 15:23 foo

# until here all is as expected, but …

% unison testbak
Contacting server...
Looking for changes
Reconciling changes

a              b
         <---- new dir    .unisonbak  [f]

Note that the bug does not happen if the prefix is more than
a directory, for instance:

backupprefix = .unisonbak/bak__

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated January 29, 2016, Mauna Loa Obs.): 402.60 ppm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20160130/349b4e72/attachment-0001.asc>