rsync -e ssh does not work well

[jw schultz]

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