I will move the focus of the project from bitbucket to github.

Due to popular demand, the source will be downgraded to make it compatible with Java 1.6.

This means:

• remove try-with-resource blocks
• re-implement closeQuietly method for closing streams
• remove diamond operator

Hello

Would you consider taking a PR that made it possible to specify an alternative file extension? I'd like to use jarchivelib to create "dump" files for Neo4j, but we don't want to advertise the file format in the extension.

Thanks
-Ben

to properly test #6, create abstract tests in the same way archivers are tested.

I'm trying to use the jarchivelib API to create a .tar.gz file and I need to set the LONGFILE_POSIX and BIGNUMBER_POSIX settings on the TarArchiveOutputStream. There may be a way to do this already using the API but I can't seem to figure it out. See http://commons.apache.org/proper/commons-compress/tar.html

The API looks great, it would be great if there were a way to use it with these settings.

Thanks!

Was having an issue on linux where my maven process wouldn't properly finish. After digging a couple hours, it looked like extra threads were being spun up and not properly cleaned up. Unfortunately, the root cause was jarchivelib. Didn't have the issue on windows. After digging thru your code, I suspects its the spinning up of "chmod" as an external process to apply permissions. Java 7 has pretty awesome support for properly setting posix permissions all in Java. No need for an external process. I reverted back to Apache commons compress for now, but wanted to give you a heads up on the issue.

Perhaps that should be done for the first major release.

also test #42

Hi,

is it possible to get size of the extracted tarball (tgz) would have on the filesystem through one of the lib methods?

Cheers.

currently IO exceptions are propagated, would make sense to extend error handling for this and test it properly.

There is no unified interface in commons' ArchiveEntry to access permission flags as they differ greatly for each different archive type.

With some type of wrapper hierarchy that focuses on POSIX permissions, it should be possible to cover a high percentage of use cases. No idea how to map non-POSIX permissions yet though (ntfs/fat being the most important).

The CompressArchiveEntry does not take into account the unix permissions of the commons's ArchiveEntry. This can be read on a zip entry from getUnixMode(), for example. Tar files also support executable files (from what I remember), but I can't see any way to pull that data from a TarArchiveEntry.

Useful for Karaf users

I have a use case where I have an input stream (and I know the type) and I'd like to unpack to a directory, It looks as if I can't do that, am I missing something?

Only into files directly, which is impractical and inconsistent. Like the Archiver, the Compressor API should allow to compress and decompress files into directories. Filename extensions need to be handled accordingly. This might be awkward when removing the filename extension of the compression type from the file. (When a "gz" compressor is created, but the filename extension is ".gzip")

Make it so.

It would be nice to have a compresser, which explicitly donates that there is explicitly no compression.

Main reason: it would be possible to always use the same method to create archivers using some dynamic mechanism.

org.rauschig:jarchivelib:jar:0.6.1 maven artifact simultaneously depends on and contains org.apache.commons:commons-compress:jar:1.8 (you can see this here, in the "Packages" section).

If maven-enforcer-plugin is configured with BanDuplicateClasses rule, plain Java (non-OSGI) projects depending on jarchivelib will fail to build:

[WARNING] Rule 2: org.apache.maven.plugins.enforcer.BanDuplicateClasses failed with message:
Duplicate classes found:

  Found in:
    org.rauschig:jarchivelib:jar:0.6.0:compile
    org.apache.commons:commons-compress:jar:1.8:compile

Looks like this had been done to package jarchivelib as an OSGI bundle. Using Import-Package: org.apache.commons.compress.*;version=1.8 instead of Embed-Dependency will probably solve this problem and will ensure that the users can add dependency on externally-packaged commons-compress bundle, e.g. from Eclipse Orbit. See this stackoverflow question for a similar solution.

To provide full OSGi support. Maybe in pax tipi

The callee should not close a stream!

in concordance to #2

Hello,

so I'm trying to do seeking inside a .tar.gz and I've attempted to get offset of a certain file I need, and I know its size.

            byte[] fileBytes = new byte[entrySize];
            stream2.read(fileBytes, entryOffset, entrySize);

However this doesn't seem to produce usable file at all.

Any ideas? Or maybe could I could "skip(entryOffset)" and then getCurrentEntry?

Thanks.

• lzma
• snappy-framed
• snappy-raw
• xz
• z

From the commons-compress documentation for zip:

This means the ZIP format cannot really be parsed correctly while reading a non-seekable stream, which is what ZipArchiveInputStream is forced to do.
[...]
If possible, you should always prefer ZipFile over ZipArchiveInputStream. 1

this is necessary for #14 to retrieve file attributes properly

Would be a great feature but it will require to actually represent archives by some interface which will in turn involve more API changes, or actually a re-design of the entire Archiver API.

Reverting back to Java 6 was fun and all, but preserving file attributes is a pain/not possible properly without Java 7. To fully support attribute preservation, I need java.nio.

For jarchivelib v2.0.0 I will be using Java 7.

Suppose I have the following file structure:

└── rootFolder
    ├── folder1
    │   └── someFile
    ├── folder2
    │   └── someFile
    └── folder3
        └── someFile

and I want to add folder1 and folder2 to an archive.

The following code doesn't quite work, because it will just add someFile twice (without adding the roots folder1 and folder2):

Archiver archiver = ArchiverFactory.createArchiver(ArchiveFormat.ZIP);
archiver.create("archive", dest, new File("rootFolder/folder1"), new File("rootFolder/folder2"));

produces

└── archive.zip
    └── someFile

But I'd like to obtain:

└── archive.zip
    ├── folder1
    │   └── someFile
    └── folder2
        └── someFile

Any thoughts on how to achieve this?

The last remnant of commons-io is the use of FileUtils to force-delete the files/directories, this could be removed.

Apparently I disregarded the possibility of file list orderings being different on different systems. Some of the asserts fails sporadically in travis.

Should be possible with commons-compress 1.8

What happens if you pass a .tar archive to an archiver that handles .zip? This is not tested at all at the moment.

hi,when my xx.tar.gz file contains a soft link, after extract, the soft link turn a empty file.

The way file types and suffixes are handled grew into an unclean implementation.

Desired behaviour of e.g. archive-compressors that handle ".tgz" rather than composite extensions such as ".tar.gz", has to be thought through and a clean concept derived.

Consequently, the API for Archiver and ArchiverFactory have to be more precise on how to deal with probing of file types and creation of archives where the file suffix is appended automatically.

doesn't like the <p/> tags

The commons stream factories provide methods for creating input-streams based on auto-detection. This functionality is currently used without any kind of consideration. Archivers can extract anything that is auto-detectable by the ArchiveStreamFactory, because CommonsArchiver creates the streams by passing the InputStream of the file to extract, rather than the archive format.
While this may be a convenient behavior in some cases, its confusing, unclean and can cause issues where archive/compression types may actually not be auto-detectable (all the new compression formats, or JAR for example).

ArchiveStreamFactory cannot tell JAR archives from ZIP archives and will not auto-detect JARs.

Auto-detection should but be segregated and properly documented.

Currently links are not supported at all. Depending on the archive type, weird things will happen.

should be org.rauschig :: jarchivelib

Enhance the Archiver interface to have an extract(InputStream archive, File destination) method for archives that are not files (such as URLs).

Debian archive files (.deb) are an "ar" file containing a set of tar.gz files.

I'd love to be able to pass the ArchiveStream from the "ar" into a new Archiver.stream() call to extract a file from the embedded tar.gz.

I'm not familiar enough with Streams to know if that would work. Archiver.stream() appears to take a File only.

Thoughts?

They're not handled in the current examples.

Simple and clean API but I have an issue.

I am using a test file named fileNane.gz. It is not a compressed file but a text file with the .gz extension. This file seems to be locked by a process when trying to delete.

compressor.decompress(f, new File(f.getParent()) ) throws an exception as expected but I cannot delete the file.

Here is my code:

private boolean decompress(File f) {
    try{
        Compressor compressor = CompressorFactory.createCompressor(f);
        System.out.println("COMPRESSED FILE");

        compressor.decompress(f, new File(f.getParent()) );
        FileUtils.deleteQuietly(f);

        return true;
    }catch(IllegalArgumentException e){

    }catch(FileNotFoundException e){

    }catch (Exception e) {

        System.out.println(f.canExecute()); // is true
        System.out.println(f.canRead()); // is true
        System.out.println(f.canWrite()); // is true
        System.out.println(f.exists()); // is true

        System.out.println(f.delete()); // is false

        System.err.println(e); 
    }

    return false;
}

testing Pack200 works differently than testing gz or bzip2. create tests for explicitly asserting Pack200 integration functionality.

Restoring file permissions on extraction works with #14, however there are no clean mechanisms for reading permissions from a File and setting them in an ArchiveEntry.

Could you please state the license for this component? I don't see one? Apologies if I'm being dense.

The current version 0.6. embeds commons-compress which has a bug that makes extracting some Tar archives fail. This is fixed with version 1.8.1.
jarchivelib may want to update to the latest version of commons-compress to circumvent issues with failing archives.

An example for a failing archive is the Maven 3.0.5 tar.gz file: http://ftp.halifax.rwth-aachen.de/apache/maven/maven-3/3.0.5/binaries/apache-maven-3.0.5-bin.tar.gz