Maven Assembly Plugin
  1. Maven Assembly Plugin
  2. MASSEMBLY-75

Unpacked TAR dependencies do not preserve file mode nor uid/gid

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.5
    • Component/s: None
    • Labels:
      None

      Description

      "TAR" Assemblies generated from unpacking another TAR do not preserver the extended file information (uid/gid/mod). For example:

      if bar.tar contains an executable file "baz" and

      if our .pom has the following dependency:

          <dependency>
            <groupId>foo</groupId>
            <artifactId>bar</artifactId>
            <type>tar</type>
            <scope>compile</scope>
          </dependency>
      

      and our assembly.xml has the following:

      <assembly>
          <id></id>
          <formats>
              <format>tar.gz</format>
          </formats>
      ....
         <dependencySets>
              <dependencySet>
                  <scope>compile</scope>
                  <outputDirectory/>
                  <includes>
                      <include>foo:bar</include>
                  </includes>
                  <unpack>true</unpack>
              </dependencySet>
      

      then the generated assembly will contain "baz", but it will no longer be executable.

        Issue Links

          Activity

          Maciej Szefler created issue -
          Hide
          Brett Porter added a comment -

          I'd suggest the way to fix this is to add ArchiveFileSet to the archiver, which has ZipFileSet, TarFileSet, etc.

          Basically, you read into the final archive straight from the source archive, without the crappy unpack step in between. It should also be faster, and we can keep everything (file times, modes, etc) where supported.

          • Brett
          Show
          Brett Porter added a comment - I'd suggest the way to fix this is to add ArchiveFileSet to the archiver, which has ZipFileSet, TarFileSet, etc. Basically, you read into the final archive straight from the source archive, without the crappy unpack step in between. It should also be faster, and we can keep everything (file times, modes, etc) where supported. Brett
          Hide
          Brett Porter added a comment -

          let's do this in conjunction with a migration to commons-compress where they are designing a clean API

          Show
          Brett Porter added a comment - let's do this in conjunction with a migration to commons-compress where they are designing a clean API
          Hide
          Robert Watkins added a comment -

          This is still an issue with 2.2-beta-1 (bit me not 30 minutes ago).

          the only workaround I've got at the moment is to leave the tarballs packed up, and then manually unpack them later (as part of the actual manual installation process).

          Show
          Robert Watkins added a comment - This is still an issue with 2.2-beta-1 (bit me not 30 minutes ago). the only workaround I've got at the moment is to leave the tarballs packed up, and then manually unpack them later (as part of the actual manual installation process).
          John Casey made changes -
          Field Original Value New Value
          Fix Version/s 2.2-beta-2 [ 13507 ]
          Trevor Pounds made changes -
          Link This issue depends upon PLXCOMP-94 [ PLXCOMP-94 ]
          Trevor Pounds made changes -
          Link This issue relates to MASSEMBLY-238 [ MASSEMBLY-238 ]
          Hide
          Grégory Joseph added a comment -

          still an issue with 2.2-beta-2, and we'd love a fix over here

          Show
          Grégory Joseph added a comment - still an issue with 2.2-beta-2, and we'd love a fix over here
          Hide
          John Casey added a comment -

          I think this is fixed as of my latest commit, but I need to add a specific test for it in plexus-archiver.

          Show
          John Casey added a comment - I think this is fixed as of my latest commit, but I need to add a specific test for it in plexus-archiver.
          Hide
          Grégory Joseph added a comment -

          Great

          Show
          Grégory Joseph added a comment - Great
          Hide
          John Casey added a comment -

          now I've added a unit test to plexus-archiver to verify this works. Unfortunately, it's no trivial task to ensure this works in an integration test for maven assembly plugin, since that IT wouldn't work on windows and we don't have a great way of marking which OSes a test should run on (at least, AFAIK).

          Show
          John Casey added a comment - now I've added a unit test to plexus-archiver to verify this works. Unfortunately, it's no trivial task to ensure this works in an integration test for maven assembly plugin, since that IT wouldn't work on windows and we don't have a great way of marking which OSes a test should run on (at least, AFAIK).
          John Casey made changes -
          Resolution Fixed [ 1 ]
          Assignee John Casey [ jdcasey ]
          Status Open [ 1 ] Closed [ 6 ]
          Hide
          Dan Carbs added a comment -

          I have tested this issue with the new 2.2-beta-3 released on January 5 2009 and it is NOT fixed. To reproduce, I have a dependency for which i set the filemode of multiple files to 777. When the dependency is unpacked as specified in the descriptor the permissions are lost.

          Show
          Dan Carbs added a comment - I have tested this issue with the new 2.2-beta-3 released on January 5 2009 and it is NOT fixed. To reproduce, I have a dependency for which i set the filemode of multiple files to 777. When the dependency is unpacked as specified in the descriptor the permissions are lost.
          Hide
          Gabe McArthur added a comment -

          Tested with 2.2-beta-4, and it's still not fixed. What gives? This has supposedly been closed, but I unpackage from a ZIP archive into a TAR.GZ archive, and I get no file permissions at all. Seriously, not even read on the user level: I get '-------'. How screwy is that? Why is this not tested/fixed after 8 months?

          Show
          Gabe McArthur added a comment - Tested with 2.2-beta-4, and it's still not fixed. What gives? This has supposedly been closed, but I unpackage from a ZIP archive into a TAR.GZ archive, and I get no file permissions at all. Seriously, not even read on the user level: I get '-------'. How screwy is that? Why is this not tested/fixed after 8 months?
          Hide
          John Casey added a comment -

          I notice there is not a single test case attached to this issue. I have a series of integration tests in this plugin that are designed to tell me whether a particular issue has been fixed, in addition to unit tests in the dependency projects. Obviously, they don't cover the use cases you are describing. Maybe you have something you can contribute to help me find the issue.

          BTW, this is open source, and in Maven there is a lot to do. If you have a deadline for getting this fix done, then you may want to have a look around to see whether you can find the issue yourself. Otherwise, it depends on the few of us Maven developers finding time to put together a release, test it as best we can, and ship it.

          Show
          John Casey added a comment - I notice there is not a single test case attached to this issue. I have a series of integration tests in this plugin that are designed to tell me whether a particular issue has been fixed, in addition to unit tests in the dependency projects. Obviously, they don't cover the use cases you are describing. Maybe you have something you can contribute to help me find the issue. BTW, this is open source, and in Maven there is a lot to do. If you have a deadline for getting this fix done, then you may want to have a look around to see whether you can find the issue yourself. Otherwise, it depends on the few of us Maven developers finding time to put together a release, test it as best we can, and ship it.
          Hide
          John Casey added a comment -

          apparently not fixed; waiting for test cases to proceed.

          Show
          John Casey added a comment - apparently not fixed; waiting for test cases to proceed.
          John Casey made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          Resolution Fixed [ 1 ]
          Hide
          Heather Wells added a comment -

          Tested with 2.2-beta-3. The permissions are set correctly if <includeBaseDirectory> is set to false. As soon as it's set to true, the permissions for unpackaged tar.gz dependencies lose the executable bit.

          Show
          Heather Wells added a comment - Tested with 2.2-beta-3. The permissions are set correctly if <includeBaseDirectory> is set to false. As soon as it's set to true, the permissions for unpackaged tar.gz dependencies lose the executable bit.
          John Casey made changes -
          Fix Version/s 2.2-beta-3 [ 13507 ]
          Fix Version/s 2.3-beta-1 [ 13669 ]
          Hide
          Sarma Palli added a comment -

          Tested maven-assembly-plugin 2.2.1, with zip file.
          with Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500). Works fine when run with maven 2.

          with Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600). It is broken.
          The permissions are set correctly if <includeBaseDirectory> is set to false.
          As soon as it's set to true, the permissions for unpacked files & directories are all 000.

          Show
          Sarma Palli added a comment - Tested maven-assembly-plugin 2.2.1, with zip file. with Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500). Works fine when run with maven 2. with Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600). It is broken. The permissions are set correctly if <includeBaseDirectory> is set to false. As soon as it's set to true, the permissions for unpacked files & directories are all 000.
          Hide
          Sarma Palli added a comment -

          Figured out the problem with the zip.
          The zip I was using was created using windows (WinZip). The permissions were missing from the zip itself.
          When unpacking the zip file under maven 2, the permissions are defaulted to drwxrwxrwx for directories and -rwsrwsrwt for files.
          When unpacking the zip file under maven 3, the permissions are defaulted to d--------- for directories and ---------- for files.

          Works fine when the zip is created in Unix.

          Show
          Sarma Palli added a comment - Figured out the problem with the zip. The zip I was using was created using windows (WinZip). The permissions were missing from the zip itself. When unpacking the zip file under maven 2, the permissions are defaulted to drwxrwxrwx for directories and -rwsrwsrwt for files. When unpacking the zip file under maven 3, the permissions are defaulted to d--------- for directories and ---------- for files. Works fine when the zip is created in Unix.
          Benson Margulies made changes -
          Fix Version/s 2.3 [ 13669 ]
          Dennis Lundberg made changes -
          Description "TAR" Assemblies generated from unpacking another TAR do not preserver the extended file information (uid/gid/mod). For example:

          if bar.tar contains an executable file "baz" and

          if our .pom has the following dependency:
              <dependency>
                <groupId>foo</groupId>
                <artifactId>bar</artifactId>
                <type>tar</type>
                <scope>compile</scope>
              </dependency>

          and our assembly.xml has the following:

          <assembly>
              <id></id>
              <formats>
                  <format>tar.gz</format>
              </formats>
          ....
             <dependencySets>
                  <dependencySet>
                      <scope>compile</scope>
                      <outputDirectory/>
                      <includes>
                          <include>foo:bar</include>
                      </includes>
                      <unpack>true</unpack>
                  </dependencySet>

          then the generated assembly will contain "baz", but it will no longer be executable.

          "TAR" Assemblies generated from unpacking another TAR do not preserver the extended file information (uid/gid/mod). For example:

          if bar.tar contains an executable file "baz" and

          if our .pom has the following dependency:
          {code:xml}
              <dependency>
                <groupId>foo</groupId>
                <artifactId>bar</artifactId>
                <type>tar</type>
                <scope>compile</scope>
              </dependency>
          {code}

          and our assembly.xml has the following:

          {code:xml}
          <assembly>
              <id></id>
              <formats>
                  <format>tar.gz</format>
              </formats>
          ....
             <dependencySets>
                  <dependencySet>
                      <scope>compile</scope>
                      <outputDirectory/>
                      <includes>
                          <include>foo:bar</include>
                      </includes>
                      <unpack>true</unpack>
                  </dependencySet>
          {code}

          then the generated assembly will contain "baz", but it will no longer be executable.

          Kristian Rosenvold made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Assignee John Casey [ jdcasey ] Kristian Rosenvold [ krosenvold ]
          Fix Version/s 2.5 [ 18952 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 09:09:00 UTC 2015 [ 1428224940639 ]
          Mark Thomas made changes -
          Workflow jira [ 12717028 ] Default workflow, editable Closed status [ 12760664 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 22:33:31 UTC 2015 [ 1428273211083 ]
          Mark Thomas made changes -
          Workflow jira [ 12954608 ] Default workflow, editable Closed status [ 12991953 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          992d 22h 25m 1 John Casey 10/Dec/08 17:29
          Closed Closed Reopened Reopened
          259d 18h 1m 1 John Casey 27/Aug/09 12:31
          Reopened Reopened Closed Closed
          1872d 15h 27m 1 Kristian Rosenvold 13/Oct/14 03:58

            People

            • Assignee:
              Kristian Rosenvold
              Reporter:
              Maciej Szefler
            • Votes:
              7 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development