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: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      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

          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).
          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).
          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.
          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.
          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.

            People

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

              Dates

              • Created:
                Updated: