• Visibility

First of all, the easier to find, is libtar ! And that's why I firstly used it. It is on freshmeat and a few projects relies on it.
When some nice guy added ftwin to archlinux packages, I discovered that the packet manager pacman was using libtar too, it made me blindly trust this library.

  • Problems
 1. libtar

Then came the problems with libtar, summed up in my comments of ftwin 0.6.0 :

/*
 * First:
 * The libtar API doesn't allow to use pointer as return of openfunc frontend,
 * and on 64 bits architecture the cast proposed in the example libtar.c
 * truncate the pointer (64 bits) returned by gzdopen function by casting it to
 * an int (32 bits).
 *
 * Thus, the solution I choose is to use a global variable (I hate it...) to
 * store the pointer returned by gzdopen.
 *
 * This ugly workaround works because I'm not a multi-threaded app.
 *
 * Second:
 * because of inconsistent allocation in function th_get_pathname, strdup() ing
 * 2 times on 3, not allowing a correct free in the return function. There's a
 * memory leak introduced by this behavior...
 */

First, an incompatibility in the openfunc callback prototype with my test machine which is under x86_64.
Then an internal function was playing with my nerves (it had 3 returns, 2 were returning an allocated string, the third was'nt, making it impossible to predict when to free or not...).
I wasn't able ( and did'nt take time ... ) to understand the internals of the library, and preferred to release a memory leaking version of ftwin.

 2. libarchive

As it implements internally the decompression, I didn't have the same cast problem as I had with libtar.
I quickly checked the different manpages about the API and didn't see any similar ugly callback bugs.
But while I was hunting for bug with valgrind I found a memory leak in libarchive too. The guilty function was header_longname() of archive_read_support_format_tar.c, so I searched in the "garbage collector" of this file to find that two archive_string object were not freed. The memory leak is fixed it by adding :

       archive_string_free(&tar->longlink);
       archive_string_free(&tar->longname);

in archive_read_format_tar_cleanup() function.

  • Conclusion

Both libraries have a clear API, and libtar is easier to understand, however, libarchive is more complete, bugfree, and his internals are well organized (that allowed me to patch quickly the memleak).

Oh, by the way, ftwin 0.7.0, using libarchive instead of libtar, is out !