Hi, Please help review the change for #6233323.
http://cr.openjdk.java.net/~sherman/6233323/webrev Background info: 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 CCC approval). 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. Thanks! -Sherman
