On FreeBSD (v6 and v7), rsync (v3.0.4) with the extented ACLs patch has a problem. The ACLs flag works, but when it is used, the mtime of the files on on the receiving system are set to the current time. This is a bit annoying in itself, but creates a larger problem because any later rsync actions on the same files see the files as _different_, meaning that _all_ the files are recopied -- which more or less defeats the purpose of using rsync. Yes, I understand that setting ACLs on a file changes the mtime of the file. But, as rsync is able to (re)set mtimes I would think that this shouldn't should be an issue when using rsync. After some searching around, I found some discussion (relating to Macs, actually) that suggests that the problem is that with the ACLs patch enabled, rsync modifies the ACLs on the target files _after_ setting the mtime, which seems to me (at least) to be a bug.
Do you mean the fileflags.diff patch? ACLs are supported by default these days, though there is also an acls.diff patch that adds a backward-compatible mode for interfacing with rsync versions prior to 3.0.0.
It doesn't seem to matter whether it is default or backward-compatible. The problem is not with the setting of ACLs itself, but that setting ACLs changes the new file's mtime. If I rsync (-avxHA) the dir 'gbyshenk' to the new dir 'gbyshenk_acl', it works, and the ACLs are copied. But it seems that the mtime has been changed to now ('now' being the time the rsync was run). This is a problem in and of itself, but also creates a new problem, in that, if I then re-run rsync, it sees the new files as different than the old files, and proceeds to copy _everything_ again, rather than only the new/changed files. If I run rsync (-avxH -- _without_ the -A flag), then rsync behaves as it should.
This is a bug/misfeature in the FreeBSD ACLs->UFS2 code. Here is a bit of more discussion about it: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125739 In general, it should be fixed on a FreeBSD side, but, possibly, rsync can work around it too.
Timur is correct, of course. My apologies; when I raised this earlier I was advised that it looked to be an 'rsync' problem and I should file the bug here. Robert Watson has provided some patches to the FreeBSD ffs code that appear to solve the more general problem, as well as the reported rsync problem. (I am guessing that 'invalid' is the proper resolution code for this 'bug'.)