Even stranger.  If I run

[lulu5] unison-2.27.57 > make UISTYLE=text
UISTYLE = text
Building for Unix
NATIVE = true
THREADS = false
STATIC = false
OSTYPE =
OSARCH =
ocamlopt: ubase/prefs.mli ---> ubase/prefs.cmi
ocamlopt -I lwt -I ubase -c /nethome/jdr/local/unison-2.27.57/ubase/prefs.mli


Then

ocamlopt -I lwt -I ubase -c /nethome/jdr/local/unison-2.27.57/ubase/prefs.ml

a few times, issuing a

make UISTYLE=text

(which generates the same error)

Then,

ocamlopt -I lwt -I ubase -c /nethome/jdr/local/unison-2.27.57/ubase/prefs.ml

(repeat a few times with the same error)

Eventually,
[lulu5] unison-2.27.57 > make UISTYLE=text
UISTYLE = text
Building for Unix
NATIVE = true
THREADS = false
STATIC = false
OSTYPE =
OSARCH =
ocamlopt: ubase/trace.ml ---> ubase/trace.cmx
ocamlopt -I lwt -I ubase -c
/nethome/adiercks/local/unison-2.27.57/ubase/trace.ml
make: ocamlopt: Command not found
make: *** [ubase/trace.cmx] Error 127


And I have moved on to the next file.  I've never seen anything like this...


--- In unison-users@yahoogroups.com, Alan Schmitt <alan.schmitt@...> wrote:
>
> On 16 oct. 2011, at 17:01, Alan wrote:
>
> > Immediately makes a file.
> >
> > [lulu5] unison-2.27.57 > ocamlc -o m
> > [lulu5] unison-2.27.57 > rm mkProjectInfo
> > [lulu5] unison-2.27.57 > ocamlc -o mkProjectInfo mkProjectInfo.ml
> > [lulu5] unison-2.27.57 > ls -a mkProjectInfo
> > -rwxrwxr-x 1 jdr  hdr91134 Oct 16 07:59 mkProjectInfo
>
>
> (I'm copying the list in case someone else knows what is going on)
>
> This is very strange. Have you tried manually doing the mkProjectInfo, then
restarting "make"?
>
> Alan
>

Hi!

I have the problem that both my local (laptop on DHCP) and remote (supercomputer
with several login nodes) host names change from one synchronization to the
next. It works to export UNISONLOCALHOSTNAME on my laptop, but on the
supercomputer, nothing happens. This could be because the ssh connection doesn't
run the full .bash_profile, or some such. Is there an easy fix to this?

Cheers
Paul

On 17 oct. 2011, at 09:39, Paul Anton Letnes wrote:

> Hi!
>
> I have the problem that both my local (laptop on DHCP) and remote
(supercomputer with several login nodes) host names change from one
synchronization to the next. It works to export UNISONLOCALHOSTNAME on my
laptop, but on the supercomputer, nothing happens. This could be because the ssh
connection doesn't run the full .bash_profile, or some such. Is there an easy
fix to this?

You could specify a script to run on the server (using the servercmd option),
and in this script do the export UNISONLOCALHOSTNAME before calling the unison
binary.

Hope this helps,

Alan

>> I tried it now with a small subdirectory for testing and none of the
>> directions work. To exclude any mistakes I used the actual path names
>> and not the symbolic link. I did the initial sync with
>>
>> root = ssh://server1//backup/111012/
>> root = /backup/test/
>
> This should create an archive for path 111012. You can check this doing
> the "head -n 3" for the new archive file. (I would recommend doing this
> to make sure I'm not mistaken.)
>
>> root = ssh://server1//backup/111013/
>> rootalias = //server1/backup/111012/ -> //server1//backup/111013/
>> root = /backup/test/
>
> The root name here is 111013. The rootalias says "if the root name
> computed is 111012, then consider it's 111013". It's not the case here,
> so an archive with 111013 is created.

Exactly, but that's what you suggested in your previous post.

>> rootalias = //server1/backup/111013/ -> //server1//backup/111012/
>
> This is very surprising. Could you do the "head -n 3" on the newly
> created archive file (having both would be useful).

==> /root/.unison/are61f28a1336908532c6206d58b1c84f2 <==
Unison archive format 22
Archive for root //server2//backup/test synchronizing roots
//server2//backup/test, //server1//backup/111012
Written at 2011-10-16 at 18:04:11 - case sensitive mode

==> /root/.unison/ar43914305c775f8d0afcc7f2abe105d14 <==
Unison archive format 22
Archive for root //server2//backup/test synchronizing roots
//server2//backup/test, //server1//backup/111013
Written at 2011-10-16 at 18:08:13 - case sensitive mode

> Note that the left hand side and the right hand side of the rootalias
> should match the name recorded in the archive file for things to work.

This I don't understand and doesn't make sense to me. I thought the left
hand side has to match one of the roots in the profile and replaces it
with the right hand side when looking for the archive file to use. Or
maybe I didn't understand the whole concept of the rootalias and it is
not the right solution for my problem.

I have a new backup folder every day and want to use a archive file from
a previous sync. I DON'T want to scan this new folder and create a new
archive file. How else could this new folder be in any of the archive files.

It would be nice if there was an option in Unison not to expand a
symbolic link and rather us the link name as is.

So it looks like I have to create a copy of the last backup in a folder
with a fixed name on server1 and use this as root. Deleting the old and
creating a new one adds another 10 minutes runtime to my backup script.

Thanks
Thomas

On 17 oct. 2011, at 11:53, Thomas Boehm wrote:

>> The root name here is 111013. The rootalias says "if the root name
>> computed is 111012, then consider it's 111013". It's not the case here,
>> so an archive with 111013 is created.
>
> Exactly, but that's what you suggested in your previous post.

Oops, sorry about that.

>>> rootalias = //server1/backup/111013/ -> //server1//backup/111012/
>>
>> This is very surprising. Could you do the "head -n 3" on the newly
>> created archive file (having both would be useful).
>
> ==> /root/.unison/are61f28a1336908532c6206d58b1c84f2 <==
> Unison archive format 22
> Archive for root //server2//backup/test synchronizing roots
> //server2//backup/test, //server1//backup/111012
> Written at 2011-10-16 at 18:04:11 - case sensitive mode
>
> ==> /root/.unison/ar43914305c775f8d0afcc7f2abe105d14 <==
> Unison archive format 22
> Archive for root //server2//backup/test synchronizing roots
> //server2//backup/test, //server1//backup/111013
> Written at 2011-10-16 at 18:08:13 - case sensitive mode

It's a shot in the dark, but have you tried removing the trailing '/' in your
rootalias directives? They do not appear in the names in the archive.

>> Note that the left hand side and the right hand side of the rootalias
>> should match the name recorded in the archive file for things to work.
>
> This I don't understand and doesn't make sense to me. I thought the left
> hand side has to match one of the roots in the profile and replaces it
> with the right hand side when looking for the archive file to use.

This is correct. But the root in the profile may not contain all the information
(for instance the host name in case of local files), so it's more than just what
is specified as the root.

The reason I said "the left hand side and the right hand side of the rootalias
should match the name recorded in the archive" is to make sure that it is
recognized as such. To be precise, the left-hand side should match the full root
specified (included the host name that may be computed), and the right-hand side
should match one of the archives.

Could you try with removing the trailing '/'?

Thanks,

Alan

I'm coming late to this conversation and am not completely sure I understand the
issue, but this...

> I have a new backup folder every day and want to use a archive file from
> a previous sync. I DON'T want to scan this new folder and create a new
> archive file. How else could this new folder be in any of the archive files.

… makes it sound as though you are creating a *new* set of files every day on
one of the machines (i.e., they have different inode numbers in the filesystem,
different creation times, etc., compared to the files you were synchronizing the
day before), and you want these to be synchronized with the same set of files on
the other side every day.

If this is the case, then I'm afraid what you are asking for is not possible. 
If Unison hasn't seen a file before, it has to scan its contents to know what is
in it.  It normally uses <same inode number plus same last-modified time> as a
quick check that the contents have not changed, but it can't do that here. 
There is a -fastcheck switch that makes it use just <modtime plus length>, but I
think this won't work either here, since the modtimes will also have changed.

      - Benjamin

Benjamin C. Pierce wrote:
> I'm coming late to this conversation and am not completely sure I understand
the issue, but this...
>
>> I have a new backup folder every day and want to use a archive file from
>> a previous sync. I DON'T want to scan this new folder and create a new
>> archive file. How else could this new folder be in any of the archive files.
>
> … makes it sound as though you are creating a *new* set of files every day on
one of the machines (i.e., they have different inode numbers in the filesystem,
different creation times, etc., compared to the files you were synchronizing the
day before), and you want these to be synchronized with the same set of files on
the other side every day.
>
> If this is the case, then I'm afraid what you are asking for is not possible. 
If Unison hasn't seen a file before, it has to scan its contents to know what is
in it.  It normally uses <same inode number plus same last-modified time> as a
quick check that the contents have not changed, but it can't do that here. 
There is a -fastcheck switch that makes it use just <modtime plus length>, but I
think this won't work either here, since the modtimes will also have changed.

It's a new backup folder every day, but unchanged files have the same
inode number and creation time using hard links. I use rsync -av
--delete --link-dest=<previous backup folder> <directory to backup> <new
backup folder> to create my backups.

So technically it's the same folder with a few changed files under a new
folder name. Of course, the changed files should be scanned, but not the
whole folder.

Thanks
Thomas

On 17 oct. 2011, at 14:51, PsyKi wrote:

> Thanks Alan, but it doesn't quite explain everything.
>
> I'm just wondering:
> Let's say:
> - I have a 10MB file on each end (server and client). (Synchronized via
unison)
> - I change the document on the client, and add 5MB of data to it.
>
> What will be sent over the network on my next sync?
> The 5MB of changes? (diff?)
> Or the entire 10MB file?
>
> Does it depend on the type of file data (text vs binary, ..)?
> Is there a treshold somewhere?
> ..?

It's typically the technical detail I don't know. I would guess that only the
change would be sent.

Alan

OK, then I agree that rootalias should be the answer.

    - B

On Oct 17, 2011, at 8:46 AM, Thomas Boehm wrote:

> Benjamin C. Pierce wrote:
>> I'm coming late to this conversation and am not completely sure I understand
the issue, but this...
>>
>>> I have a new backup folder every day and want to use a archive file from
>>> a previous sync. I DON'T want to scan this new folder and create a new
>>> archive file. How else could this new folder be in any of the archive files.
>>
>> … makes it sound as though you are creating a *new* set of files every day on
one of the machines (i.e., they have different inode numbers in the filesystem,
different creation times, etc., compared to the files you were synchronizing the
day before), and you want these to be synchronized with the same set of files on
the other side every day.
>>
>> If this is the case, then I'm afraid what you are asking for is not possible.
If Unison hasn't seen a file before, it has to scan its contents to know what is
in it.  It normally uses <same inode number plus same last-modified time> as a
quick check that the contents have not changed, but it can't do that here. 
There is a -fastcheck switch that makes it use just <modtime plus length>, but I
think this won't work either here, since the modtimes will also have changed.
>
> It's a new backup folder every day, but unchanged files have the same
> inode number and creation time using hard links. I use rsync -av
> --delete --link-dest=<previous backup folder> <directory to backup> <new
> backup folder> to create my backups.
>
> So technically it's the same folder with a few changed files under a new
> folder name. Of course, the changed files should be scanned, but not the
> whole folder.
>
> Thanks
> Thomas
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

The precise answer is a little complicated, but the short version is that only
the changes will be sent.  Check out the documentation for the rsync utility for
more details, if you want -- we use the same algorithm.

     - Benjamin

On Oct 17, 2011, at 9:03 AM, Alan Schmitt wrote:

> On 17 oct. 2011, at 14:51, PsyKi wrote:
>
>> Thanks Alan, but it doesn't quite explain everything.
>>
>> I'm just wondering:
>> Let's say:
>> - I have a 10MB file on each end (server and client). (Synchronized via
unison)
>> - I change the document on the client, and add 5MB of data to it.
>>
>> What will be sent over the network on my next sync?
>> The 5MB of changes? (diff?)
>> Or the entire 10MB file?
>>
>> Does it depend on the type of file data (text vs binary, ..)?
>> Is there a treshold somewhere?
>> ..?
>
> It's typically the technical detail I don't know. I would guess that only the
change would be sent.
>
> Alan
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

PsyKi wrote:
> It's what I guessed, but I wasn't sure that unison used the rsync
> algorithm everywhere.

I don't know whether Unison uses it by default, but rsync = true in your
profile or -rsync on the command line will enable it for sure.

Edit: Just looked it up

http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual\
.html#prefs

...
-rsync             activate the rsync transfer mode (default true)
...

HTH
Thomas

Hello,

I updated my Kubuntu-Box to version 11.10.
Now i can't use the graphical interface of Unison (2.40.63) anymore.
Unison still works in text-mode.


The GUI says "Contacting server..." and does nothing. On the right top stands
"No profile"

Here is the debug output:
-------------------------------------------------------------------
$ unison -debug all Profile\ Name


Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve
property `gtk-enable-event-sounds' of type `gboolean' from rc file value
"((GString*) 0x8d23450)" of type `gboolean'
Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve
property `gtk-enable-input-feedback-sounds' of type `gboolean' from rc file
value "((GString*) 0x8d23480)" of type `gboolean'
Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve
property `gtk-button-images' of type `gboolean' from rc file value "((GString*)
0x8d23350)" of type `gboolean'
Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve
property `gtk-menu-images' of type `gboolean' from rc file value "((GString*)
0x8d23310)" of type `gboolean'
[startup] Preferences:
ui = graphic
host =
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = Profile Name
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat =
contactquietly = false
key =
label =
expert = false
height = 15
auto = false
maxthreads = 0
prefer =
force =
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
backupdir =
maxbackups = 2
backups = false
backupsuffix =
backupprefix = .bak.$VERSION.
backuploc = central
copymax = 1
copyquoterem = default
copythreshold = -1
copyprogrest = rsync --partial --append-verify --compress
copyprog = rsync --partial --inplace --compress
rsync = true
fastcheck = default
ignorelocks = false
dumparchives = false
ignorearchives = false
showarchive = false
rootsName =
fat = false
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
ignore = Name {.dropbox*}
ignore = Name {*nosync*}
ignore = Name {.directory}
ignore = Name {,.}*{.mp3}
ignore = Name {,.}*{.ogm}
ignore = Name {,.}*{.AVI}
ignore = Name {,.}*{.vmdk}
confirmbigdel = true
batch = false
path = Dokumente
path = calibre_config
root = ssh://xxxUser@xxxDomain.net/syncFolder
root = /home/xxxUser/
killserver = false
halfduplex = false
stream = true
addversionno = false
servercmd =
sshargs =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
ignoreinodenumbers = false
links-aux = true
links = default
times = true
group = false
owner = false
numericids = false
dontchmod = false
perms = 1023
rsrc-aux = false
rsrc = default
maxerrors = 1
unicodeCS = false
unicodeEnc = false
unicode = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = /home/xxxUser/unison.log
log = true
debugtimes = false
debug = all
addprefsto =

----------------------------------------------

Thanks for any suggestions!

Any help appreciated!  Unison just hangs with cryptic messages in the terminal
window of the Mac OS.

I've been using Unison for years. Linux. Windows. Mac OSX. USB Drives. SSH
between them all. I'm pretty fluent. I have initiated most syncs from the
Windows computer or Linux computer. Now I need to initiate from the Mac.

I log into SSH with a password, running a Unison profile, and all is okay. Then
Unison would error. Turns out the Windows box has to have the HOME environment
variable set. Fixed that. Log out and log back in, and now that works fine. Now
Unison just hangs. I turn on debug = all in the profile and here's what I get in
the Mac terminal window:

bmmbp:~ brian$ unison acer-docs
2011-10-19 00:48:03.190 Unison[1681:f07] *** __NSAutoreleaseNoPool(): Object
0x20a490 of class NSThread autoreleased with no pool in place - just leaking
2011-10-19 00:48:03.235 Unison[1681:f07] Unknown class MessageProgressIndicator
in Interface Builder file at path
/Applications/Unison.app/Contents/Resources/English.lproj/MainMenu.nib.
2011-10-19 00:48:03.275 Unison[1681:f07] *** WARNING: Method
selectRow:byExtendingSelection: in class ProfileTableView is deprecated. It will
be removed in a future release and should no longer be used.
2011-10-19 00:48:03.285 Unison[1681:f07] Connecting to acer-docs...
about to parse command linePreferences:
ui = graphic
host =
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = acer-docs
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat =
contactquietly = false
key =
label =
expert = false
reusewindows = false
height = 20
auto = false
maxthreads = 20
prefer =
force =
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
fastcheck = true
ignorelocks = false
dumparchives = false
showarchive = false
rootsName =
backupdir =
maxbackups = 2
backups = false
backupsuffix =
backupprefix = .bak.$VERSION.
backuploc = central
copyquoterem = default
copythreshold = -1
copyprogrest = rsync --partial --inplace --compress
copyprog = rsync --inplace --compress
rsync = true
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
ignore = Path {My Music}
ignore = Name {Thumbs.db}
ignore = Name {.DS_Store}
confirmbigdel = true
batch = false
root = ssh://brian@10.0.0.102/testjunk
root = /Users/brian/testjunk
killserver = false
addversionno = false
servercmd =
sshargs =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
pretendwin = false
times = true
group = false
owner = false
numericids = false
dontchmod = false
perms = 0
rsrc-aux = false
rsrc = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = /Users/brian/unison.log
log = true
debugtimes = false
debug = verbose
addprefsto =
[remote] Shell connection: ssh xxxxx
2011-10-19 00:48:03.936 Unison[1681:f07] Got the prompt: 'brian@...'s
password: '
2011-10-19 00:48:04.153 Unison[1681:f07] Connected.
[remote+] grab: Unison 2.32\n\000\000\000\000
[remote+] Waiting for next message
[remote+] Received the write permission
[remote+] Received write token (1)
[remote+] Waiting for next message
[remote+] send [negociateFlowControl-args]
'\132\149??\000\000\000\001\000\000...' 21 bytes
[remote+] send [rsp] '\132\149??\000\000\000\022\000\000...' 42 bytes
[remote+] Sending request (id: 2)
[remote+] Remaining tokens: 0
[remote+] Sending write token
[remote+] dump:
\002\000\000\000-\000\000\000rsp\132\149??\000\000\000\022\000\000\000\000\000\0\
00\000\t\000\000\000\006\1464negociateFlowControl.\000\000\000negociateFlowContr\
ol-args\132\149??\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\00\
0@\000\000\000\000

Hello all. Is there an option to make [d] do something useful on
new files ? Instead of writing "Can't diff: path doesn't refer
to a file in both replicas", showing the attributes and contents
of the new file through the pager. Same thing as -N in GNU diff.

Thanks in advance.

--
André Majorel http://www.teaser.fr/~amajorel/

I'm trying to limit the size of files included in the sync operation by using
the rsync --max-size flag.  The problem I'm seeing is that that causes the
program to hang and I have to kill it with ctrl+c.

Here's an example.  Note that I've cut out a lot of the output to try and make
this clearer.

>>>>>

kevin@machineA ~]$ unison -batch -rshargs -C -prefer newer -times issues

Contacting server...
Connected [//machineA//xxxx/xxxx/kevin -> //machineB//xxx/xxxx/kevin]
Looking for changes
   Waiting for changes from server
Reconciling changes
new file ====> new file   _issues/xxxxxx
local        : new file           modified on 2011-08-31 at 12:40:56  size
967990461 rw-r--r--

UNISON 2.40.63 started propagating changes at 09:05:11.57 on 20 Oct 2011
[BGN] Updating file xxxxxx from /smb/csoft/kevin to //love2//smb/csoft/Kevin

Failed: External copy program did not create target file (or bad length):
.unison.xxxxxx.8487c2a9b8bcec5e6af10bc95e90b484.unison.tmp
  70%  00:07 ETAFailed [xxxxxxx.gz]: External copy program did not create target
file

Terminated!
  97%  00:03 ETAKilled by signal 2.

<<<<<<

There's approx 35GB of files in the directory I'm syncing.  Everything except
the very large files I'm trying to exclude has already been synchronised using
rsync.  The reconciliation changes output from Unison indicates that it's only
these large files that need to be synchronised.

I'm using a 4Mbps/800Kbps WAN connection.  I have tried this several times on
the same data and been forced to terminate the program manually every time.  The
longest I've left it running before terminating manually is 30 minutes.  I'm
using Unison 2.40.63 on CentOS 4.  MachineA is x86_64 and MachineB is i686.

What might be causing Unison to hang like this?

Thanks,

Kevin

> Failed: External copy program did not create target file
> (or bad length):
> .unison.xxxxxx.8487c2a9b8bcec5e6af10bc95e90b484.unison.tmp
> 70% 00:07 ETAFailed [xxxxxxx.gz]: External copy program
> did not create target file

With debug enabled I see that the operation appears to be looping, producing
this output:

[rsynctoken] flushing the token queue
  96%  00:03 ETA[server: generic] receiving 65497 bytes
[rsynctoken] flushing the token queue
[rsynctoken] flushing the token queue
  96%  00:03 ETA[server: generic] receiving 65497 bytes
[server: generic] receiving 65497 bytes
[server: generic] receiving 65497 bytes
[rsynctoken] flushing the token queue
[rsynctoken] flushing the token queue
  96%  00:03 ETA<>$[server: generic] receiving 65497 bytes

Any ideas?

Kevin

Looks like it's probably just transferring the file, which I believe is correct
behavior: the external copy program is expected to actually do the copy, and if
it doesn't for some reason then Unison should (and does) fail back to doing the
copy itself.

     - B


On Oct 20, 2011, at 10:35 AM, Kevin Clark wrote:

>> Failed: External copy program did not create target file
>> (or bad length):
>> .unison.xxxxxx.8487c2a9b8bcec5e6af10bc95e90b484.unison.tmp
>> 70% 00:07 ETAFailed [xxxxxxx.gz]: External copy program
>> did not create target file
>
> With debug enabled I see that the operation appears to be looping, producing
this output:
>
> [rsynctoken] flushing the token queue
> 96%  00:03 ETA[server: generic] receiving 65497 bytes
> [rsynctoken] flushing the token queue
> [rsynctoken] flushing the token queue
> 96%  00:03 ETA[server: generic] receiving 65497 bytes
> [server: generic] receiving 65497 bytes
> [server: generic] receiving 65497 bytes
> [rsynctoken] flushing the token queue
> [rsynctoken] flushing the token queue
> 96%  00:03 ETA<>$[server: generic] receiving 65497 bytes
>
> Any ideas?
>
> Kevin
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

> Looks like it's probably just transferring the file, which I believe is
> correct behavior: the external copy program is expected to actually do
> the copy, and if it doesn't for some reason then Unison should (and
> does) fail back to doing the copy itself.

Hmm...perhaps I didn't make my aim clear: I'm trying to skip these large files. 
I thought I could do this with rsync --max-size, as per the FAQ.

What's strange is that it does seem to work but only on a smaller set of files. 
Here's an example where a 2GB has been added to the local copy.  Unison
identifies it and attempts to transfer it with rsync.  The rsync transfer fails
because of the --max-size setting but still the Unison synchronisation operation
completes with a report that there was a failed transfer.

[kevin@machineA unison_testing]$ unison -batch -rshargs -C -prefer newer -times
unison_testing
Contacting server...
Connected [//xxx//xxxx/xxxxx/kevin -> //yyy//yyyy/yyyyy/kevin]
Looking for changes
   Waiting for changes from server
Reconciling changes
new file ---->            unison_testing/bigfile.ova
local        : new file           modified on 2011-09-09 at  9:58:16  size
2289288704 rw-------
love2        : absent
Propagating updates
UNISON 2.40.63 started propagating changes at 12:40:04.44 on 20 Oct 2011
[BGN] Copying unison_testing/bigfile.ova from /xxxx/xxxxx/kevin to
//yyy//yyyy/yyyyy/kevin
rsync --compress --bwlimit=200 --max-size=20M '/xxxx/xxxxx/kevin/bigfile.ova'
'yyy:'\''/yyyy/yyyyy/kevin/unison_testing/.unison.bigfile.ova.8487c2a9b8bcec5e6a\
f10bc95e90b484.unison.tmp'\'''
Failed: External copy program did not create target file (or bad length):
.unison.bigfile.ova.8487c2a9b8bcec5e6af10bc95e90b484.unison.tmp
100%  00:00 ETAFailed [unison_testing/bigfile.ova]: External copy program did
not create target file (or bad length):
.unison.bigfile.ova.8487c2a9b8bcec5e6af10bc95e90b484.unison.tmp
UNISON 2.40.63 finished propagating changes at 12:40:18.07 on 20 Oct 2011
Saving synchronizer state
Synchronization incomplete at 12:40:20  (0 items transferred, 0 skipped, 1
failed)
   failed: unison_testing/bigfile.ova
[kevin@machineA unison_testing]$

On the larger set of data, which is more representative of the actual data that
I want to synchronise (i.e. it contains several >1GB files), the output again
shows rsync failing but then - as you say - Unison falls back to doing the copy
itself, which is a different outcome to what I expect.

Kevin

Mac Unison starts up SSH fine, connecting to a Windows freeSSH host. The Windows
unison server is started and few exchanges happen.  Then Unison just hangs. I
turn on debug in the unison profile and here's what I get in the Mac terminal
window:

  [remote+] grab: Unison 2.32\n\000\000\000\000
  [remote+] Waiting for next message
  [remote+] Received the write permission
  [remote+] Received write token (1)
  [remote+] Waiting for next message
  [remote+] send [negociateFlowControl-args]
'\132\149??\000\000\000\001\000\000...' 21 bytes
  [remote+] send [rsp] '\132\149??\000\000\000\022\000\000...' 42 bytes
  [remote+] Sending request (id: 2)
  [remote+] Remaining tokens: 0
  [remote+] Sending write token
  [remote+] dump:
\002\000\000\000-\000\000\000rsp\132\149??\000\000\000\022\000\000\000\000\000\0\
00\000\t\000\000\000\006
 
\1464negociateFlowControl.\000\000\000negociateFlowControl-args\132\149??\000\00\
0\000\001\000\000\000\000\000\000\000\000\000\000
  \000\000@\000\000\000\000

Then nothing.. even after really long waits, nothing. Help ??

I slapped together an upstart script for unison, but it fails with the following
log message: init: unison main process (29316) terminated with status 2

Is there a special trick to get unison started this way? I am using Ubuntu 11.04

Here is the script:
---
# upstart script to start unison socket service
# using port 2225
# This file should be named unison.conf
# and located in /etc/init/

description "unison service"
author "Alan Pater <alan.pater@...>"

# When to start the service
start on runlevel [2345]

# When to stop the service
stop on runlevel [016]

# Automatically restart process if crashed
respawn

# Lets upstart know the process will detach itself to the background
expect fork

# Start the process
exec unison -socket 2225
---

It has been suggested that I use inetd (or xinetd) instead. There are
no config files for those on this Ubuntu system, is there something
else I should be using?

In other words, what is best practice for starting unison as a
service? xinetd? upstart? initd? Or something else?

Alan

On Tue, Oct 25, 2011 at 8:06 PM, Alan <alan.pater@...> wrote:
>
>
>
> I slapped together an upstart script for unison, but it fails with the
following log message: init: unison main process (29316) terminated with status
2
>
> Is there a special trick to get unison started this way? I am using Ubuntu
11.04
>
> Here is the script:
> ---
> # upstart script to start unison socket service
> # using port 2225
> # This file should be named unison.conf
> # and located in /etc/init/
>
> description "unison service"
> author "Alan Pater <alan.pater@...>"
>
> # When to start the service
> start on runlevel [2345]
>
> # When to stop the service
> stop on runlevel [016]
>
> # Automatically restart process if crashed
> respawn
>
> # Lets upstart know the process will detach itself to the background
> expect fork
>
> # Start the process
> exec unison -socket 2225
> ---
>
>

further searching on the interwebs indicates that upstart is indeed best
practice.

I found the problem after enabling extra logging.

    Fatal error: exception Util.Fatal("Environment variable HOME not found")

Here is the working script:

description "unison service"
author "Alan Pater <alan.pater@...>"
env HOME=/home/xobilyol
start on (local-filesystems and net-device-up IFACE!=lo)
respawn
expect fork
exec /usr/bin/unison -socket 2225 >> /var/log/unison.log 2>&1



--- In unison-users@yahoogroups.com, Alan Pater <alan.pater@...> wrote:
>
> It has been suggested that I use inetd (or xinetd) instead. There are
> no config files for those on this Ubuntu system, is there something
> else I should be using?
>
> In other words, what is best practice for starting unison as a
> service? xinetd? upstart? initd? Or something else?

Hello

With the lack of file watcher utility for windows I have been trying to find
other ways of having file sync carried out after a file change.  Having a
scheduled task set up for every 5 mins isn't too good for the hard drives.

I have come across 'directory monitor'
http://brutaldev.com/page/Directory-Monitor.aspx which is currently a free app.
It does a good job of detecting file changes, it can trigger an app on file
change so I set up a cmd file to launch unison and scan the folders.  It works
reasonably well as I have added a delay to the launch of unison, but a lot of
unison windows pop up when there are a lot of file changes.

On speaking to the developer of the app he suggested launching unison with
'C:\Temp\Unison.exe C:\Temp\Unison %~p1 -batch'  this passes the path of the
changed file to unison.  I'm a little unsure if this is good method and how to
set it up properly, for example how would unison know where to sync the file to?
his post (Werner) is here
http://www.brutaldev.com/post/2011/01/05/Directory-Monitor-20-Release-Roadmap.as\
px#id_544a7822-fa22-40e2-8654-da6ba1d0f3f9

So i'm wondering if anybody else has interest in this and if anybody can figure
out how to set up a working method.  The developer seems like a very helpful
chap so he may even be prepared to add extra features to get this working
flawlessly.

Thanks
Pad

<raising hand>   I am definitely interested in having something like
this.
BUT ... if unison has to do a full rescan anyway - I see very little
benefit,  because even quick-scanning most of my profiles take at
minimum 7minutes to run the detection phase.
So unless there is a way to  monitor for change, and tell Unison
*specifically* which file to propagate,  I'm not switching from my
current scheduled hourly batch runs.
Seb

-----Original Message-----
From: unison-users@yahoogroups.com [mailto:unison-users@yahoogroups.com]
On Behalf Of leastsq
Sent: Thu, 2011-10-27 05:58
To: unison-users@yahoogroups.com
Subject: [unison-users] Windows file watcher like utility

Hello

With the lack of file watcher utility for windows I have been trying to
find other ways of having file sync carried out after a file change.
Having a scheduled task set up for every 5 mins isn't too good for the
hard drives.

I have come across 'directory monitor'
http://brutaldev.com/page/Directory-Monitor.aspx which is currently a
free app.
It does a good job of detecting file changes, it can trigger an app on
file change so I set up a cmd file to launch unison and scan the
folders.  It works reasonably well as I have added a delay to the launch
of unison, but a lot of unison windows pop up when there are a lot of
file changes.

On speaking to the developer of the app he suggested launching unison
with 'C:\Temp\Unison.exe C:\Temp\Unison %~p1 -batch'  this passes the
path of the changed file to unison.  I'm a little unsure if this is good
method and how to set it up properly, for example how would unison know
where to sync the file to?  his post (Werner) is here
http://www.brutaldev.com/post/2011/01/05/Directory-Monitor-20-Release-Ro
admap.aspx#id_544a7822-fa22-40e2-8654-da6ba1d0f3f9

So i'm wondering if anybody else has interest in this and if anybody can
figure out how to set up a working method.  The developer seems like a
very helpful chap so he may even be prepared to add extra features to
get this working flawlessly.

Thanks
Pad




------------------------------------

Yahoo! Groups Links

Hello,

I'm brand new to Unison, though I've been using a similar program called SyncToy
on Windows for a number of years.  I've installed Unison on a Mac with OS X 10.6
(Snow Leopard).  The first thing I did in Unison was create a new Profile to
define a pair of folders to be synchronized.  I needed to exclude certain files,
so I used the Ignore feature for that.  Unfortunately I accidentally ignored
something I didn't mean to ignore, and now I can't get it back.  I don't see a
way to view what is ignored and remove things from the ignore list.  I
considered deleting the profile and creating it from scratch again, but I'm not
seeing a way to do that either.  In my opinion, that should definitely be a
feature in the UI.  I've searched for the ".unison" folder to see if I could
perhaps manually modify the profile file and get rid of the invalid ignore
entry, but I can't find the folder nor any files with .prf extensions.  I've got
hidden files set to be visible in Finder (I see plenty of files and folders that
begin with periods), but I just don't see .unison anywhere.  I'd really like to
be able to delete or edit my profile(s)... any suggestions?

Thanks,
Torrey

On 27 oct. 2011, at 18:55, Torrey Jones <torrey@...> wrote:

> Hello,
>
> I'm brand new to Unison, though I've been using a similar program called
SyncToy on Windows for a number of years.  I've installed Unison on a Mac with
OS X 10.6 (Snow Leopard).  The first thing I did in Unison was create a new
Profile to define a pair of folders to be synchronized.  I needed to exclude
certain files, so I used the Ignore feature for that.  Unfortunately I
accidentally ignored something I didn't mean to ignore, and now I can't get it
back.  I don't see a way to view what is ignored and remove things from the
ignore list.  I considered deleting the profile and creating it from scratch
again, but I'm not seeing a way to do that either.  In my opinion, that should
definitely be a feature in the UI.  I've searched for the ".unison" folder to
see if I could perhaps manually modify the profile file and get rid of the
invalid ignore entry, but I can't find the folder nor any files with .prf
extensions.  I've got hidden files set to be visible in Finder (I see plenty
>  of files and folders that begin with periods), but I just don't see .unison
anywhere.  I'd really like to be able to delete or edit my profile(s)... any
suggestions?

You should find the profile, which you will be able to edit, in the folder
Library/Application Support/Unison.

Hope this helps,

Alan