Pádraig, thanks for looking into this.
2015-06-30 14:32 GMT+02:00 Pádraig Brady <[email protected]>: > The crux of the patch is to set the acl_no_supported flag > when getting permissions and get such an errno. That's not how this should work; the flag is there for set_permissions internal use. The source and target file may have different kinds of acl support. In get_permissions, when acls are not supported, only ctx->mode should be set. In set_permissions, we try to set_acls the first time. If that fails, set_acls sets the acls_not_supported flag. It is then retried and the flag tells it to try setting the acls based on ctx->mode. This is needed on systems which support different kinds of acls on different file systems. Whether failing to set an acl is an error or not depends on the acl: if the acl is equivalent to the file mode, we can just do a chmod instead; otherwise, we are losing information, and we need to tell the user. See the "nontrivial" functions in the code. I've tried to get a recent version of Solaris running inside qemu/kvm so I can debug these problems myself, unfortunately with no luck. I haven't had time to try FreeBSD yet. > Also I've reinstated the acl_from_mode() replacement > in set-permissions.c which was ignored due to defines in acl-internal.h Hmm, what's using that? It can't be set_permissions: that still errors out when HAVE_ACL_FROM_TEXT isn't defined, which is when rpl_acl_from_mode is defined. acl_from_mode() cannot fail because of lack of acl support on a file system, it doesn't access the file system. It shouldn't affect the acls_not_supported flag. Thanks, Andreas
