Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19947

Missing base directory in ZIP from .../artifact/dir/subdir/*zip*/subdir.zip

      1.509.x would create a subdir.zip with a root entry subdir/. Development builds omit this top directory.

          [JENKINS-19947] Missing base directory in ZIP from .../artifact/dir/subdir/*zip*/subdir.zip

          Jesse Glick created issue -
          Jesse Glick made changes -
          Link New: This issue is blocking JENKINS-17236 [ JENKINS-17236 ]
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-19752 [ JENKINS-19752 ]
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          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.

          SCM/JIRA link daemon added a comment - 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.
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Progress [ 3 ] New: Resolved [ 5 ]

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2940
          [FIXED JENKINS-19947] Restore historical undocumented behavior of a top-level entry in a ZIP. (Revision 793b6826e567e20a256a6d4166031e75a185ef7a)

          Result = UNSTABLE
          Jesse Glick : 793b6826e567e20a256a6d4166031e75a185ef7a
          Files :

          • changelog.html
          • core/src/main/java/hudson/util/DirScanner.java
          • test/src/test/java/hudson/model/DirectoryBrowserSupportTest.java
          • core/src/main/java/hudson/FilePath.java
          • core/src/main/java/hudson/model/DirectoryBrowserSupport.java

          dogfood added a comment - Integrated in jenkins_main_trunk #2940 [FIXED JENKINS-19947] Restore historical undocumented behavior of a top-level entry in a ZIP. (Revision 793b6826e567e20a256a6d4166031e75a185ef7a) Result = UNSTABLE Jesse Glick : 793b6826e567e20a256a6d4166031e75a185ef7a Files : changelog.html core/src/main/java/hudson/util/DirScanner.java test/src/test/java/hudson/model/DirectoryBrowserSupportTest.java core/src/main/java/hudson/FilePath.java core/src/main/java/hudson/model/DirectoryBrowserSupport.java

          Daniel Beck added a comment -

          Is this really something that should be changed? I've always wondered why the unnecessary directory was added in the first place.

          Daniel Beck added a comment - Is this really something that should be changed? I've always wondered why the unnecessary directory was added in the first place.

          Jesse Glick added a comment -

          Is this really something that should be changed?

          It is an inconsistent special behavior that I am not fond of either, but as the historical behavior it must be retained as people may have scripts etc. relying on it.

          why the unnecessary directory was added in the first place

          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.

          Jesse Glick added a comment - Is this really something that should be changed? It is an inconsistent special behavior that I am not fond of either, but as the historical behavior it must be retained as people may have scripts etc. relying on it. why the unnecessary directory was added in the first place 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.

          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

          Matthew Webber added a comment - 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

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: