xar SVN HEAD drops Leopard ACLs

[GoogleCodeExporter]

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/

Original issue reported on code.google.com by n8gray@gmail.com on 14 Dec 2007 at 12:58

[GoogleCodeExporter]

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

Original comment by bbraun on 14 Dec 2007 at 1:59

[GoogleCodeExporter]

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.)

Original comment by n8gray@gmail.com on 14 Dec 2007 at 7:29

[GoogleCodeExporter]

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 <sys/types.h> #include <sys/acl.h>], [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])])

Original comment by bbraun on 14 Dec 2007 at 8:07

[GoogleCodeExporter]

I believe the problem is in the configure test and no newline between #include
<sys/types.h> and #include <sys/acl.h>.  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.

Original comment by bbraun on 14 Dec 2007 at 8:33

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by n8gray@gmail.com on 14 Dec 2007 at 8:55

[GoogleCodeExporter]

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

Original comment by bbraun on 14 Dec 2007 at 8:59

[GoogleCodeExporter]

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);

Original comment by n8gray@gmail.com on 14 Dec 2007 at 9:13

[GoogleCodeExporter]

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.

Original comment by bbraun on 14 Dec 2007 at 9:27

[GoogleCodeExporter]

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

Original comment by n8gray@gmail.com on 14 Dec 2007 at 9:57

[GoogleCodeExporter]

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.

Original comment by bbraun on 14 Dec 2007 at 10:24

[GoogleCodeExporter]

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

Original comment by n8gray@gmail.com on 20 Dec 2007 at 2:41