Scott | 1 Sep 15:39 2002
Picon

Remote sync issue

I have been successful in syncing 2 networked Win OS computers, but having difficulty setting up, or understanding method, to sync with my internet hosted website.
 
I do know that the website is hosted on a Linux system, so not sure how unix (ssh or rsh) would play a role in this.
 
I have tried using ftp.remotehost as the server lookup directory... maybe I just don't get it.
 
Any step-by-step assistance would be great.
 
Thanks,
Scott
 
 


To unsubscribe from this group, send an email to:
unison-users-unsubscribe <at> onelist.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
gleb20020902 | 2 Sep 11:35 2002
Picon

disabling "rsync" in Windows XP

Hello!

I use unison in a Windows environment: Win2k domain and Win2k client 
(using network shares, not client-server)

When I tried to use it in Windows XP I started to get messages like:

Failed with exception Util.Transient("Error in renaming 
XXXXXXXXX.0.unison.tmp to
XXXXXXXXX:\nPermission denied [rename(XXXXXXXXX.0.unison.tmp)]")
Failed: Error in renaming XXXXXXXXX.0.unison.tmp to XXXXXXXXX:
Permission denied [rename(XXXXXXXXX.0.unison.tmp)]

I've never experienced these problems in Win2k.
After long investigation the only solution I found is to disable 
rsync (rsync = false) in unison profile.

It seems that winXP differs a lot from win2k in a way it works.
(Does anybody tried make folder read-only in winXP via explorer?)

Thanks!

alain cetre | 2 Sep 17:15 2002
Picon

The Archives are locked unison 2.9.1

When using unison 2.9.1 on linux redhat7.1 for simple local example a message appears :

- The archives are locked ... delete file lk.....etc

Nevertheless none other unison session have been executed and no lock files exist in

the specified location.

This message appears only with a specific user (confmgr) and not with the root user.

The synchronisation is very simple, it is just a try between two directories /tmp/t1 and /tmp/t2.

Here is the result of unison -debug -all command

Thanks in advance for your answer

sscn2_confmgr /tmp/test % unison -debug -all t1 t2
Preferences:
ui = graphic
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = t2
rest = t1
contactquietly = false
key =
label =
expert = false
reusewindows = false
height = 20
batch = false
auto = false
backups = false
prefer =
force =
sortnewfirst = false
sortbysize = false
editor = emacs
merge2 =
merge =
diff = diff
verifyTransfers = false
statusdepth = 2
fastcheck = default
maxbackups = 2

rootsName =
root = t2
root = t1
killserver = false
rsync = true
addversionno = false
servercmd =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
pretendwin = false
times = false
group = false
owner = false
numericids = false
perms = 1023
ignorecase = false
timers = false
terse = false
logfile = /home/confmgr/unison.log
log = true
debugtimes = false
debug = -all
addprefsto =
Contacting server...
Roots:
        t2
        t1
  i.e.
        t2
        t1
  i.e. (in canonical order)
       /tmp/test/t1
       /tmp/test/t2

Looking for changes
Fatal error: Warning: the archives are locked.
If no other instance of unison is running, the locks should be removed.
The file /home/confmgr/.unison/lkb66c5a036c19c6cd4b06938f29f5935e on host sscn2
should be deleted
The file /home/confmgr/.unison/lk13c2aedfb353c436aeb72523ec3360ae on host sscn2
should be deleted


Yahoo! Mail -- Une adresse <at> yahoo.fr gratuite et en français !


To unsubscribe from this group, send an email to:
unison-users-unsubscribe <at> onelist.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Sebastien Routier | 5 Sep 00:13 2002

Problem merging !!

I get this error every time I try to merge two files !??!
 
------------------------------------------------- START PASTE -------------------------------------
Internal error: New archives are not identical.
Retaining original archives.  Please run Unison again to bring them up to date.
 
If you get this message repeatedly, please
   a) notify unison-help <at> cis.upenn.edu
  b) move the archive files (~/.unison/arNNNNN) on each      machine to some other directory (in case they may be
     useful for debugging)
  c) run unison again to synchronize from scratch.
------------------------------------------------- END PASTE -------------------------------------
 
Any ideas ?!?!
 

bye.
/Sebast


:
####[ Linux One Stanza Tip (LOST) ]###########################

Sub : Killing X Programmes (under KDE)               LOST #274

Stuck with a hung X programme under KDE ? Press these together
<Ctrl><Alt><Esc>, this will  change the cursor looking  like a
"death sentence" now point the cursor to the offending program
window and press the left mouse button to terminate it

####<ajitabhpandey <at> users.sourceforge.net>#####################
:

-----Original Message-----
From: alain cetre [mailto:xjrman2002 <at> yahoo.fr]
Sent: Monday, September 02, 2002 11:16 AM
To: unison-users <at> yahoogroups.com
Subject: [unison-users] The Archives are locked unison 2.9.1

When using unison 2.9.1 on linux redhat7.1 for simple local example a message appears :

- The archives are locked ... delete file lk.....etc

Nevertheless none other unison session have been executed and no lock files exist in

the specified location.

This message appears only with a specific user (confmgr) and not with the root user.

The synchronisation is very simple, it is just a try between two directories /tmp/t1 and /tmp/t2.

Here is the result of unison -debug -all command

Thanks in advance for your answer

sscn2_confmgr /tmp/test % unison -debug -all t1 t2
Preferences:
ui = graphic
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = false
testserver = false
rest = t2
rest = t1
contactquietly = false
key =
label =
expert = false
reusewindows = false
height = 20
batch = false
auto = false
backups = false
prefer =
force =
sortnewfirst = false
sortbysize = false
editor = emacs
merge2 =
merge =
diff = diff
verifyTransfers = false
statusdepth = 2
fastcheck = default
maxbackups = 2

rootsName =
root = t2
root = t1
killserver = false
rsync = true
addversionno = false
servercmd =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
pretendwin = false
times = false
group = false
owner = false
numericids = false
perms = 1023
ignorecase = false
timers = false
terse = false
logfile = /home/confmgr/unison.log
log = true
debugtimes = false
debug = -all
addprefsto =
Contacting server...
Roots:
        t2
        t1
  i.e.
        t2
        t1
  i.e. (in canonical order)
       /tmp/test/t1
       /tmp/test/t2

Looking for changes
Fatal error: Warning: the archives are locked.
If no other instance of unison is running, the locks should be removed.
The file /home/confmgr/.unison/lkb66c5a036c19c6cd4b06938f29f5935e on host sscn2
should be deleted
The file /home/confmgr/.unison/lk13c2aedfb353c436aeb72523ec3360ae on host sscn2
should be deleted


Yahoo! Mail -- Une adresse <at> yahoo.fr gratuite et en français !


To unsubscribe from this group, send an email to:
unison-users-unsubscribe <at> onelist.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


To unsubscribe from this group, send an email to:
unison-users-unsubscribe <at> onelist.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Benjamin C. Pierce | 5 Sep 20:27 2002

Re: Problem merging !!

> I get this error every time I try to merge two files !??!
> -------------------------------------
> Internal error: New archives are not identical.
> Retaining original archives.  Please run Unison again to bring them up to
> date.

There has been some discussion of this problem on the unison-hackers list
recently, but basically the status is that it seems to be happening quite
a bit "out in the field" but *doesn't* seem to happen to anybody who is
handy enough with looking through the sources to actually track down
where it is.  

     B

Matt Swift | 7 Sep 15:12 2002
Picon

Re: Problem merging !!


> There has been some discussion of this problem on the unison-hackers
> list recently, but basically the status is that it seems to be
> happening quite a bit "out in the field" but *doesn't* seem to
> happen to anybody who is handy enough with looking through the
> sources to actually track down where it is.

This problem used to happen to me occasionally; now it happens every
time I do a merge.

I have looked at the sources a bit with no luck so far.  I can
probably track the problem down if I get some help on the basics of
what Unison is trying to do and what a successful merge is supposed to
look like; while I understand them on the surface, the code, the
archives, the debugging msgs, and so on, don't mean much when I don't
have a technical grasp of Unison's larger concepts, architecture, etc.

I will try to join unison-hackers momentarily.  Meanwhile, here is a
tarball containing a very simple merge failure with full debugging.
Roots are ~/test on two machines (Linux and Cygwin); that dir contains
one file, "wombat", which I merged.  I include the files and archives
in an uptodate state, then again after altering the files and
attempting to merge them.  One thing that seems odd (but perhaps it is
entirely normal...) is that after the error I end up with *two*
archive files on each machine.  Also, if ~/unison.dump is an archive
file as the debug msgs say, why is it human readable when the ones in
~/.unison are not?

Luis Soltero | 9 Sep 09:24 2002
Picon

RH7.x woes...


Hello All,

I am trying to get unison 2.9.x running under RH 7.3.

Here are few comments maybe some one can help.

a) The dynamic version of the textual version of unison 2.9.1 and 2.9.2
core dump under RH 7.1 and RH 73.

b) The static version of the text version of unison runs ok for v 2.9.1

c) The static version of the textual version of unison returns the
following for version 2.9.2

Warning: 'uname' returned unrecognized result (Linux) in Util.isOSX.
I'll assume this is NOT an OSX machine.
unison version 2.9.20

I notice that uname returns "Linux" and unison wants "linux"...

So I decided to fix this in the sources...

After installing OCAM from the RH rpms. I do a make

I can trick unison into not displaying the mesg by replacing
the system uname with a script that echos "linux".

d) RH dynamic linked version of text-unison core dumps

e) RH static linked version of text-unison code dumps

g)  The static version of unison 2.9.2 downloaded from the upenn will not
run due to the version error...   When trying to copy between two
machines I get the following error

Fatal error: Received unexpected header from the server:
 expected "U" but received "W".
This is probably because you have different versions of Unison
installed on the client and server machines.

This problem is related to (c)

h) Since the statically distributed unison version 2.9.1 is the only thing
that
will work I have been using it for my testing and have run into a problem.

I have 3 machines which I want to keep in sync.  Two are on a fast LAN
the third is on a dialup connection.  I designate one of the LAN computers
as a Server and the other two clients.   I configure xinetd and tcpd to
run a chrooted unison -server on the clients.  I have created a shell
scrip on the server which in a loop first calls unison to sync the LAN
client and then the DIALUP client...

The file systems that are being synced are 12Mb and contain lots
of small files...

Here are some observations.

The LAN client-server interaction has not failed yet... It works
wonderfully.

The Dial-up connection has been problematic... On initial
replication of the file systems all goes well.  As long as
the transferred data is small the sync does fine. After a
while, especially after the transfer of a big file, the 
unison -server on the client side will "hang" after 
the sync has completed... As far as I can tell the unison -server
process does indeed complete and update all the files correctly
and then simply does not exit.  Killing this process and then
running unison again results in the file systems correctly syncing up.
but again the client unison process refuses to exit.

Running tcpdump on the ppp connection shows that
after the file transfers have completed the unison
process on the server side sends requests to
the unison process on the client side but never gets
replies.

I have set the "killserver" option on server side but to
no avail...

I am out of ideas.  Can any one out there offer any help?

Thanks,

--luis

alain cetre | 9 Sep 18:16 2002
Picon

Error in Deleting files unison 2.9.1

I'm using unison 2.9.1 with a linux redhat 7.1 and a NT4.0 machine.

I'm always using unison from Linux machine to NT using a -force option

with the socket method.

Changes made on source directory are well synchonized with target directory.

However when deleting files from target directory, unison tells me "Error in

deleting files, permission denied c:\tmp\.#<name of file>.0.unison.tmp"

Once i kill unison server in NT machine and start it again, everything works

fine 'till the next time. My solution, for instance, is to use a -killserver option

and restart the server on PC just after.

Is there anything to do instead of this solution which not very safe and proper ???

Thanks in advance

Al


Yahoo! Mail -- Une adresse <at> yahoo.fr gratuite et en français !


To unsubscribe from this group, send an email to:
unison-users-unsubscribe <at> onelist.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Luis Soltero | 10 Sep 08:38 2002
Picon

Dialup connection woes, was RH7.x woes...


Hello All,

A few days ago I posted a list of unison issues with RH 7.3..

Here is some addition information.

Firstly, I was able to get Unison 2.9.2 to compile on RH7.3
I had installed the wrong caml rpm. Note when installing
caml the RH version is important.   I was then able
to hack out the OSX testing routine that calls uname.

There are two problems with the routine... A) It
does not detect Linux correctly when evaluating
the output of uname.  B) when running from
a chrooted tcpd uname must be in the path
or unison fails to find it and yield a correct version 
number.  

After spending hours and hours in front of tcpdump
while transferring massive amounts of data over a
unison socket connection and a very slow dial up
line I can only conclude that there is
a timing bug in unison... After several 
megabytes of data transfer the unison -server
process reading from the socket simply stops
acking the requesting unison process.

This is a very reproducible result... It seems that
the slower the network runs the worse the problem
gets.. Once the unison -server process stops
acking the whole transfer halts and hangs 
indefinitely... Kill -TERM; rm .#*; restart is about
all you can do...  As I mentioned in my previous
posting faster networks do not seem to yield this
problem... I have the same setup running on a
10Mb ethernet, and a single channel 64KB ISDN
line and the transfers work fine.

The interesting thing is that the problem only happens
when using the socket:// transport... If you run
through a ssh tunnel the problem does not arise. It
seems that ssh is able to deal with tcp time out's and
protect the unison -server from them.

I have now set up a cipe tunnel between my systems
hoping that it will provide the same kind of time out
protection that ssh does while still providing the use
of the chrooted tcpd mechanism.

Will let you know what I find.

Thanks,

--luis

Laurent Gasnot | 10 Sep 14:56 2002

error on a Sun ultr10 solaris 7

Hello,

i'm very interesting in Unisson but unfortunatly it don't working on my 
Sun ultra10 under solaris 7.
I has downloaded the binaries for solaris and try to run them (text and 
gui) and i get always the same error: Uncaught exception Sys_blocked_io

thank you for your help

--

-- 
Laurent Gasnot  - Production Systems and Applications Administrator -
> PROLIGO S.A.S.
> 1, rue Delaunay  75011 Paris
> Phone: +33 1 43 56 59 19  mailto:Laurent.Gasnot <at> proligo.com
> Fax:   +33 1 43 56 59 49  http://www.gensetoligos.com/


Gmane