RFR: 6233323,,ZipEntry.isDirectory() may return false incorrectly
xueming.shen at oracle.com
Thu Sep 19 22:10:00 UTC 2013
Please help review the change for #6233323.
ZipFile.getEntry() is implemented the way that it first tries to find the entry
with the exactly matched name. If failed, it then tries to see if the specified
name ends with a slash '/', if not, it then tries to find the entry with the '/'
appended, with the expectation that there might be a "directory" entry, whose
name ends with '/'. The problem here is that the returned entry actually sets
its name with the original passed in name in this situation, so if the passed
in name does not end with the '/' and the search result is the one with '/'
(directory), the returned entry then fails the ZipEntry.isDirectory() test, which
is purely implemented on the assumption/specification that "A directory entry
is defined to be one whose name ends with a '/'".
The change here is to return the entry with the name of the "real" name of
the entry in the zip file, with the '/' slash appended. I also added some words
to clarify this behavior (given the nature of the change, I probably need a
Interestingly, "an entry whose name ends with a slash is a directory entry"
appears to be a convention, instead of something being explicitly specified
in either pkware or info-zip's specification. zip/uzip and our jar definitely work
with the assumption that a "slash / ended" entry is a directory, however it
easily to read/write an entry with slash ended name as a "normal" file entry
via ZipInputStream/OutputStream (both unzip and jar treat such an entry as
a directory entry, they create a directory instead of extracting it as a file, when
being extracted). One of the reasons that I did not explicitly say "directory
entry" in the wording added to the getEntry() method.
More information about the core-libs-dev