Works in simulator, doesn't work on real device. The strangest thing is it is "compiled successfully" but the app is not installed on the device. Log:

dyld: Library not loaded: @rpath/UnrarKit.framework/UnrarKit
Referenced from: /var/mobile/Containers/Bundle/Application/0FEBCED9-848A-4262-9399-7AA060C61F3E/UnrarExample.app/UnrarExample
Reason: image not found

If rar l lists a discrete directory for the archive, then all files after it get skipped.

int CALLBACK CallbackProc(UINT msg, long UserData, long P1, long P2)
int CALLBACK BufferedReadCallbackProc(UINT msg, long UserData, long P1, long P2)
These functions can be accessed from the code inside URKArchive.mm.
What about to add a public way to access them? For example I want to customize UCM_CHANGEVOLUME event

The documentation is here: https://developer.apple.com/reference/os/1891852-logging

Switch logging to use a new macro (URKLog), with an ifdef that uses the existing NSLog behavior on older OS versions. All logging should happen on a custom logger whose identifier is published on the readme. The macro should take the log level as the first argument, and insert it as a string into the NSLog fallback.

Hi ,
when I install UnrarKit in my project (with cocoa pod) ,
and import UnrarKit through a bridging header :

import "UnrarKit/UnrarKit.h"

I get those error :
for archive.hpp
archive.hpp:4:1: Unknown type name 'class'; did you mean 'Class’?
archive.hpp:5:1: Unknown type name 'class'; did you mean 'Class’?
archive.hpp:6:1: Unknown type name 'class'; did you mean 'Class’?
archive.hpp:23:1: Unknown type name 'class'; did you mean 'Class'?
archive.hpp:23:26: Expected ';' after top level declarator
archive.hpp:23:15: Unknown type name ‘public'

for array.hpp
array.hpp:4:8: Unknown type name 'ErrorHandler'; did you mean 'ProcHandle’?
array.hpp:6:1: Unknown type name ‘template'
array.hpp:6:10: Expected identifier or ‘('
array.hpp:33:1: Unknown type name ‘template'
array.hpp:33:10: Expected identifier or ‘('
array.hpp:42:1: Unknown type name ‘template'
array.hpp:42:10: Expected identifier or ‘('
array.hpp:48:1: Unknown type name ‘template'
array.hpp:48:10: Expected identifier or ‘('
array.hpp:56:1: Unknown type name ‘template'
array.hpp:56:10: Expected identifier or ‘('
array.hpp:65:1: Unknown type name ‘template'

then for my bridging header :
Too many errors emitted, stopping now

can you help me ?

PS: I don't think the problem come from the code I think the compiler act like the files .hpp are Objective C and not C++ code .

Hello guy, thank you create this lib. I want compress files by lib without a password or have a password. You can show me exam syntax code thank so much

http://blog.cocoapods.org/CocoaPods-0.38/

I cant extract password protected files, give me URKErrorCodeUnknown

[!] Unable to find a target named Demo
[!] Unable to find a target named DemoTests

I don't have another unrar library.
How to fix it?

Undefined symbols for architecture i386:
"std::bad_alloc::bad_alloc()", referenced from:
FragmentedWindow::Init(unsigned long) in libPods-UnrarKit.a(unpack.o)
Unpack::Init(unsigned long, bool) in libPods-UnrarKit.a(unpack.o)
"std::bad_alloc::~bad_alloc()", referenced from:
FragmentedWindow::Init(unsigned long) in libPods-UnrarKit.a(unpack.o)
Unpack::Init(unsigned long, bool) in libPods-UnrarKit.a(unpack.o)
"std::terminate()", referenced from:
___clang_call_terminate in libPods-UnrarKit.a(URKArchive.o)
___clang_call_terminate in libPods-UnrarKit.a(dll.o)
___clang_call_terminate in libPods-UnrarKit.a(secpassword.o)
___clang_call_terminate in libPods-UnrarKit.a(extract.o)
___clang_call_terminate in libPods-UnrarKit.a(options.o)
___clang_call_terminate in libPods-UnrarKit.a(strlist.o)
___clang_call_terminate in libPods-UnrarKit.a(cmddata.o)
...
"typeinfo for std::bad_alloc", referenced from:
GCC_except_table1 in libPods-UnrarKit.a(dll.o)
GCC_except_table19 in libPods-UnrarKit.a(dll.o)
FragmentedWindow::Init(unsigned long) in libPods-UnrarKit.a(unpack.o)
Unpack::Init(unsigned long, bool) in libPods-UnrarKit.a(unpack.o)
GCC_except_table1 in libPods-UnrarKit.a(dll.o)
GCC_except_table19 in libPods-UnrarKit.a(dll.o)
FragmentedWindow::Init(unsigned long) in libPods-UnrarKit.a(unpack.o)
Unpack::Init(unsigned long, bool) in libPods-UnrarKit.a(unpack.o)
"vtable for __cxxabiv1::__enum_type_info", referenced from:
typeinfo for RAR_EXIT in libPods-UnrarKit.a(dll.o)
typeinfo for RAR_EXIT in libPods-UnrarKit.a(errhnd.o)
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"vtable for __cxxabiv1::__class_type_info", referenced from:
typeinfo for File in libPods-UnrarKit.a(file.o)
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"vtable for cxxabiv1::si_class_type_info", referenced from:
typeinfo for Archive in libPods-UnrarKit.a(archive.o)
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"operator delete", referenced from:
QuickOpen::~QuickOpen() in libPods-UnrarKit.a(qopen.o)
QuickOpen::Close() in libPods-UnrarKit.a(qopen.o)
RarVM::~RarVM() in libPods-UnrarKit.a(rarvm.o)
BitInput::~BitInput() in libPods-UnrarKit.a(getbits.o)
BitInput::SetExternalBuffer(unsigned char) in libPods-UnrarKit.a(getbits.o)
"operator delete(void)", referenced from:
-[URKArchive closeFile] in libPods-UnrarKit.a(URKArchive.o)
RAROpenArchiveEx in libPods-UnrarKit.a(dll.o)
RARCloseArchive in libPods-UnrarKit.a(dll.o)
CmdExtract::CmdExtract(CommandData) in libPods-UnrarKit.a(extract.o)
CmdExtract::~CmdExtract() in libPods-UnrarKit.a(extract.o)
File::~File() in libPods-UnrarKit.a(file.o)
Archive::Archive(RAROptions) in libPods-UnrarKit.a(archive.o)
...
"operator new[](unsigned long)", referenced from:
-[URKArchive unrarOpenFile:inMode:withPassword:error:] in libPods-UnrarKit.a(URKArchive.o)
QuickOpen::Init(Archive, bool) in libPods-UnrarKit.a(qopen.o)
RarVM::Init() in libPods-UnrarKit.a(rarvm.o)
BitInput::BitInput(bool) in libPods-UnrarKit.a(getbits.o)
"operator new(unsigned long)", referenced from:
-[URKArchive unrarOpenFile:inMode:withPassword:error:] in libPods-UnrarKit.a(URKArchive.o)
RAROpenArchiveEx in libPods-UnrarKit.a(dll.o)
CmdExtract::CmdExtract(CommandData) in libPods-UnrarKit.a(extract.o)
Archive::Archive(RAROptions) in libPods-UnrarKit.a(archive.o)
Unpack::AddVMCode(unsigned int, unsigned char, int) in libPods-UnrarKit.a(unpack.o)
ScanTree::FindProc(FindData) in libPods-UnrarKit.a(scantree.o)
"___cxa_allocate_exception", referenced from:
ErrorHandler::Throw(RAR_EXIT) in libPods-UnrarKit.a(errhnd.o)
FragmentedWindow::Init(unsigned long) in libPods-UnrarKit.a(unpack.o)
Unpack::Init(unsigned long, bool) in libPods-UnrarKit.a(unpack.o)
"___cxa_begin_catch", referenced from:
clang_call_terminate in libPods-UnrarKit.a(URKArchive.o)
RAROpenArchiveEx in libPods-UnrarKit.a(dll.o)
RARReadHeaderEx in libPods-UnrarKit.a(dll.o)
ProcessFile(void, int, char, char, wchar_t, wchar_t) in libPods-UnrarKit.a(dll.o)
___clang_call_terminate in libPods-UnrarKit.a(dll.o)
___clang_call_terminate in libPods-UnrarKit.a(secpassword.o)
___clang_call_terminate in libPods-UnrarKit.a(extract.o)
...
"_cxa_end_catch", referenced from:
RAROpenArchiveEx in libPods-UnrarKit.a(dll.o)
RARReadHeaderEx in libPods-UnrarKit.a(dll.o)
ProcessFile(void, int, char, char, wchar_t, wchar_t*) in libPods-UnrarKit.a(dll.o)
"___cxa_throw", referenced from:
ErrorHandler::Throw(RAR_EXIT) in libPods-UnrarKit.a(errhnd.o)
FragmentedWindow::Init(unsigned long) in libPods-UnrarKit.a(unpack.o)
Unpack::Init(unsigned long, bool) in libPods-UnrarKit.a(unpack.o)
"___gxx_personality_v0", referenced from:
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(URKArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(dll.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(pathfn.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(secpassword.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(extract.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(options.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(strlist.o)
...
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(URKArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(dll.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(pathfn.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(secpassword.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(extract.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(options.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(strlist.o)
...
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(URKArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(dll.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(pathfn.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(secpassword.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(extract.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(options.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(strlist.o)
...
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(URKArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(dll.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(pathfn.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(secpassword.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(extract.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(options.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(strlist.o)
...
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(URKArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(dll.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(pathfn.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(secpassword.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(extract.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(options.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(strlist.o)
...
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(URKArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(dll.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(pathfn.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(secpassword.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(extract.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(options.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(strlist.o)
...
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(URKArchive.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(dll.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(pathfn.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(secpassword.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(extract.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(options.o)
Dwarf Exception Unwind Info (__eh_frame) in libPods-UnrarKit.a(strlist.o)
...
...
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

As long as the build is for a tag, and there were no issues, push to CocoaPods. This link to Travis documentation and an answer to my question on Stack Overflow should provide enough info to do this.

It should only push if:

1. All matrixed jobs have completed successfully

2. The current build is tagged (TRAVIS_TAG var)

3. The tag matches the podspec's version number

4. The branch name is "master", or it's a pre-release build

   Turns out this isn't possible to check, since tag builds don't know their branch, only the tag name. Instead, validate that the tag looks like a version number (e.g. #.#.#(-beta#))

Steps:

• Set up a branch to test this out
• Update the Travis script in the branch with the changes above, set to echo instead of pushing to CocoaPods (this page provides the right way to go, until/unless CocoaPods gets fully supported by Travis)
• Test that the echo runs
• Test that any failures don't trigger the echo. Specifically:
• a. Build failure
• b. Test failure
• c. Post-test validation failure
• Get the configuration right, with API keys and so on
• Replace the Podspec version number with $TRAVIS_TAG
• Write a script to update the plist's version number's and tag the build
• Clean up the various tags created during dev and testing
• Push a test build
• Add a script to push the release to GitHub
• Move the updated .travis.yml and any scripts over to master

Following UnzipKit's example, localize all strings to a resource bundle distributed with the framework.

Steps to reproduce

1. Begin extracting the contents of an archive
2. Move the file to a different directory before finishing extraction

Expected

Best case: the extraction seamlessly completes
Next best: file move is blocked, so the file can't be moved until UnrarKit is done with it
Last resort: Return an error code.

If the archive is deleted during extraction (via, say, an rm in Terminal, since moving to the Trash is just a file move as described above), an error should be returned (a distinct code from the one defined in the "last resort" case.

Actual

As soon as the file is moved, 0 bytes are returned for the remainder of the file that was in progress, and for the entirety of the remaining files.

hi,
please replace
int PFCode = RARProcessFile(_rarFile, RAR_SKIP, NULL, NULL);
instead of
int PFCode = RARProcessFile(_rarFile, RAR_TEST, NULL, NULL);
in (BOOL)isPasswordProtected
to speed up checking

Make URKArchive implement NSProgressReporting on OS X >= 10.11 and iOS >= 9.0, and support implicit progress reporting for earlier OSes.

https://developer.apple.com/videos/play/wwdc2015/232/

Remaining tasks:

• Add NSProgress support to all top-level methods
• For extraction to disk, add passing of the current file info to NSProgress
• Add section to Readme describing sample NSProgress usage and cancellation
• Deprecate the methods that use a progressBlock argument, mentioning migration to NSProgress
• Update documentation

Add support for the Carthage decentralized dependency manager.

• Evaluate the degree to which it already works
• Add metadata necessary to make it fully work

it is nice to have a separate method for checkIntegrity via this RAR_TEST option.
also for UnzipKit via CRC check

I think that UnrarKit should try to see if it is possible to "unfork" it's repo from Unrar4iOS. Some reasons for this change would be:

• UnrarKit has become a project onto it's own. The two codebases have diverged greatly and are unlikely to join paths again.
• GitHub restricts certain features from forked repos (such as repo search)
• Contributors looking to submit PRs to UnrarKit must always put up with their pull requests defaulting to the master repo (Unrar4iOS). This is confusing and has already lead to me almost submitting a PR to the wrong repo.

There is a CocoaPods blog post detailing how to do so.

I recently discovered the "Supported Platforms" build setting. I should use that to make a single cross-platform framework and unit test bundle. This will make the project easier to maintain going forward.

• Update project's supported platforms
• Make UnrarKit target support all platforms
• Once everything's working right for macOS and iOS with the unified targets, drop the iOS-specific targets

Right now, we can decompress the entire RAR archive or we can decompress a single file in the archive entirely into memory.

Ideally, it would be nice to be able to read a single file but not entirely into memory at once. Using a read-then-write buffer would allow us to extract individual files of an arbitrary length without hitting the iOS memory limits.

Here an example of how the objective-zip library handles this.

This would be a really nice enhancement of this library. Thanks for your work maintaining UnrarKit!

It enough complex code but you made it private. It is even not separated into the method

It should be under 10 MB, since it's getting dinged by the CocoaPods quality check. The culprits are two CBR files stored with the example project, which can be dumped altogether, and the Large Archive file used for testing, which can possibly be generated as part of the unit test.

Causes a leak for each call, meaning if you extract each file from an archive, there will be that many leaks. This can cause an app to run out of file descriptors in short order.

Another potential enhancement would be for the listFiles method to return an NSArray of a URKFileInfo instead of just an array of NSString file paths .

This URKFileInfo could contain some more useful metadata that we have available to us in the RAR header via RARReadHeaderEx.

Perhaps something like:

typedef NS_OPTIONS(NSUInteger, URKFileFlags) {
    URKFileFlagsFileContinuedFromPreviousVolume     = 1 << 0,
    URKFileFlagsFileContinuedOnNextVolume           = 1 << 1,
    URKFileFlagsFileEncryptedWithPassword           = 1 << 2,
    URKFileFlagsFileCommentPresent                  = 1 << 3,
    // TODO: Add remaining FileFlags in that are specified in bits 7, 6, and 5
};

typedef NS_ENUM(NSUInteger, URKPackingMethod) {
    URKPackingMethodStorage                         = 0x30,
    URKPackingMethodFastestCompression              = 0x31,
    URKPackingMethodFastCompression                 = 0x32,
    URKPackingMethodNormalCompression               = 0x33,
    URKPackingMethodGoodCompression                 = 0x34,
    URKPackingMethodBestCompression                 = 0x35
};

typedef NS_ENUM(NSUInteger, URKHostOS) {
    URKHostOSMSDOS                                 = 0,
    URKHostOSOS2                                   = 1,
    URKHostOSWindows                               = 2,
    URKHostOSUnix                                  = 3
};

@interface URKFileInfo : NSObject
@property (nonatomic, strong) NSString *archiveName;
@property (nonatomic, strong) NSString *fileName;
@property (nonatomic, strong) NSDate *fileTime;
@property (nonatomic, assign) long long unpackedSize;
@property (nonatomic, assign) long long packedSize;
@property (nonatomic, assign) URKFileFlags flags;
@property (nonatomic, assign) URKPackingMethod method;
@property (nonatomic, assign) URKHostOS hostOS;
@end

Then in the listFiles method we could map these header properties:

       // ...
        while ((RHCode = RARReadHeaderEx(_rarFile, header)) == 0) {
            URKFileInfo *file = [[URKFileInfo alloc] init];
            file.fileName = [NSString stringWithCString:header->FileName encoding:NSASCIIStringEncoding];
            file.archiveName = [NSString stringWithCString:header->ArcName encoding:NSASCIIStringEncoding];
            file.unpackedSize = (long long) header->UnpSizeHigh << 32 | header->UnpSize;
            file.packedSize = (long long) header->PackSizeHigh << 32 | header->PackSize;

This page and this page spells out some of the fields that could be pulled from the header. Things like Archive Name, FileName, PackedSize, UnpackedSize, Modify Date, CRC Hash.

An example use case for this is if you wanted to display detailed information about the rar archive contents, or let them selectively choose which files they would like to unarchive. The more file metadata I have, and can display about these files the better.

Hello!

I'm trying to unrar this file (happens with others too):
https://www.dropbox.com/s/q0w8gatjobx2puq/rarWithoutPassword.rar?dl=0

I'm using the method extractFilesTo and for the destination path i'm creating a folder with the same name of the file

NSString *destination = [[file URLByDeletingPathExtension] path];

The extract is working, but there is a very strange bug. The rar i provided for download has 2 .txt on it and this is the result i got from its extraction:

It creates a folder for each file inside the rar. The last characters of the folder name always has strange charsets (this time is a japanese thing lol). This bug don't happens 100% all the times, but happens a lot.

I got a solution for this but probably it's not the right way to fix it, i really don't know what is causing this bug. (i'm testing in iOS Simulator, 8.3 - Xcode 6.3.2, installed UnrarKit from the cocoa pods
)

URKArchive.mm - Line 274

if ((PFCode = RARProcessFileW(_rarFile, RAR_EXTRACT, unicharsFromString(filePath), NULL)) != 0)

change to ->

if ((PFCode = RARProcessFile(_rarFile, RAR_EXTRACT, (char *) [filePath UTF8String], NULL)) != 0)

Thanks!

extractData:progress:error: and -extractDataFromFile:progress:error: are missing the nullable attribute, even though they return nil for error conditions. This should be especially helpful for Swift users.

I no longer need to use a third-party hack, as the built-in Build Stages feature now provides this functionality.

https://blog.travis-ci.com/2017-05-11-introducing-build-stages

There's a guide on the Carthage readme

I was able to build it for 10.9.
10.8- does not support NSProgress, so can't build for this one.

Hello,

The method validatePassword don't work if the archive is RAR5.

You can test using this archive (password is 123):
https://www.dropbox.com/s/rnl6y9jons1eiyp/rar5WithPassword.rar?dl=0

This happens because this if

if (RHCode == ERAR_MISSING_PASSWORD || PFCode == ERAR_MISSING_PASSWORD || RHCode == ERAR_BAD_DATA || PFCode == ERAR_BAD_DATA)
            return;

is not checking if PFCode is ERAR_BAD_PASSWORD, which is the value a rar5 with wrong password returns. So, change this if to ->

if (RHCode == ERAR_MISSING_PASSWORD || PFCode == ERAR_BAD_PASSWORD || PFCode == ERAR_MISSING_PASSWORD || RHCode == ERAR_BAD_DATA || PFCode == ERAR_BAD_DATA)
            return;

to fix this issue =).

Should those be URKLogDebug instead of URKLogInfo?

Hi,
After released iOS 10.3 update with the change of FileSystem from HFS+ to APFS, most of filename with Unicode characters are can't unzip. (Before this update, all things are work perfectly)

Based on Apple, to avoid the problem, try to "Use the fileSystemRepresentation property of NSURL objects when creating and opening files with lower-level filesystem APIs such as POSIX open(2), or when storing filenames externally from the filesystem".

I have digged into UnrarKit library and have tried alot but unsuccessful, can you help me with this problem.
Thank you very much!

(Detail problem link: https://eclecticlight.co/2017/04/06/apfs-is-currently-unusable-with-most-non-english-languages/)
(Zip file link: https://www.dropbox.com/s/hhtoxqixj24dejb/QR%E3%82%B3%E3%83%BC%E3%83%89.zip?dl=0)

Unless I'm missing something, I think right now there may be an issue if a user were to try and decompress an archive one file at a time due to not being able to tell if a URKFileInfo is a file or directory.

This edge case seems to only be an issue if you have empty directories. There is nothing to differentiate their filename from a file or folder (such as a trailing slash).

Here is an example archive:
https://dl.dropboxusercontent.com/u/638285/testrar.rar

It contains the following structure (note that URKFileInfo doesn't contain trailing slashes, they are here for demonstration only):

- testrar2/
- testrar2/testrar3/
- testfile

If I'm iterating through all the URKFileInfo objects, there will be 3 entries, and it is impossible for me to tell if testar2/testrar3 is a directory or a zero byte file (I think).

I believe that we can pull an isDirectory flag from the flags property of the RarReadHeaderEX, but I'm not entirely sure.

Hi,

the unrar library used in UnrarKit seems to be vulnerable to the following critical bug: https://bugs.chromium.org/p/project-zero/issues/detail?id=1286&can=1&q=unrar&desc=6

Could you please update UnrarKit to the latest unrar library?

Thx Jegge

Add the following methods:

- (void)performOnFilesInArchive:(void(^)(URKFileInfo *fileInfo, BOOL **stop))action
                          error:(NSError **)error;

- (void)performOnDataInArchive:(void(^)(URKFileInfo *fileInfo, NSData *fileData, BOOL **stop))action
                         error:(NSError **)error;

- (NSData *)extractDataFromFile:(URKFileInfo *) error:(NSError **)error;

in the file dll.cpp,Unknow type name 'HANDLE', it cannot run

It should contain an NSError* object, not a string, as it currently does. Use a different key, like NSLocalizedFailureReasonErrorKey, and bump the minor revision number, since this might break someone who's looking for the existing key.

When archiving an app using the framework, libunrar.a is exported. Skip install flag should be set as TRUE on unrar target build settings.

Also dll.hpp and raros.hpp libraries are exported, but I can't figure out how to skip those.

• Upgrade project
• Fix any new warnings
• Fix any broken test cases
• Fix any CocoaPods/Carthage validation problems

Add something akin to these overloads:

- (BOOL)extractFilesTo:(NSString *)filePath
             overWrite:(BOOL)overwrite
              progress:(void (^)(URKFileInfo *currentFile, CGFloat percentFileDecompressed, CGFloat percentArchiveDecompressed))progress
                 error:(NSError **)error;

- (NSData *)extractDataFromFile:(NSString *)filePath
                       progress:(void (^)(CGFloat percentDecompressed))progress
                          error:(NSError **)error;

At least for release, all non URKLogError or URKLogFault messages should be optional. Even those, since the functions printing this messages also return the NSErrorobject.

Maybe I'm missing something.

Since the multivolume check is now done on init, I think this property should be filled there.
Also would be useful to have another property like "firstVolumeNotFound", also filled on init.

I can code it if you think like.

Since now the framework includes this bundle, it should be necessary to build this first. Adding it to the UnrarKit framework target dependencies should be enough.

Also to UnrarKit iOS framework. I can't build it but i suppose it uses this bundle too.

Hi guy. Thank you create and support unbar lib . i'm use lib in swift and i got the problem, i can't extract file have password protected . this is my code

var archive : URKArchive?

do {
    archive = try URKArchive(path: files.filePath.path)
    let isPass =  archive?.isPasswordProtected();
    if isPass == true {
        try archive?.extractFiles(to: unzipURL.path, overwrite: true, progress: { (currenyFile, percentLoad) in
            if (percentLoad >= 1.0) {
                self.reloadFilesData()
            }
        })
    }
}
catch{

}

18:03:13.870928+0700 TheUnarchiver[50668:720439] [Common] _BSMachError: port 7c0f; (os/kern) invalid capability (0x14) "Unable to insert COPY_SEND"
2017-08-15 18:03:13.871261+0700 TheUnarchiver[50668:720439] [Common] _BSMachError: port 7c0f; (os/kern) invalid name (0xf) "Unable to deallocate send right"
please help me thank !!!

I'm bringing this issue over from ararog/Unrar4iOS#5.

I suspect this is because we use the FileName field from RARHeaderDataEx:

[NSString stringWithCString:header->FileName encoding:NSASCIIStringEncoding];

We should look at using FileNameW (UTF-8?) throughout UnrarKit so it can support unicode filenames.

Check the file's signature, which starts with "Rar!".

http://www.rarlab.com/technote.htm#arcstruct
http://en.wikipedia.org/wiki/List_of_file_signatures

This produces a ton of warnings, but the problem is I don't want any warnings reported for the unrar library. I can solve this by moving the unrar library into its own static library that'll get compiled in, I think. Then I'll specify -Weverything for UnrarKit, and -Wnone for unrar. This makes sense after #55, since it involves changing target configuration around.

• Split unrar into its own library, linked into UnrarKit
• Specify -Weverything for UnrarKit
• Fix all warnings produced