CentOS - Sep 2011 - rsync -x does not do the same on EL 5.6 and 5.7

Hi,

We re doing backups of all filesystems to a dedicated server using "rsync
-x". Now, the latest CentOS versions (5.7/6.x) come with rsync-3.0.6
instead of rsync-2.x. That's nice but unfortunately it doesn't do the
same
as 2.x in certain situations.

The problem is with the -x option, which does not delete content under a
mount point anymore. It was my impression that this is a bug, but I've
been told it's a feature. The problem has shown up after I have added a
new mount point on a server.

I've added a BZ for RedHat and also posted to the rsync list as below:

https://bugzilla.redhat.com/show_bug.cgi?id=735981

https://lists.samba.org/archive/rsync/2011-September/026766.html

Am I really the only one having problems with the new behaviour? It
affects all user running "rsync -x". The problem only shows up after
new
mount points have been added to a subdirectory which is processed by rsync
-x. That may be the reason why not many people relize it. Still, I don't
see the logic behind the change which is why I take this here to hear what
others think.

Thanks,
Simon

Le jeu 08 sep 2011 08:32:20 CEST, Simon Matter a ?crit:
> Hi,
> 
> We re doing backups of all filesystems to a dedicated server using
"rsync
> -x". Now, the latest CentOS versions (5.7/6.x) come with rsync-3.0.6
> instead of rsync-2.x. That's nice but unfortunately it doesn't do
the same
> as 2.x in certain situations.
> 
> The problem is with the -x option, which does not delete content under a
> mount point anymore. It was my impression that this is a bug, but I've
> been told it's a feature. The problem has shown up after I have added a
> new mount point on a server.
> 
> I've added a BZ for RedHat and also posted to the rsync list as below:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=735981
> 
> https://lists.samba.org/archive/rsync/2011-September/026766.html
> 
> Am I really the only one having problems with the new behaviour? It
> affects all user running "rsync -x". The problem only shows up
after new
> mount points have been added to a subdirectory which is processed by rsync
> -x. That may be the reason why not many people relize it. Still, I
don't
> see the logic behind the change which is why I take this here to hear what
> others think.
This is not the only difference between rsync-2.x and 3.x.

We are doing
rsync -azX --delete-after etc...
and it fails with rsync-3.

On the server (still running rsync-2), /var/log/secure shows the 
difference (sorry for the long lines).
From a rsync-2 client, we receive :
Sep  7 12:35:01 lasbHOME scponly[6166]: running: /usr/bin/rsync --server
-lXogDtprz --delete --delete-after etc...
From a rsync-3 client, it turns to :
Sep  7 20:35:01 lasbHOME scponly[12764]: option 'e' or a related long
option is not permitted for use with /usr/bin/rsync (arg was .is)
Sep  7 20:35:01 lasbHOME scponly[12764]: requested command (/usr/bin/rsync
--server -logDtpXrze.is --delete-after etc...) tried to use disallowed argument

As I don't have the time to make more trials, I simply downgraded to 
rsync-2.

-- 
Philippe Naudin
UMR MISTEA : Math?matiques, Informatique et STatistique pour 
l'Environnement et l'Agronomie
INRA, b?timent 29   -   2 place Viala   -   34060 Montpellier cedex 2
t?l: 04.99.61.26.34, fax: 04.99.61.29.03, m?l: naudin at supagro.inra.fr