Cygwin/rsync/ssh automation problems

[jw schultz]

On Fri, Oct 03, 2003 at 11:50:45AM -0500, Paul Thompson wrote:
> Olivier Kaloudoff wrote:
> 
> >On Thu, 2 Oct 2003, Josh Endries wrote:
> > 
> >
> >To synchronise files between Windows and unix, you might
> >take a look at Unison: 
> >
> >http://www.cis.upenn.edu/~bcpierce/unison/
> >
> >Unison is a file-synchronization tool for Unix and Windows. (It also works 
> >on OSX to some extent, but it does not yet deal with 'resource forks' 
> >correctly; more information on OSX usage can be found on the unison-users 
> >mailing list archives.) It allows two replicas of a collection of files 
> >and directories to be stored on different hosts (or different disks on the 
> >same host), modified separately, and then brought up to date by 
> >propagating the changes in each replica to the other.
> >
> >Olivier
> >
> 
> Oliver,
> 
> Thanks for your post. I was looking for exactly such a tool yesterday 
> and stumbled across drsync and unison. I chose to go with drsync, 
> because for some reason I felt more secure with a tool that was built on 
> rsync then a new creation completely, which is what unison appears to be.

I can understand that logic but i'm not so sure it applies
in this case.

> Can you give me much input on the two tools and your thoughts about why 
> one (drsync or unison) would be a better choice then the other for 
> unix/windows, etc, syncronization?

This is the first i've heard of drsync.  I took a quick look
and it appears to be a perl wrapper for rsync.  I can think
of several problems with that approach.

I've note looked at drsync's logic so i will assume the best
of it but it.  To do bi-directional syncing you need to
maintain meta-data of the last synchronised state and compare
that meta-data against the local files to create an action
list (so to speak) completely outside of rsync.  You will
then need to perform deletes outside of rsync, which is
fine, and then run rsync's each way.  This means that you
will have at least two rsync invocations plus some sort of
communication between the to locales.  Unless drsync depends
on a fairly recent (unreleased) rsync build from CVS the
file list for action will have to be either passed on the
command line or a complicated --include-from pattern set be
built.  Depending on the length of the file-list and the
approach used each direction may well be multiple rsync
runs.  The simplest approach could run literally hundreds
but i hope that isn't the case.

The reason why i stress the number of rsync invocations is
that rsync has a stubborn intermittent hanging problem
interacting with ssh on cygwin.  Every rsync invocation runs
the risk of hanging.  So even if drsync is terrific, i'd
avoid it on cygwin.  Craig Barrett (sorry if misspelt) has a
patch that apparently reduces the cygwin hang but as of his
last related posting here does not completely eliminate it.

I don't know if unison has a hanging problem on cygwin but
i've not heard about one and i suspect that if there was
such a problem it would have been spoken of on the rsync
list given how often unison gets mentioned here.  Unison is
built on the "rsync" algorithm.  I've been using it for
about a year (Linux only) and i know several other rsync
maintainers and other list contributors also use it.  It is
a very good tool.  One of the nice things about FLOSS is
that most of us would rather you used the best tool for the
job even if that means you don't use ours.  For
uni-directional stateless synchronisation use rsync, for
bi-directional statefull synchronisation use unison.  I'm
not far from suggesting that even for uni-directional
syncing on cygwin over ssh it might be safer to use unison.

> Just for the record and a complete picture, I am planning on keeping two 
> windows boxes syncronized by using a linux box as an in between. One 
> windows box is at home behind a cable modem. The other is at work behind 
> a corporate firewall. The linux box is just an independant server 
> sitting out on the net.
> 
> I assume with either of the tools, I would just independantly syncronize 
> between each of the windows boxes and the linux box, which would 
> effectively syncronize the windows boxes. I haven't thought real hard 
> about it, but I don't think that this should be a problem.

I think that assumption is correct.  I know it is with
unison.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt