What steps will reproduce the problem? 1. create a file foo with ACLs 2. xar -c -f tmpfile foo 3. cd somewhere_else 3. xar -x -f tmpfile

or alternately, test with backup-bouncer and notice the failures.

What is the expected output? What do you see instead? I expect the output of "ls -Plde foo" to be identical in both directories. Instead the foo in somewhere_else has no ACLs.

What version of the product are you using? On what operating system? Today's SVN HEAD, Mac OS X 10.5.1.

Please provide any additional information below. The last time I tested xar was on Tiger in May, and it did not have this issue. You can verify this problem using backup-bouncer: http://www.n8gray.org/code/backup-bouncer/

If someone with 10.5 can test or look into this, that'd be great. I do not currently have access to 10.5.

It looks like the configure script fails to set HAVE_SYS_ACL_H. Running "locate acl.h" on my system gives me /usr/include/sys/acl.h

(Note: I'm actually relaying this bug report from a backup-bouncer user so I'm not doing the digging myself. I have, however, verified the report myself.)

Great, that's something to go on. The sys/acl.h detection is a little odd because it tries to verify a working acl_t as well. Here is the autoconf test currently used: AC_TRY_COMPILE([#include #include ], [acl_t a], [AC_DEFINE([HAVE_SYS_ACL_H],[1], [define if you have sys/acl.h and it has a working acl_t type])])

I believe the problem is in the configure test and no newline between #include and #include . A newline has been inserted and checked into subversion. If you (or the backup-bouncer user) could give it another shot, that'd be great.

Ok, looking at config.log it appears that your test is trying to link to -lacl, but in Leopard there is no libacl. The acl man page indicates that the acl functions are part of libc.

That's fine, it just won't use -lacl on osx. That's expected and not erroneous.

Ok, well here's the output:

configure:7577: checking for acl_get_file in -lacl configure:7612: gcc -o conftest -Wall -g conftest.c -lacl >&5 ld: library not found for -lacl collect2: ld returned 1 exit status configure: failed program was: | /* confdefs.h. / | #define PACKAGE_NAME "Xar" | #define PACKAGE_TARNAME "xar" ... | #define DEV_CAST (uint32_t) | / end confdefs.h. / | | / Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char acl_get_file (); | int | main () | { | return acl_get_file (); | ; | return 0; | }

And here's the relevant declaration in acl.h: extern acl_t acl_get_file(const char *path_p, acl_type_t type);

That should be fine. If the -lacl test fails, it's not a big deal. Are you testing with r201 from subversion? I committed that configure.ac change earlier.

Yes, I'm testing 201. I did an svn up followed by autogen.sh and configure. Is there something else I need to do?

That should detect sys/acl.h and define HAVE_SYS_ACL_H in include/config.h, which will address the initial problem of sys/acl.h detection.

OK, looks like you're right and the issue is fixed. Thanks!