[Unison-hackers] another way to produce path.ml assertion failure assertion failure, tested versions 2.40.65 and 2.48.3

[Alan Schmitt]

Hello,

On 2015-07-21 22:22, Julian Squires <julian at cipht.net> writes:

> On Tue, Jul 21, 2015 at 2:58 PM, Frederik Eaton <frederik at ofb.net> wrote:
>> The bit about syncing between different versions of unison/ocaml is
>> interesting, but it's not relevant to the bug I reported.
>>
>> Can you reproduce the bug by running my script? It syncs locally so
>> there is only one version of unison/ocaml involved at a time.
>
> I've attached a script that may be easier for people to use to
> reproduce the bug, as it uses the text UI and does not depend on
> xvkbd.
>
> FWIW, for me the bug occurs as you describe, with OCaml 4.01 and unison 2.48.0.

I’ve looked a little more into this, and I’m seeing very strange things.
I would be very grateful if other unison hackers could give me a hand
going through this code.

First, the setup. This is what I’m running in a temporary directory:

--8<---------------cut here---------------start------------->8---
#!/bin/bash

UNI=~/src/unison/trunk/src/unison

rm -rf .unison
touch foo bar
echo hi > foo
# echo two > bar
UNISON=.unison $UNI -backup 'Name *' -batch -force foo foo bar
echo bye > bar
UNISON=.unison $UNI -backup 'Name *' -batch foo bar
--8<---------------cut here---------------end--------------->8---

I see the bug with trunk, 2.48, and 2.40 (I could not compile earlier
versions with my ocaml, but I can install another one if need be).

The setup is a bit strange: it directly synchronizes two files, which
means that the relative path to be synchronized in empty. This breaks
some assumptions for the stasher when it needs to move the current
backup file (named simply "backup") to a version with a number appended:
Path.addPrefixToFinalName asserts the path is not empty, which is wrong
in this case. Should the assertion go away?

While reproducing this, I found another very strange bug. If I run the
following, where the length of the file is the same:

--8<---------------cut here---------------start------------->8---
#!/bin/bash

UNI=~/src/unison/trunk/src/unison

rm -rf .unison
touch foo bar
echo hi > foo
# echo two > bar
UNISON=.unison $UNI -backup 'Name *' -batch -force foo foo bar
echo by > bar
UNISON=.unison $UNI -backup 'Name *' -batch foo bar
--8<---------------cut here---------------end--------------->8---

then unison tells me that there is nothing to synchronize for the second
run! This is the full output:

--8<---------------cut here---------------start------------->8---
[schmitta at top:~/tmp/unison_bug]
% ./bug.sh
Contacting server...
Looking for changes
Warning: No archive files were found for these roots, whose canonical names are:
	/Users/schmitta/tmp/unison_bug/foo
	/Users/schmitta/tmp/unison_bug/bar
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

Reconciling changes
file     ====> file       /
foo          : file               modified on 2015-09-19 at 15:43:54  size 3         rw-r--r--
bar          : file               modified on 2015-09-19 at 15:43:54  size 4         rw-r--r--
Propagating updates
UNISON 2.49.2 started propagating changes at 15:43:55.97 on 19 Sep 2015
[BGN] Updating file  from /Users/schmitta/tmp/unison_bug/foo to /Users/schmitta/tmp/unison_bug/bar
[END] Updating file
UNISON 2.49.2 finished propagating changes at 15:43:55.97 on 19 Sep 2015
Saving synchronizer state
Synchronization complete at 15:43:55  (1 item transferred, 0 skipped, 0 failed)
Contacting server...
Looking for changes
Reconciling changes
Nothing to do: replicas have not changed since last sync.
[schmitta at top:~/tmp/unison_bug]
% cat foo
hi
[schmitta at top:~/tmp/unison_bug]
% cat bar
by
--8<---------------cut here---------------end--------------->8---

This makes me wonder: is unison supposed to work in this scenario
(directly synchronizing two files)?

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Last week athmospheric CO₂ average (Updated September 13, 2015, Mauna Loa Obs.):
397.77 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/20150919/0cfd5f76/attachment.asc>