0

I use unison to sync two folders that are in separate computers (via unison command with ssh). If for convenience I happen to change the name of the parent folder, unison start to sync the folders as if it were the first time I sync them, taking a lot of time (because the two folders are quite large). Here is the message I get:

Looking for changes
Warning: No archive files were found for these roots, whose canonical names are:
    /path/to/my/folder1
    /path/to/my/folder2
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.

Is there a way to tell unison that these folders have previously been synced? Perhaps changing the path somewhere and recovering the last unison file?

Similarly, maybe a related question: if I copy one of my folders to a new computer and therefore they are already in that moment identical, could I tell unison that they are identical to skip the update detection process?

1 Answer 1

0

You can (carefully) use the rootalias option. If you get this wrong you can completely break the mirror though so do take care.

The documentation (man unison) says,

rootalias xxx When calculating the name of the archive files for a given pair of roots, unison replaces any roots matching the left‐hand side of any rootalias rule by the corresponding right‐hand side.

What I think is not so well documented is the syntax of the rootalias parameter xxx. (It's defined in the section Path Specification but you have to know to look there and realise it applies to rootalias.)

Example for your situation

# Existing command (#1)
unison wasSrc remoteHost:dst

# Your attempted new command (#2)
unison newSrc remoteHost:dst

# Modified new command (#3)
unison -rootalias "//$(hostname)/$PWD/newSrc -> //$(hostname)/$PWD/wasSrc" newSrc remoteHost:dst

Once the modified new command (#3) completes successfully you can remove the -rootalias option and revert to the simpler version (#2).

Notes

  • If wasSrc and newSrc are already absolute paths that start with / then you should not include $PWD but instead use this variant that omits $PWD:

     unison -rootalias "//$(hostname)/newSrc -> //$(hostname)/wasSrc" newSrc remoteHost:dst
    
  • If you're not using bash or some other shell that maintains $PWD you can use $(/bin/pwd) or a hard-coded absolute path such as /home/user/path/to/newSrc

5
  • Thank you so much @Chris for your reply. I'm trying your suggestion but cannot make it work. I'm also testing it with just two folders in the same computer but still no luck. The old folder was 'sorigin'. Now renamed to 'torigin'. The destination folder to sync is called 'remote'. Here is the command I use: unison -rootalias "/home/andres/torigin -> /home/andres/sorigin" /home/andres/torigin/ /home/andres/remote/. Commented Jan 20 at 15:39
  • I keep getting the same message: Warning: No archive files were found for these roots, whose canonical names are: /home/andres/torigin /home/andres/remote 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. Commented Jan 20 at 15:41
  • If I use the $(hostname) variable in the command I get the same message. Command: unison -rootalias "//$(hostname)/home/andres/torigin -> //$(hostname)/home/andres/sorigin" /home/andres/torigin/ /home/andres/remote. Commented Jan 20 at 15:50
  • Continue testing.... I noticed that If I misspell the rootalias giving completely erroneous folder names, I get the same very message as always. So, is rootalias working well? Am I writing the command correctly? Commented Jan 20 at 15:58
  • @Andres please update your question to provide a sufficiently working example that I can then modify for you. (i.e. if you're going to obfuscate, do so but remember I'll be working from your obfuscated example, which I in turn will have to modify to test against.) Commented Jan 20 at 19:19

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.