Plexus Components

archivers do not detect duplicated files in the archive

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: plexus-archiver
  • Labels:
    None
  • Number of attachments :
    2

Description

This allows the same file to be added from two different calls, and the same exact path will be added twice to a single archive, prompting for overwrite when the archive is extracted.

Issue Links

This issue is depended upon by:
MASSEMBLY-285 regression: duplicate files added to the assembly Blocker Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Erik Engstrom added a comment -

Here is a unit test that exposes the problem.

Show
Erik Engstrom added a comment - Here is a unit test that exposes the problem.
Hide
Permalink
Erik Engstrom added a comment -

The unit test depends on src/test/resources/group-writable/foo.txt and src/test/resources/world-writable/foo.txt to have different content in the first line.

Show
Erik Engstrom added a comment - The unit test depends on src/test/resources/group-writable/foo.txt and src/test/resources/world-writable/foo.txt to have different content in the first line.
Hide
Permalink
Erik Engstrom added a comment -

Here is a patch to AbstractArchiver that fixes the problem. I changed the archiver to store the resources in a Map (instead of a list) with the path as the key. The last resource added with a given path wins.

Show
Erik Engstrom added a comment - Here is a patch to AbstractArchiver that fixes the problem. I changed the archiver to store the resources in a Map (instead of a list) with the path as the key. The last resource added with a given path wins.
Hide
Permalink
John Casey added a comment -

I didn't apply the patch, as it seemed to replace a lot of logic that wasn't necessary to replace. It also didn't make any allowances for different duplicate-file behaviors that should be configurable. Instead, I migrate the duplicate-file behavior logic out of AbstractZipArchiver and formalized it to two methods in Archiver/AbstractArchiver to configure it, and four constants in Archiver to allow programmatic configuration without using raw string values.

I did apply your unit test, Erik, thanks for that.

Show
John Casey added a comment - I didn't apply the patch, as it seemed to replace a lot of logic that wasn't necessary to replace. It also didn't make any allowances for different duplicate-file behaviors that should be configurable. Instead, I migrate the duplicate-file behavior logic out of AbstractZipArchiver and formalized it to two methods in Archiver/AbstractArchiver to configure it, and four constants in Archiver to allow programmatic configuration without using raw string values. I did apply your unit test, Erik, thanks for that.
Hide
Permalink
Erik Engstrom added a comment -

Thanks for the fix. Looking at your code, I have two questions:

1) What is the difference between DUPLICATES_PRESERVE and DUPLICATES_SKIP? Your code seems to treat them the same
2) Is there a way to configure it so that later files replace older ones? That is the behavior I was trying to achieve. I wanted the archive targets to work like the directory target does. I should have made my test clearer.

Thanks

Show
Erik Engstrom added a comment - Thanks for the fix. Looking at your code, I have two questions: 1) What is the difference between DUPLICATES_PRESERVE and DUPLICATES_SKIP? Your code seems to treat them the same 2) Is there a way to configure it so that later files replace older ones? That is the behavior I was trying to achieve. I wanted the archive targets to work like the directory target does. I should have made my test clearer. Thanks

People

Vote (9)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.