[CentOS] rsync versioning problem

Fri Aug 3 16:27:04 UTC 2018
Robert Moskowitz <rgm at htt-consult.com>

Warren, Thanks!

On 08/03/2018 12:17 PM, Warren Young wrote:
> On Aug 3, 2018, at 9:59 AM, Robert Moskowitz <rgm at htt-consult.com> wrote:
>>> You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default.  It was released in 2004.
>> How do I specify -p and -l that I cut out of my example?
> Add it to ~/.ssh/config:
>      Host nevia.htt-consult.com
>          Port 2222
>          User rmoskowitz

I will look into this and rtfm  :)

I have been doing this for so long, I never paid attention to the 
change.  The man pages I originally used said to use -e ssh

> You might not think of rsync as paying attention to this file, which is correct, because it doesn’t.  But since it is executing ssh under the hood, and ssh *does* pay attention to that file, it takes effect.
> If you’re creating that file for the first time, be sure to chmod 600 it.  Ssh will ignore it if it’s not locked-down.  RTFM for details.

And then still ask Dr. Google.  Page's father WAS one of my profs at MSU.

>>>> /var/flexshare/shares x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
>>> Rsync won’t create multiple levels of directories on the target.  It will only create up to one level of missing directories.  Try this:
>>>      $ ssh x.htt-consult.com 'mkdir -p /media/backup/homebase/var/flexshare/shares/'
>> Oh?  I have been doing this in one shape or form for a long time.
> Let me clarify:
> If only /media/backup exists on the remote machine, I believe you’ll end up with /media/backup/shares with that command.
> If at least /media/backup/homebase/var/flexshare exists, rsync will always create “shares” under “flexshare" on the remote host.
> Anything below that level will also be created, regardless of depth.  I’m speaking only of the target path given as the last argument to rsync here, not of the source machine’s directories discovered during the sync process.
> It’s possible this behavior changed since I last looked at it.  I ran into this issue many years ago and now ensure that the target path passed to the rsync command exists on the remote host before starting the sync.

Always a challenge to get this right and get the right behavior.  I use 
rsync for backing up my data from my notebook to a USB drive. Also when 
I was active in IEEE 802, at the meetings I could rsync all the 
documents off the local server.  The public server does not support 
rsync.  Plus I rsync all the IETF RFCs and drafts every night.

So I have a lot of old habits.