rsync -e ssh does not work well

[Kauko Heikkila]

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
directory name
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
works, but
rsync -trvuz  -e ssh  file.wrk
uname at servername:public_html/
does not.

It again gives an error, twice the line
"unexpected EOF in read_timeout"
as before.

This is serious from point of view of the whole project,
since the client side is as essential.

sincerely
Kauko

----- 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
wrote:
> > 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
be
> > 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
which
> is explicitly defined as mapping to a directory.  But in
> uname at servername:uname-html uname-html is just an
ambiguous
> specification of a path, in this case relative to the
home
> directory of the user uname.
>
> rsync needs to be able to sync a file with a file just
like
> 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
same
> regardless of what exists at the destination prior to
> execution.
>
> The use of a trailing slash on a destination is a
standard
> 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
on
> 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
directories
> > 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
the
> > clients if I want to change something in
> > the server. Using rsync again for this purpose,
perhaps.
> > -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
the
> > nonsymmetric behaviour of rsync....I will start
studying
> > port forwarding soon......and use rsync in that way if
it
> > helps....
>
> The semantics of syncing with an rsync daemon vs. local
or
> 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
$user\@$server:$destdir/$file
> eliminating any ambiguity.
>
>
> --
>
___________________________________________________________
_____
> J.W. Schultz            Pegasystems Technologies
> email address: jw at pegasys.ws
>
> Remember Cernan and Schmitt
> --
> To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read:
http://www.tuxedo.org/~esr/faqs/smart-questions.html
>