Cygwin/rsync/ssh automation problems
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
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:
>>>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.
>>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
More information about the rsync