Hello,
I am trying to use ACL and link-dest without success.
Here is what I do.
First step, without ACL :
rsync -ai --link-dest=<date_folder_1> --link-dest=<date_folder_2> /sourcedir myserver::backup/$(date)/
All works fine here, my files are hard linked together, "ls -li" on myserver confirms.
Second step, adding ACL :
rsync -aiA --link-dest=<date_folder_1> --link-dest=<date_folder_2> /sourcedir myserver::backup/$(date)/
Each time I run this command, rsync itemizes an ACL change for each file, for example :
cf.......a. d/Users/Users.txt
However, nothing has changed on the source.
On myserver, "ls -li" confirms that my files are no more hard linked together.
As my rsync daemon has "fake super = yes", I run "getfattr -d" on my files to compare attributes : same files from differents date_folders have exactly the same attributes' values (user.rsync.%stat and user.rsync.%aacl).
Seems that --acls is not --fake-super aware.
Thank you very much for your support !
Best regards,
Ben

Note that --fake-super puts things into xattrs, not into ACLs. However, it will indeed put any preserved ACL info into an xattr rather than setting actual ACLs on a file. That's --fake-super's purpose -- to make backups of files without needing to be root. It is therefore not a bug that rsync doesn't hard-link a non --fake-super file to a --fake-super file, since the two files are very different (and rsync can only hard-link together identical files).
So, you should be using getfacl -d to see what is different, not getfattr.

Hello,
Thank you for your help !
Of course yes, here is a "script" to reproduce the problem :
# Source and destination :
# Init some vars
DEST_SRV=mytestserver.com
DEST_USR=bob #must not be root
DEST_DIR=/home/test #must be mounted with user_xattr
# Source :
# First let's make some test files
# These files will never change during our tests, to let Rsync hard link them together !
cd /tmp
mkdir rsynctest
echo file1 > rsynctest/file1
echo file2 > rsynctest/file2
# Source :
# First Rsync to the destination
rsync -a --rsync-path="rsync --fake-super" rsynctest/ $DEST_USR@$DEST_SRV:$DEST_DIR/rsynctest1
# Source :
# Let's link-dest previous Rsync, without ACL, to see if files are linked together (they should be)
rsync -a --rsync-path="rsync --fake-super" --link-dest="$DEST_DIR/rsynctest1/" rsynctest/ $DEST_USR@$DEST_SRV:$DEST_DIR/rsynctest2
# Destination :
# Let's find out, on the destination, do the following to confirm links :
ls -li $DEST_DIR/rsynctest1
ls -li $DEST_DIR/rsynctest2
# Destination :
# In addition, on the destination, do the following to confirm that extended attributes have been set by fake-super (user.rsync.%stat) :
getfattr -d -m - $DEST_DIR/rsynctest1/*
getfattr -d -m - $DEST_DIR/rsynctest2/*
###### So great, all works fine without ACL
###### So let's go with ACL
# Source :
# First Rsync to the destination
rsync -aA --rsync-path="rsync --fake-super" rsynctest/ $DEST_USR@$DEST_SRV:$DEST_DIR/rsynctest3
# Source :
# Let's link-dest previous Rsync, with ACL, to see if files are linked together (they should be)
rsync -aA --rsync-path="rsync --fake-super" --link-dest="$DEST_DIR/rsynctest3/" rsynctest/ $DEST_USR@$DEST_SRV:$DEST_DIR/rsynctest4
# Destination :
# Let's find out, on the destination, do the following, and you will see that files are not hard linked together :
ls -li $DEST_DIR/rsynctest3
ls -li $DEST_DIR/rsynctest4
# Destination :
# In addition, on the destination, do the following to confirm that extended attributes have been set by fake-super (user.rsync.%stat AND user.rsync.%aacl) and are exactly the same between the 2 Rsync (of course yes) :
getfattr -d -m - $DEST_DIR/rsynctest3/*
getfattr -d -m - $DEST_DIR/rsynctest4/*
###### So using -A, files are not linked as they should be.
###### Seems that fake-super is not --acls aware.

I've fixed this in the git repository for the 3.1.0 release.
The function that was reading the ACL values from the xattr wasn't translating NO_ENTRY values into real permission bits (based on the file's mode), which caused an ACL to be abbreviated where that is not supported.

Hello Wayne !
Great news, thank you very much for your support !
I am not really sure about rsync 3.1.0 roadmap, and as I use rsync in a production environment, could it be possible to have the modifications you did through a 3.0.8 patch please ?
It could be perfect !
Thank you very much,
Best regards,
Ben