On Tue 29 Jun 2010, Filipus Klutiero wrote:
>
> Trying to use --delete with a rsync 3.0.3 receiver resulted in this:
>
> $ rsync -r -n -t -v --progress --delete /etc/
> r...@andrea:/mnt/backup/vinci/etc/
> r...@andrea's password:
> sending incremental file list
> rsync: opendir "/etc/atheme" failed: Permission denied (13)
> FATAL I/O ERROR: dying to avoid a --delete-during issue with a
> pre-3.0.7 receiver.
> rsync error: requested action not supported (code 4) at
> flist.c(1795) [sender=3.0.7]
> chea...@vinci:/etc/apache2$
>
> --delete-during was, as you can see, not requested.
>From the manpage:
...
Some options require rsync to know the full file list, so these
options disable the incremental recursion mode. These include:
--delete-before, --delete-after, --prune-empty-dirs, and
--delay-updates. Because of this, the default delete mode when
^^^^^^^^^^^^^^^^^^^^^^^
you specify --delete is now --delete-during when both ends of
^^^^^^^^^^^^^^^^^^^^^^
the connection are at least 3.0.0 (use --del or --delete-during
to request this improved deletion mode explicitly). See also
the --delete-delay option that is a better choice than using
--delete-after.
The process commits suicide because the directory /etc/atheme is not
readable, so rsync can't check what files to delete (or rather: what
files _not_ to delete).
Either exclude the unreadable directory/ies or don't specify --delete
to work around this. Or run the transfer as root so that all files can
be sync'ed.
Paul
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
