edmund-wagner / junrar Goto Github PK

hi! first of all, thanks for making this project! i'm using it in a school project and really appreciated how easy it is to use. however, i found a couple of bugs: first, sometimes it miscalculates the crc for small files, detecting them as corrupt when they're not. i see that someone already reported the bug so i won't waste your time by describing it: i removed the crc check as a workaround in my project, but that's a veeeery cheap workaround as it may not detect corrupt archives (unless it's the header that's corrupted). second: for some archives (very large ones apparently), it gets stuck at the end of extraction, extracting the last file/folder forever. i kinda fixed this by modifying my extractor class to stop the extraction if extracting the same file twice but i'm pretty sure there's a better way to do that

In com.github.junrar.unpack.vm.RarVM, opcodes likes VM_INC, VM_INCB, VM_INCD, VM_DEC, VM_DECB, VM_DECD, VM_ADC, VM_SBB, VM_MUL... contains an errors:

In java operator '+', '-', '*' have priority over bitwise '&'.
So: (v & 0xffffffff + 1) becomes: (v & (0xffffffff + 1)), ie always 0
So: (v & 0xffffffff - 1) becomes: (v & (0xffffffff - 1))

ref: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/operators.html

regards
Tyco :)

It should be possible to log without that import.

The file unrar/src/main/java/com/github/junrar/Volume.java claims to be licensed under the GPL3+

This appears to be incompatible with the terms of the license at license.txt

Hello,

In case the library is used unmodified, could you please clarify if the distribution in a commercial context is allowed?

Thank you.

Hi,

I am encountering with Nullpointer exception when I am instantiating the Archive object. This file is valid and can be extracted with some other applications like "winrar" on windows and "zipeg" on mac os x. The trace like below. You can download the rar file from

http://78.47.144.62/sample.rar

Jul 25, 2011 4:49:35 PM de.innosystec.unrar.Archive setFile
WARNING: exception in archive constructor maybe file is encrypted or currupt
java.lang.NullPointerException
at de.innosystec.unrar.Archive.readHeaders(Archive.java:234)
at de.innosystec.unrar.Archive.setFile(Archive.java:124)
at de.innosystec.unrar.Archive.(Archive.java:108)
at de.innosystec.unrar.Archive.(Archive.java:96)
at com.xxxx.common.service.FileIOService.extract(FileIOService.java:16)
at com.xxxx.common.service.FileIOServiceTest.shouldFindReleatedTextFileInCorrectFolderWhenRarFileExists(FileIOServiceTest.java:16)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:274)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:242)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:58)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:240)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:48)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:233)
at org.junit.runners.ParentRunner.run(ParentRunner.java:303)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Hello,

I created simple rar and zip files with WinRar to use for testing Junrar. They contain a simple text file. For the encrypted archives, the password is just "encrypted". See attachments,

For unencrypted.rar, I expected extraction to work. For everything else, I expected RarException. For the zip files, I get unexpected NullPointerException instead. One line of code is sufficient to reproduce the NullPointerException in Junrar.

		Archive arc = new Archive(new File("C:/encrypted.zip"));

Root cause is Junrar's Archive.java line 245. The return value of BaseBlock.getHeaderType() is null, and passing a null value to a switch() statement triggers a NullPointerException.

241 BaseBlock block = new BaseBlock(baseBlockBuffer);
242
243 block.setPositionInFile(position);
244
245 switch (block.getHeaderType()) {

To fix, please add a null check for BaseBlock.getHeaderType() and throw RarException. This simple patch should help improve the graceful error handling of Junrar.

Thank you,
Justin

encrypted.zip
unencrypted.zip

Simulation Steps:

1. Use extractArchive method of the ExtractArchive Class to extract the .rar file.
2. Once extracted, try to delete the original archive.
3. It gives error that the archive is open in java (TM)**********

extractFile does not accept a FileHeader which was obtained while Archive was reading a different Volume. So if you collect the headers to build up a file tree and then later pass one of these header objects back to extractFile, this check rejects it:

   if (!headers.contains(hd)) {
       throw new RarException(RarExceptionType.headerNotInArchive);
   }

Removing this check fixes the problem at the expense of losing the check. Keeping track of all headers ever handed out might be a better solution to this part of the issue.

Additionally, if Archive is currently pointing at a volume which is not the first volume in the set, you can get a CRC error, presumably because it doesn't start reading from the first file which contained the header.

The workaround I used to get around both of these related issues was to create a brand new instance of Archive and call extractFile on that. That way, I'm always on the first file.

The other major problem which will bite people without them realising it is that getFileHeaders() always returns only the headers for the current volume. If you want to find all files in the archive, you have to manually call the volume-related methods on Archive, which feels like a bit of a dodgy workaround (works, though.)

any Idea? why L junrar library version is slow performance ?

I'm a noob with log4j so if there is a way... well.

The archive constructors call readheaders eventually. There there is a log of alll exceptions:
WARNING: exception in archive constructor maybe file is encrypted or currupt

and a comment on that catch:
//ignore exceptions to allow exraction of working files in
//corrupt archive

In my data, there is one or two files that are corrupt/encrypted: that catch logs a NullPointerException (i didn't pass null). However, as it is a nullpointer, not a IOException, i don't have a file name (or indeed, i don't have anything to report to the user, because that the exception triggered is opaque to the code).

I'd prefer if this corner case was configurable, maybe by throwing a exception at the end of the constructor, documenting on it that you can still try using the archive for the non-corrupted parts, or a 'getError' or a similar scheme.

Hello Edmund,

My name is Michael and I am with IBM software labs.

We would like to use JUNRAR library in one of our projects.

Can you be so kind to shed some light on few legal issues with the library?

What exactly the license terms actually apply to the library, this https://github.com/edmund-wagner/junrar/blob/master/license.txt license talks about UNRAR which seems a different software entity?
Are Junrar and Unrar related in any way? Are their licenses related?
We notice on the SourceForge that the project was removed allegedly for some sort of violation? Can you please comment on this?

Thanks a lot!

Michael Davidovich

Content Discovery Group.

Hi
I am curious the sources dates to 29/11/2011 but the latest 0.5 jar to 30/01/11. The jar appears to be is much earlier?
Is this code match to the jar?

Can you please clarify this?

Thanks
Michael

Hi,
We are doing due diligence on JUNRAR to determine if we can legally use it.
Would you be kind to answer the following questions:

• Who is the copyright owner for JUNRAR?
• According to the copyright statement in most of the JUNRAR files, the copyright owner is innoSysTec with Edmund Wagner as the author. Does innoSysTec agree to publish this project as open source? Did Edmund Wagner work for innoSysTec while authoring JUNRAR? Did he get permission from innoSysTec to contribute to this open source project?
  We tried writing to [email protected] but did not get a response.
  Thanks,
• Yariv

Hi,

I did not find a buit-in way of unrar'ing a byte array, so I wrote an implementation of VolumeManager and one of Volume, called ByteArrayVolumeManager and ByteArrayVolume.

I think they may be useful to someone else, so I donate them to the project ;-)

I ask you, anyway, to check that I did not do any large and stupid error (my tests are ok, though).

I paste them here:

/*
 * This file is part of seedbox <github.com/seedbox>.
 *
 * seedbox is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * seedbox is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with seedbox.  If not, see <http://www.gnu.org/licenses/>.
 */
package com.github.junrar.impl;

import java.io.IOException;

import com.github.junrar.Archive;
import com.github.junrar.Volume;
import com.github.junrar.VolumeManager;


/**
 * @author <a href="http://www.rogiel.com">Rogiel</a>
 * 
 */
public class ByteArrayVolumeManager implements VolumeManager {
    private byte[] bytes;

    public ByteArrayVolumeManager(byte [] bytes) {
        this.bytes = bytes;
    }

    @Override
    public Volume nextArchive(Archive archive, Volume last)
            throws IOException {
        return new ByteArrayVolume( archive, bytes );
    }
}

/*
 * This file is part of seedbox <github.com/seedbox>.
 *
 * seedbox is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * seedbox is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with seedbox.  If not, see <http://www.gnu.org/licenses/>.
 */
package com.github.junrar.impl;

import java.io.IOException;

import com.github.junrar.Archive;
import com.github.junrar.Volume;
import com.github.junrar.io.IReadOnlyAccess;
import com.github.junrar.io.ReadOnlyAccessByteArray;


/**
 * @author <a href="http://www.rogiel.com">Rogiel</a>
 * 
 */
public class ByteArrayVolume implements Volume {
    private final Archive archive;
    private final byte [] bytes;

    /**
     * @param file
     */
    public ByteArrayVolume(Archive archive, byte [] bytes) {
        this.archive = archive;
        this.bytes = bytes;
    }

    @Override
    public IReadOnlyAccess getReadOnlyAccess() throws IOException {
        return new ReadOnlyAccessByteArray(bytes);
    }

    @Override
    public long getLength() {
        return bytes.length;
    }

    @Override
    public Archive getArchive() {
        return archive;
    }

}

In Comic Viewer android app, I have implemented junrar jar file and used to unrar files and show image files in pager in asynctask(background), I have downloaded several cbr comic books and unrared it, There was no problem at all, While unraring this file : comic file . I am getting below exception suddenly, (i.e) increase from 27mb to 240mb suddenly. Can you suggest me what would be the problem or any solution for this. I have given the sample code below.
FATAL EXCEPTION: Thread-610 Process: com.vthink.VReader, PID: 24545 java.lang.OutOfMemoryError: Failed to allocate a 233832633 byte allocation with 16777216 free bytes and 143MB until OOM at com.github.junrar.unpack.ppm.SubAllocator.startSubAllocator(SubAllocator.java:146) at com.github.junrar.unpack.ppm.ModelPPM.decodeInit(ModelPPM.java:215) at com.github.junrar.unpack.Unpack.readTables(Unpack.java:652) at com.github.junrar.unpack.Unpack.unpack29(Unpack.java:161) at com.github.junrar.unpack.Unpack.doUnpack(Unpack.java:116) at com.github.junrar.Archive.doExtractFile(Archive.java:501) at com.github.junrar.Archive.extractFile(Archive.java:443) at com.github.junrar.Archive$1.run(Archive.java:474) at java.lang.Thread.run(Thread.java:818)
Code Used:
for (int i = 0; i < numOfPages; i++) { //setLoadingBookNameAndCount(folderName, i, numOfPages); currentProgressPercentage = Utils.percentageCalc(numOfPages, i); setLoadingPercentage(Utils.percentageCalc(numOfPages, i)); fileHeader = mPages.get(i); try { in = archive.getInputStream(fileHeader); BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; BitmapFactory.decodeStream(in, null, options); options.inSampleSize = calculateInSampleSize(options, screenWidth, screenHeight); options.inJustDecodeBounds = false; options.inPreferredConfig = Bitmap.Config.ARGB_8888; try { in.close(); } catch (Exception e) { e.printStackTrace(); } in = archive.getInputStream(fileHeader); bitmap = BitmapFactory.decodeStream(in, null, options); imgPaths[i] = String.valueOf(saveImage(bitmap, folderName, i)); BookPageInfo bookPageInfo = new BookPageInfo(imgPaths[i], false); bookPageInfoArrayList.add(bookPageInfo); if (bitmap != null) { bitmap.recycle(); } }catch (Exception e){ e.printStackTrace(); } } }

It could maybe be avoided by internal bookeeping in the class that would save the location of the stream at the current time, and skip the intervening fileheaders or reset the stream if location > desired location.

Meanwhile, i'm using workaround that does that, but it requires me to juggle the pipedinput/output streams required for getInputStream function myself, which complicates the code, to say the least.

I'd be great if the junrar.jar would contain a /META-INF/vfs-providers.xml so that the VFS2 RAR provider can be added simply by dropping the jar into the classpath.

<providers>
    <provider class-name="com.github.junrar.vfs2.provider.rar.RARFileProvider">
        <scheme name="rar" />
    </provider>
    <extension-map extension="rar" scheme="rar" />
    <mime-type-map mime-type="application/rar" scheme="rar" />
</providers>

Please help me every time i am getting error "mainheader is null"

Hello, it's very kind of you to share this project. However, when I use this jar to implement the function in my app，I encounter a problem. The exception is described as follow:

Would you kindly provide a solution to this problem?

I personally invested a bit of time on this repo when the fork is the actual up-to-date version

Hi
Why we are not getting any response from the team for fixing the issues.Long back i raised two issues
still i didn't received any solution from the team.

Fix

/testutil/pom.xml:
1.
<mainClass>
de.innosystec.unrar.testutil.JUnRarTestUtil
</mainClass>
<packageName>
de.innosystec.unrar.testutil
</packageName>

<mainClass>
	com.github.junrar.testutil.JUnRarTestUtil
</mainClass>
<packageName>
	com.github.junrar.testutil
</packageName>

<dependency>
<groupId>com.github.junrar</groupId>
<artifactId>junrar</artifactId>
<version>0.6-SNAPSHOT</version>
</dependency>

<dependency>
	<groupId>com.github.beothorn</groupId>
	<artifactId>junrar</artifactId>
	<version>0.7-SNAPSHOT</version>
</dependency>

/unrar/src/main/java/com/github/junrar/rarfile/UnixOwnersHeader.java
3.
@see de.innosystec.unrar.rarfile.SubBlockHeader#print()
@see com.github.junrar.rarfile.SubBlockHeader#print()

On my project I'm using the class ExtractArchive that is on the testutil module. It seems that this class could be moved to the unrar module, and JUnRarTestUtil.java could go to src/test on unrar too, if the generate-testdata.sh was converted to java.
This would make it easier to import/deploy junrar.
Is it ok to do this?
Thanks

在springb-boot项目中出现
java.io.FileNotFoundException: C:\Users\my.m2\repository\com\github\junrar\junrar\4.0.0\commons-vfs2-2.2.jar (系统找不到指定的文件。)

I don't think eclipse specific project files should be included into the repository. They are volatile and sometimes not compatible with older versions of eclipse. Besides the fact that other might not use Eclipse at all.

Instead, I propose that should be encouraged the usage of Maven 2 eclipse plugin (Right click project -> Maven -> Update project configuration) or, as a last resort, the maven eclipse plugin (mvn eclipse:eclipse) to generate project files.

using the library in an android app and in a 10mb rar, it takes like a 1-2 minutes to extra 600k image file. Not sure if i'm compiling this correctly since there is another project that uses junrar and it extract it's very fast but if I compile the other app myself, it runs very slowly as well.

Hi,

It appears the junjar has problem to work on some type of files. For example with my libfontmanager.rar, which is just created by winrar4.01. It includes two files, one is
libfontmanager.so, which is a linux .so file from the jdk binary, other is the text file jvm.cfg.

junjar works fine with jvm.cfg, but throws an exception for the libfontmanger.so. This is
not the only one that junjar does not like, when try to junjar a .rar file including the whole
linux jdk binary (with source and all the binaries), it fails on lots of .so files, though works
fine as well on the rest (including lots of .so file as well).

It appears the crc32 calculation is correct, the output bytes of the libfontmanager.so indeed
has different bits compare to its source. So I guess something is wrong during the decoding.

I don't know how to upload the test case libfontmanager.rar here, so I parked it at

http://www.filedropper.com/libfontmanager

It should be safe to download that file by clicking "Download this file". Let me know if an email with an attachment is more comfortable, the .rar file is about 100K.

Thanks!
-Xueming

$ /cygdrive/d/jdk6/bin/java -cp "./target/java-unrar-0.6-SNAPSHOT.jar;./" Test test/libfontmanager
.rar dst
extracting: libfontmanager.so
de.innosystec.unrar.exception.RarException: crcError
at de.innosystec.unrar.Archive.doExtractFile(Archive.java:473)
at de.innosystec.unrar.Archive.extractFile(Archive.java:443)
at Test.extractArchive(Test.java:82)
at Test.extractArchive(Test.java:38)
at Test.main(Test.java:43)
extracting: jvm.cfg

http://www.filedropper.com/libfontmanager

I tried this with two different files when I pass path of a password encrypted file. The result is false.
Please see if anything can be done.

surpport rar5?

Hi
I am dealing with legals in order to use Junrar as 3'd party.
I come across two authors : "alpha_lam" and "alban" that are not registered jUnrar contributors.
Can you please shed some light on this (to the origin of the contributes and code)?

Thanks a lot.

Michael

Linux System \ spliter can not recognize

Trying to run the mvn package-produced .jar fails, without dep:unrar

Static compile
Add to /testutil/pom.xml:

<plugin>
	<artifactId>maven-assembly-plugin</artifactId>
	<configuration>
		<archive>
			<manifest>
				<mainClass>com.github.junrar.testutil.JUnRarTestUtil</mainClass>
			</manifest>
		</archive>
		<descriptorRefs>
			<descriptorRef>jar-with-dependencies</descriptorRef>
		</descriptorRefs>
	</configuration>
</plugin>

compile: $ mvn clean compile assembly:single
run: $ java -jar target/junrar-testutil-0.1-jar-with-dependencies.jar

I just pulled the current code and build it to update our application using junrar.
Looks like the dependency on ij is gone since the single class used from that jar has been copied into junrar itself.

I was trying decompress Rar file i revived below exception, most of the files are able decompress sucessfully,but few rar files are not able to extract. is any solution you have?

01-01 17:41:32.121: E/AndroidRuntime(12799): FATAL EXCEPTION: Thread-771
01-01 17:41:32.121: E/AndroidRuntime(12799): java.lang.OutOfMemoryError
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.unpack.ppm.SubAllocator.startSubAllocator(SubAllocator.java:146)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.unpack.ppm.ModelPPM.decodeInit(ModelPPM.java:216)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.unpack.Unpack.readTables(Unpack.java:656)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.unpack.Unpack.unpack29(Unpack.java:165)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.unpack.Unpack.doUnpack(Unpack.java:120)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.Archive.doExtractFile(Archive.java:500)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.Archive.extractFile(Archive.java:442)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.testutil.ExtractArchive.extractArchive(ExtractArchive.java:73)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.github.junrar.testutil.ExtractArchive.extractArchive(ExtractArchive.java:29)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.letusread.util.DeCompressUtil.deCompress(DeCompressUtil.java:140)
01-01 17:41:32.121: E/AndroidRuntime(12799): at com.letusread.activity.FileListActivity$7.run(FileListActivity.java:338)
01-01 17:41:32.121: E/AndroidRuntime(12799): at java.lang.Thread.run(Thread.java:856)
01-01 17:41:32.324: E/MobclickAgent(12799): onEndSession called before onStartSession

rar 5.0 archive format defines new signature:
RAR 5.0 signature consists of 8 bytes: 0x52 0x61 0x72 0x21 0x1A 0x07 0x01 0x00. You need to search for this signature in supposed archive from beginning and up to maximum SFX module size. Just for comparison this is RAR 4.x 7 byte length signature: 0x52 0x61 0x72 0x21 0x1A 0x07 0x00.

but junrar has not supported the v5.0 signature yet
Please update junrar src code /com/github/com/junrar/rarfile/MarkHeader.java: isSignature() to support it

I downloaded the code of JUnrar 4 years ago because the author of HelloNzb refused to activate JUnrar in his program. This was because JUnrar seemed to have problems with certain rar files. So I downloaded the C code of unrar and tried to debug the Java code of JUnrar. In the process I updated the code of JUnrar a bit to be more on par with the downloaded C version of the code. So there have been a few updates in that area (see changes in unpack.java). I did not work on it for 4 years, but today I thought it was time to finally settle the issues with JUnrar. So what steps did I take:
1: I replaced all >> operators by >>> operators. This because the Java equivalent of the C >> operator is the >>> operator. Using the >> operator in Java, causes the sign bit to be left inserted when shifting right. This did not solve the problems in my testcase (but I did leave the modifications in place), so we did go further with the next step:
2: Extensively debugging. After hours of hard work, this brought the solution. There was a bug in RarVM.java. Look at line 932:

if (curByte==0xe8 || curByte==cmpByte2)

especially "curByte==0xe8". curByte is of type Byte and the value range is -128 to 127 in Java. So the condition will always be false. This is not a problem when filterType is VMSF_E8. But in the case of filterType is VMSF_E8E9, the javacode behaves different then the C counterpart. So I changed it to:

if (curByte==((byte)0xe8) || curByte==cmpByte2)

I searched the code on simular bugs and found another one in MarkHeader.java line 70:

else if (d[1]==0x61 && d[2]==0x72 && d[3]==0x21 && d[4]==0x1a &&

is changed in

else if (d[1]==0x61 && d[2]==0x72 && d[3]==0x21 && d[4]==((byte)0x1a) &&

The first modification in step 2 already fixed my problems with JUnrar. So I hope you will accept my changes for the repository.

With kind regards,

Roy Damman