rsync - Dec 2009 - Option to create ancestors of destination, like "mkdir -p

> I agree with everyone else that it would be incredibly useful for rsync to
> either adopt such behaviour by default (assuming always doing 'mkdir
-p' isn't
> harmful in any way), or have a tunable to enable it.
I also agree the suggested behavior makes a lot of sense and I think it is a
good idea.

However, some deployments may rely upon the current behavior.  As an example, a
setup may rely on rsync failing if a file system is not mounted.  In such a
situation, it is worth contemplating whether you would you want rsync to
generate the mount point and any subdirectories, specified for this rsync.

I personally think that such checks should be external from rsync. However,
changing the current default behavior has the potential to create problems on
setups which may rely on the current default behavior.

I recommend the consideration of potential problems which could occur if the
deployed setups are dependent on the current rsync behavior and that default
behavior changes. Then based upon the severity of these potential problems move
ahead or delay the change to a major revision change?

My 2?

>> > I agree with everyone else that it would be incredibly useful for
rsync to
>> > either adopt such behaviour by default (assuming always doing
'mkdir -p' isn't
>> > harmful in any way), or have a tunable to enable it.
>> 
>> I also agree the suggested behavior makes a lot of sense and I think it
is a good idea.
>> 
>> However, some deployments may rely upon the current behavior.  As an
example, a setup may rely on rsync failing if a file system is not mounted.  In
such a situation, it is worth contemplating whether you would you want rsync to
generate the mount point and any subdirectories, specified for this rsync.
>> 
>> I personally think that such checks should be external from rsync.
However, changing the current default behavior has the potential to create
problems on setups which may rely on the current default behavior.
>> 
>> I recommend the consideration of potential problems which could occur
if the deployed setups are dependent on the current rsync behavior and that
default behavior changes. Then based upon the severity of these potential
problems move ahead or delay the change to a major revision change?
> 
> #!/bin/sh
> #backup friday
> #"Spinning up backup drive and mounting it .."
> cd /
> mount /mnt/hd2
> #"Starting backup procedures"
> rsync -avx --exclude="/home/gary/.thumbnails/"
> --exclude="/home/gary/tmp/" --delete --ignore-errors /home/gary
> /mnt/hd2/2010
> umount /mnt/hd2
> #END
The quoted script above is from another thread which was just posted to the
rsync mailing list : <http://www.mail-archive.com/rsync at
lists.samba.org/msg25132.html>

This script above is a good example of the potential problems with making
'mkdir -p' the default. I agree that this feature is the way to move
forward. However, changing the default behavior may cause potential issues for
various scripts.

I have no idea how many scripts are there like this, which could potentially
start start backing up to the wrong file system if the drive is not successfully
mounted.

I suggest considering these potential issues and suggest that leaving such a
change to the next major release is seriously considered.

my 4?


---------------------------------------------------------------------
 This email is protected by LBackup, an open source backup solution. 
      Free as in freedom; LBackup is licensed under the GNU GPL
              Download LBackup now : http://www.lbackup.org
---------------------------------------------------------------------