rsync -e ssh does not work well
Kauko.Heikkila at helsinki.fi
Fri Oct 25 13:36:01 EST 2002
Thank you for the explanations.
I start to understand a bit more.
In my case uname-html is then a "module"
pointing to public_html directory of the user
uname. With ssh I can then use the
uname at servername:public_html/
instead of the module name
uname at servername::uname-html
And I agree that scripts can be edited as you say.
Problem number one is handled.
One more, serious problem exists, since
when invoked from a w2000 laptop
(servername is still the same SuSe Linux server)
rsync -trvuz file.wrk uname at servername::uname-html
rsync -trvuz -e ssh file.wrk
uname at servername:public_html/
It again gives an error, twice the line
"unexpected EOF in read_timeout"
This is serious from point of view of the whole project,
since the client side is as essential.
----- Original Message -----
From: "jw schultz" <jw at pegasys.ws>
To: <rsync at lists.samba.org>
Sent: Friday, October 25, 2002 2:23 PM
Subject: Re: rsync -e ssh does not work well
> On Fri, Oct 25, 2002 at 12:38:03PM +0300, Kauko Heikkila
> > Thanks for the answer. I fully appreciate.
> > And in a way I admit what you said,
> > but if you think of the command
> > rsync -trvuz file.wrk uname at servername::uname-html
> > what it does, then according to my logic
> > rsync -trvuz -e ssh file.wrk
uname at servername:uname-html
> > should do exactly the same thing. Another thing would
> > to say, that it originally is not realizable in this
> > way....
> > and why not?
> Because they don't say the same thing. in
> uname at servername::uname-html uname-html is a module
> is explicitly defined as mapping to a directory. But in
> uname at servername:uname-html uname-html is just an
> specification of a path, in this case relative to the
> directory of the user uname.
> rsync needs to be able to sync a file with a file just
> cp. This particular behavior is used quite frequently by
> people who explicitly rsync one file at a time inside
> scripts. The difference is that unlike cp rsync needs to
> behave deterministically. The result needs to be the
> regardless of what exists at the destination prior to
> The use of a trailing slash on a destination is a
> unix notation for "don't name it this but put it in the
> specified directory". That rsync supports this is to be
> expected and is much better than having to add an option.
> When you resync and the source has replaced a
> directory with a file rsync needs to delete the directory
> the destination and copy the file that now exists on the
> source location.
> > Otherwise there is reconsideration of my perl
> > procedures not made by me. And same with the
> > that should only be known at the server side, not the
> > client
> > side, according to my logic. Perhaps I am wrong again,
> > but currently cannot understand why I should tell all
> > clients if I want to change something in
> > the server. Using rsync again for this purpose,
> > -All right, adding symbolic links to Linux and slashes
> > to the procedures.
> > But it is not that beautiful any more....-
> > I might do that, but currently I am not contented with
> > nonsymmetric behaviour of rsync....I will start
> > port forwarding soon......and use rsync in that way if
> > helps....
> The semantics of syncing with an rsync daemon vs. local
> remote shell are very different such that the first path
> element given to the daemon is a module name, not a
> directory. A destination of
> uname at servername::modname/uname-html should have the same
> behavior pattern as uname at servername:uname-html
> It is a unclear to me what symlinks have to do with
> this. As for slashes, if a script breaks because of an
> unanticipated issue it needs to be updated.
> Most people scripting this would actually invoke it with
> rsync -trvuz -e ssh $srcdir/$file
> eliminating any ambiguity.
> J.W. Schultz Pegasystems Technologies
> email address: jw at pegasys.ws
> Remember Cernan and Schmitt
> To unsubscribe or change options:
> Before posting, read:
More information about the rsync