search

srikanth-lingala / zip4j

A Java library for zip files and streams
Apache License 2.0
2.09k stars 313 forks source link

Zip File Header requiring either "\" or "/" for an entry to be considered a directory #274

Closed smeverts closed 3 years ago

smeverts commented 3 years ago

I have come across some software that generates a zip file which does not include a trailing "\" or "/" on the filename of a directory. Instead they update the "External File Attributes" (which seems to have been the standard way of doing it with the pkware/pkzip stuff.

I found this answer on stackoverflow to be useful:

Is there a specific reason why you are just looking for a trailing "/" or "\" to determine if the Zip Header Entry represents a directory instead of the "External File Attributes"?

I have had to patch the HeaderReader code to look at the value read into the ExternalFileAttributes byte array and compare it against the value 16 (0x10) (values from the above Microsoft documentation, they seem to be valid for linux, macos and windows) and it seemed to work fine.

srikanth-lingala commented 3 years ago

Would it be possible for you to attach a sample zip file generated by that software?

srikanth-lingala commented 3 years ago

@smeverts Would you be able to attach a sample zip file please? It would be good to see the headers which are set for analysing and implementing this.

srikanth-lingala commented 3 years ago

After some research on this topic, here are my findings: You are right that it is not right to depend on just "/" to define an entry as a directory, and external file attributes have to be considered as well. But it is not right to just check this value for 16 (0x10), because external file attributes are dependent on the file system on which the zip file is created. A zip file generated on Windows will have different values set in external file attributes than a zip file generated on unix based system. Even on a Windows system, we cannot just compare it to 16 (0x10), because if a directory is hidden, it will have a different value (18) than 16, and similarly if it is a system directory, it might have another value. Basically, what we have to be comparing against in a zip file generated on Windows system is that the 4th bit of the first byte of general purpose flag is set. In a zip file generated on unix system, 6th bit on 4th byte will be set for a directory. We should also fallback and check for a slashes in file names because some tools (ex: JDK zip) does not set the right flags in external file attributes.

I have pushed a fix for this and will include it in the next release.

srikanth-lingala commented 3 years ago

Issue fixed in v2.7.0 which was released today.