Possibly by mistake (the code in question seems to have never previously been subject to automated test), but also possibly to ensure that someone running unzip or the equivalent will always get a single folder as a result—if you forget to unzip to a new destination directory, it can be quite annoying to have your current directory strewn with several dozen new files and subdirectories
Actually, unzip behaviour differs depending on whether you are Linux or Windows.
On Linux, the behaviour is as you describe - the unzip writes into the current directory.
On Windows, unzip creates a new directory with the same name as the .zip file (minus the .zip extension) and then writes into there (that's with the GUI - not sure what the command line does).
In fact, when we zip up our product, we add an extra directory level in the Linux .zip, but not in the Windows .zip, for exactly that reason.
Matthew
Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/hudson/FilePath.java
core/src/main/java/hudson/model/DirectoryBrowserSupport.java
core/src/main/java/hudson/util/DirScanner.java
test/src/test/java/hudson/model/DirectoryBrowserSupportTest.java
http://jenkins-ci.org/commit/jenkins/793b6826e567e20a256a6d4166031e75a185ef7a
Log:
[FIXED JENKINS-19947] Restore historical undocumented behavior of a top-level entry in a ZIP.
Noting that various DirScanner implementations handle this inconsistently.