Platform: HP-UX 11iv3 (11.31) on ia64 with vxfs/JFS and ACLs when trying to rsync files or dirs with more than 16 ACLs we get errors in the rsync-server logfile (used flags: -axA) 2010/12/08 09:40:06 [21974] rsync: get_acl: sys_acl_get_file(rsynctest/abc/123, ACL_TYPE_ACCESS): Invalid argument (22) 2010/12/08 09:41:00 [23863] rsync on patdb/rsynctest from xy123 (10.190.81.189) After changing INITIAL_ACL_SIZE to 128 (in both lines) in lib/sysacls.c the binary is able to rsync our ACL-topscorer with 115 ACLs. Maybe, someone can get the dynamic things using ACL_GET after ACL_CNT work correctly, after the initial ACL_GET using 16 as INITIAL_ACL_SIZE is not successfull.
result with standard rsync: files or dirs with more than 16 ACLs in source get no ACLs in destination
What we need to know is what part of the sys_acl_get_file() function for HPUX fails. It should call: acl_d = sys_acl_init(16); count = acl(path, ACL_GET, 16, &acl_d->acl[0]); If that fails (count < 0), is errno ENOSPC? If not, what is the errno? If errno is ENOSPC, it will call: sys_acl_free_acl(acl_d); count = acl(path, ACL_CNT, 0, NULL) If that fails (count < 0), what is the right call to find the count? If that succeeds, it calls: acl_d = sys_acl_init(count) count = acl(path, ACL_GET, count, &acl_d->acl[0]) That call should succeed. If it doesn't, what is the errno?
errno is 22 as you & we can see in different logfiles: rsync-patdb.log:2010/12/08 09:40:06 [21974] rsync: get_acl: sys_acl_get_file(rsynctest/abc/123, ACL_TYPE_ACCESS): Invalid argument (22) rsync-patdb.log:2010/12/08 09:41:01 [23863] rsync: get_acl: sys_acl_get_file(rsynctest/abc/123, ACL_TYPE_ACCESS): Invalid argument (22) rsync-patdb.log:2010/12/08 10:01:52 [11469] rsync: get_acl: sys_acl_get_file(rsynctest/abc/123, ACL_TYPE_ACCESS): Invalid argument (22) rsync-patdb.log:2010/12/08 10:04:31 [17760] rsync: get_acl: sys_acl_get_file(rsynctest/abc/123, ACL_TYPE_ACCESS): Invalid argument (22) rsync-patdb.log:2010/12/08 11:36:37 [15997] rsync: get_acl: sys_acl_get_file(rsynctest/abc/123, ACL_TYPE_ACCESS): Invalid argument (22) it happens in the call using get_acl errno 22 translates to: bysas8:root:include#grep "22" sys/errno.h|grep -v "22[0-9]" #define EINVAL 22 /* Invalid argument */ as you can see in the above excerpts from logfile
get_acl() is not a systemcall.
We're facing the same issue. Ran a gdb against latest rsync 3.1.0. Hopefully this helps, I'm not a C guru though. # getacl Save # file: Save # owner: 200 # group: 200 user::rwx user:201:rwx user:600:rwx group::r-x group:501:rwx mask::rwx other::r-x default:user::rwx default:user:200:rwx default:user:201:rwx default:user:600:rwx default:group::r-x default:group:200:rwx default:group:501:rwx default:mask::rwx default:other::r-x Breakpoint 2, sys_acl_get_file (path_p=0x7fffe620 "Save", type=1) at lib/sysacls.c:908 908 while ((count = acl(path_p, ACL_GET, count, &acl_d->acl[0])) < 0 && errno == ENOSPC) { (gdb) print count $1 = 16 (gdb) print ACL_GET $2 = 1 (gdb) print errno $3 = 22 (gdb) s 910 sys_acl_free_acl(acl_d); (gdb) s sys_acl_free_acl (acl_d=0x401272a0) at lib/sysacls.c:1541 1541 free(acl_d); (gdb) s 1542 return 0; (gdb) sys_acl_get_file (path_p=0x7fffe620 "Save", type=1) at lib/sysacls.c:912 912 if ((count = acl(path_p, ACL_CNT, 0, NULL)) < 0) { (gdb) print count $4 = -1 (gdb) print ACL_CNT $5 = 3 (gdb) s 913 return NULL; (gdb) sys_acl_set_file (name=0x7fffe620 "Save", type=0, acl_d=0x4012ca40) at lib/sysacls.c:1444 1444 if (tmp_acl == NULL) { (gdb) 1445 return -1; (gdb) s set_rsync_acl (fname=0x7fffe620 "Save", duo_item=0x4009f540, type=0, sxp=0x7fffdd40, mode=16893) at acls.c:1005 1005 rsyserr(FERROR_XFER, errno, "set_acl: sys_acl_set_file(%s, %s)", (gdb) bt #0 set_rsync_acl (fname=0x7fffe620 "Save", duo_item=0x4009f540, type=0, sxp=0x7fffdd40, mode=16893) at acls.c:1005 #1 0x40fd320:0 in set_acl (fname=0x7fffe620 "Save", file=0x4009f514, sxp=0x7fffdd40, new_mode=16893) at acls.c:1043 #2 0x405ccb0:0 in set_file_attrs (fname=0x7fffe620 "Save", file=0x4009f514, sxp=0x7fffdd40, fnamecmp=0x0, flags=0) at rsync.c:572 #3 0x4068a20:0 in recv_generator (fname=0x7fffe620 "Save", file=0x4009f514, ndx=2, itemizing=1, code=FLOG, f_out=7) at generator.c:1422 #4 0x406fb70:0 in generate_files (f_out=7, local_name=0x0) at generator.c:2213 #5 0x409c680:0 in do_recv (f_in=6, f_out=7, local_name=0x0) at main.c:945 #6 0x409e180:0 in client_run (f_in=8, f_out=7, pid=8869, argc=1, argv=0x400271e4) at main.c:1195 #7 0x409fa20:0 in start_client (argc=1, argv=0x400271e4) at main.c:1405 #8 0x40a1090:0 in main (argc=2, argv=0x400271e0) at main.c:1633 #9 0x200000007778cc60:0 in main_opd_entry+0x50 () from /usr/lib/hpux32/dld.so (gdb) cont Continuing. rsync: set_acl: sys_acl_set_file(Save, ACL_TYPE_ACCESS): Invalid argument (22)
While you didn't output errno after the failing acl() call, it appears that it returns 22 (EINVAL), which means that your OS doesn't like the args to that call. I googled a bit and saw some gnu code that was passing NACLENTRIES to the function instead of 0 (which looks like it is defined in sys/acl.h on some systems). I'm going to change that call to use NACLENTRIES and also define that value if it is missing (I'll just define it as 0, since that seems to work for other systems). Fix committed.