summary
===========

when an acl that sets default permissions is configured on the receiving side of an rsync transmission, those permissions get overruled by explicitly applying the umask to the mode of a newly created file instead of letting the os figure out how to set the modes. (having the operating system evaluating it is the usual way umask, and is compatible with acls).

example
=========

in the following example, it is assumed that umask is 022 and that /tmp is mounted -oacl.

* mkdir and cd to /tmp/dest, do `setfacl -dm g::rwx .`
* `mkdir test` will create a 775 directory, as would be expected due to the configured acl. the syscall issued is `mkdir("test3", 0777)`.
* at /tmp/src, `mkdir test2`. its permissions don't matter as we won't send them.
* there, `rsync -r . /tmp/dest`. the syscalls issued are `mkdir("test2", 0700)`, `chmod("test2", 0755)`.

as a result, /tmp/dest/test2 is 0755 instead of 0777 as seen in /tmp/dest/test.

explanation of current behavior and suggestions
==============================================

the "create restrictive, then chmod" approach is reasonable when syncing with --perms in situations where data is created in 0000 directories (data inside gets created, and the directory is then set 0000). it is also reasonable then and with --chmod because any default permissions are meant to be overridden.

if neither --chmod nor --perms is given, the behavior should be altered to create directories 0777 (as it is done by mkdir) and rely on the operating system for interpreting umask, which can then apply other defaults too. situations like files in 0000 directories can then not occur at all unless the umask is set extremely restrictively (eg 0777), in which case whoever set the umask hopefully knew what that does and might even expect things not to work.

(part of this was developed together with BasketCase on freenode/#rsync).

further reference
=============

this problem was discovered in the context of git-annex at <http://git-annex.branchable.com/bugs/acl_not_honoured_in_rsync_remote/>. a similar problem is present in `mkdir -p` as described in <http://savannah.gnu.org/bugs/?19546>; there, it was not fixed but is just being worked around, as mkdir tries to strictly implement a posix spec that was written before acls were created, and prescribes explicitly applying a umask.