Unzip symlinks from a ZipArchiveInputStream on Android

Question

I have troubles to unzip symlinks from a zip archive on Android with the apache commons-compress-1.6 library.

When I get the ZipArchiveEntry, there is a method called isUnixSymlink() which tells that the file is a symlink or not, but it returns always false.

InputStream inputStream = new FileInputStream(archive);
ZipArchiveInputStream zipInputStream = new ZipArchiveInputStream(inputStream);
ZipArchiveEntry ze = null;

while ((ze = zipInputStream.getNextZipEntry()) != null) {
    File path = new File("/tmp/user/folder", ze.getName());
    byte[] extras = ze.getExtra();
    boolean isSymlink = ze.isUnixSymlink();

I read the documentation located here : http://www.pkware.com/documents/casestudies/APPNOTE.TXT, they are talking about extras informations in the chapter "4.5 Extensible data fields". Extras should start

with 2 bytes for the header id (which in my case should be "0x000d UNIX"

and 2 bytes for the data size

but the two first bytes are always [85, 84], and after I have the byte array [9, 0].

Maybe that's why the ZipArchiveEntry cannot returns the good boolean. Someone can give me some explanations about that case ?

Thanks in advance.

Answer 1

Ok I found the right way to find zip file extra data in the unzip source files... didn't found any documentation (if someone has, please send us a link)

The two first bytes array is an universal timestamp. The next two bytes array is the size of the next data which contains pkware data as access time, modify time eso.

The next two bytes array is also the header id, and the next two one is the data size and last bytes are extra informations.

But even I interpret them, and even the java code is running on a Unix file system, I don't get any information about the file is a symlink or not.

Answer 2

I was having the same problem. Turns out, ZipArchiveInputStream comes with the following caveats (emphasis mine):

The ZipFile class is preferred when reading from files as ZipArchiveInputStream is limited by not being able to read the central directory header before returning entries. In particular ZipArchiveInputStream

• may return entries that are not part of the central directory at all and shouldn't be considered part of the archive.
• may return several entries with the same name.
• will not return internal or external attributes.
• may return incomplete extra field data.
• may return unknown sizes and CRC values for entries until the next entry has been reached if the archive uses the data descriptor feature.

While the question specifically asks about ZipArchiveInputStream, I thought i would share that switching to ZipFile solved the problem for me.