Cygwin/rsync/ssh automation problems

Paul Thompson captbunzo at squirrelmail.org
Sat Oct 4 16:18:52 EST 2003


JW, Mr. Shultz, whatever you prefer -

Thanks for the great advice. Looks like I am going to become a unison 
user. :)

Paul

jw schultz wrote:

>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.
>
>
>  
>





More information about the rsync mailing list