extractFilesTo path bug

[andre-alves]

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!

[abbeycode]

Interesting... Now, the difference between the * and *W variants is using char vs. wchar, respectively. wchar is required for full unicode support. the unicharsFromString() method uses a specific UTF-32 (little endian) encoding, because the archives I had tested with used that encoding. May I ask what app created the test archive you linked? The spec does state that the file names should be in UTF-8. I'll have to update unicharsFromString() to more intelligently guess the encoding.

[andre-alves]

I used WinRAR 5.20 64bits for Windows (Portuguese Brazilian).

The file i provided in issue #19 also was created using this app and has the bug. Every rar that i tested (downloaded from the internet) had the bug.

Thanks for the quick reply.

[abbeycode]

I added the linked archive to the Test Data folder (named Test Archive (RAR5).rar), and added a couple of unit tests against it, that both are passing. I did this in a new issue20 branch. Could you submit a pull request or comment on this issue detailing how to get these tests to break as you described?

testExtractFiles_RAR5
testListFilenames_RAR5

[andre-alves]

Sorry, i don't know very well how to use all the features of github.
I created a new repository here: https://github.com/SkiesOFF/UnrarKitBugTest

What i did:
-> Clean new Xcode 6.3.2 project
-> Pod install only with UnrarKit
-> In AppDelegate.m i created a easy test case, trying to extract a .rar file.
-> I print the files inside the folder before and after extraction.

The bug don't happens all the time. Expected logs (without bug):

Logs when the bug happens:

As you can see, there is a lot of trash in one of the rarWithoutPassword folder's name, It created 2 folders, one for each file inside the archive.

I needed to try 4+- times to catch the bug. I cleaned the simulator folder everytime.

Please, download the repository, i think it's just build and run.
Sorry for my bad english and thanks for your time.

[abbeycode]

Have you tried a destination that's not inside your app bundle? You probably shouldn't be modifying that at runtime.

It'd be a lot easier to see this in a test case. I can help you with forking, if you haven't done it before. You basically click the "Fork" button, which makes a copy of the repo in your own account, and then you clone that, make your changes, and push.

This is GitHub's guide: https://guides.github.com/activities/forking/

[andre-alves]

I forked and tried but i couldn't reproduce the bug in your test unit. Maybe is the folder i'm using?

I updated my repository to use the /Documents with this code:

- (NSURL *)documentsDirectory {

    NSString *docsPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
    NSURL* docsDirectory = [NSURL fileURLWithPath:docsPath isDirectory:YES];

    return docsDirectory;
}

The bug still happens sometimes:

Thanks.

[abbeycode]

I wonder if it's an iOS vs. Mac thing. The unit test runs on Mac. I'll take another look and let you know when I have something.

[andre-alves]

What would be the problem with the fix i suggested in the first comment? I thought it would mess with the unicode but i tested with this filenames and worked 100%:

Ⓣest Ⓐrchive.rar
rarWithoutPassword.rar
rarWithéçPassword.rar
rar★WitΨhéçPassword.rar
ⓉestУ ⒶrcдiЦe.rar

It seems to be working with the Test Cases too (testExtractFiles_Unicode and testExtractFiles).

Thanks.

[abbeycode]

You're right, that doesn't break any existing unit tests, and it is fairly limited in scope. I do prefer to have a test case demonstrating a problem before adding a fix, though. I'm going to try to reproduce it a little longer, but if I'm unable, then I'll push out the fix without a test case.

[abbeycode]

I added an iOS test bundle, and I'm still not seeing any problems. I updated the test to extract your test archive 500 times in a loop, and it passes. Can you verify whether the test works for you also?

[andre-alves]

Yes, i tested and it works too. I even pasted the code from my repository to your test case and still works. Everything is equal (folder, file, code), i simple can't make it work in any other project, even a new one.

I might create a "local fix" for me, unfortunately.

Thank you very much for your time, really appreciated the help.

[abbeycode]

No problem, and I don't mind working with you to try to continue figuring out what's wrong - there's definitely something wrong somewhere. How are you installing UnrarKit in your new projects?

[andre-alves]

Open Xcode 6.3.2 -> Create a new Xcode Project -> IOS Single View Application -> Language: Objective-C, Devices: Universal. Project created.

Quit Xcode, go to project folder in terminal, -> pod init -> open -a Xcode Podfile. Edit:

https://github.com/SkiesOFF/UnrarKitBugTest/blob/master/UnrarKitBugTest/Podfile

Save, close, pod install, wait and open the project with .xcworkspace.

[abbeycode]

Ah ha! I see it now. I'll take a look at the projects and see what's not configured the same. Looking at the output, though, it looks like it must be something in the text of "yohoho_ws.txt". That's the only one that ever ends up in the wrong directory.

[abbeycode]

So, stepping through the new text project in the debugger, I see that sometimes the result of unicharsFromString() gets padded with a bunch of 0xFFFD (�) characters. Those then don't get translated properly by dll.cpp's call to wcsncpy().

[abbeycode]

I released your fix in v2.5, which is now out on CocoaPods

[andre-alves]

Thank you.