also sprach martin f krafft <[EMAIL PROTECTED]> [2008.06.24.0119 +0200]:
> ACLs not supported by filesystem at /
> escape_dos_devices not required by filesystem at /
> -----------------------------------------------------------------
> Detected abilities for source (read only) file system:
>   Access control lists                         Off
>   Extended attributes                          On
>   Case sensitivity                             On
>   Escape DOS devices                           Off
>   Mac OS X style resource forks                Off
>   Mac OS X Finder information                  Off
> -----------------------------------------------------------------

Thanks to Micah for spotting that rdiff-backup seems to insist that
the source also supports ACLs in /.

In fact, if I turn on ACL support for /, the problem goes away.

So there are a number of problems:

> Fatal Error: --never-drop-acls specified, but ACL support missing
> from destination filesystem

First of all, that should be s/destination/source/

Second, I don't see a single reason why rdiff-backup should care
about /. I am asking it to recursively back up /, and /srv uses ACLs
all over the place. So either is should look everywhere, or nowhere
at all.

Third, I am asking it to --never-drop-acls, not to
--require-local-acls or even --backup-acls. --never-drop-acls is
defined as:

  Exit with error instead of dropping acls or acl  entries.
  Normally  this  may  happen (with  a warning) because the
  destination does not support them or because the relevant
  user/group names do not exist on the destination side.

To me, this means to exit with error if ACLs cannot be stored
remotely and would have to be dropped, not if there are no ACLs
defined for the source root.

If I ask it to back up a system without any ACLs and I specified
--never-drop-acls, then it should not exit with an error due to
ACLs, because there are no ACLs that could ever be dropped.

If, however, I asked it to back up a system with some ACLs and it
couldn't store those properly on the destination filesystem, *then*
it should raise hell!

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

Attachment: digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Reply via email to