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 there, 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). So why Rsync does not hard link them ? Env : Source : Rsync 3.0.8 / Cygwin 1.7 / NTFS Destination : Rsync 3.0.8 / Debian 6 / ext4 with user_xattr Thank you very much ! Best regards, Ben
On Sun, 08 May 2011 18:21:23 +0200, AZ 9901 wrote: [...]> So why Rsync does not hard link them ?If I understand what you're asking correctly, you've two files that are identical but for the ACLs which are different. You're asking why these two files aren't hard-linked? The answer is that the ACL - at least as far as file systems I've seen - is on the inode, not the directory entry which refers to an inode. Therefore, if you've two files hard-linked to one another, they must share the same ACL. The act of changing the ACL requires rsync to make a second copy. Happily, it seems that rsync is sufficiently smart to make the copy at the destination end of the copy. That is, it doesn't bother to transfer the file since the file's content is already at the destination. It merely creates the required new copy and then changes the new copy's ACL. Does this help you? - Andrew
I mean completely unchanged : file content, access rights, ACL... nothing changed at all. It looks like rsync does not go into xattr attributes to see if ACL already exists and is the same, so thinks that the file is different and re-create it. If you do the test I give in my bug report, executing rsync without waiting between 2 runs, without touching your test files... so being sure files are not modified at all, you will see that they are not hard linked together. Comparing ACL on destination side will reveal that ACL are exactly the same. But files are not hard linked. Trying without -A (--acls) will hard link files together. https://bugzilla.samba.org/show_bug.cgi?id=8130 Ben Le 23 mai 2011 ? 21:07, Andrew Gideon a ?crit :> On Mon, 23 May 2011 19:45:57 +0200, AZ 9901 wrote: > >> Well, when using -A (--acls), same (unchanged) files between 2 rsync >> runs are not linked together. Removing -A (--acls) makes things fine, >> files are hard linked together. > > Where you write "unchanged", do you mean completely unchanged or do you > mean that nothing is changed but for an ACL, which is changed? > > If the latter, I believe that what you describe as occurring is the > expected behavior. > > - Andrew > -- > Please use reply-all for most replies to avoid omitting the mailing list. > To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Maybe Matching Threads
- [Bug 8130] New: ACL and link-dest do not work together
- directory, effect of recurse with ensure => directory
- Backup to NTFS USB drive --compare-dest not working
- DO NOT REPLY [Bug 5298] New: xattrs and acls do not work well together along with fake-super, even worse on XFS
- Specify Includes Only