-
Notifications
You must be signed in to change notification settings - Fork 483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rar 5 format #310
Rar 5 format #310
Conversation
Fix rar 5 format comment
Do you plan on doing more? |
I have made IsRar5 function but still not implement. |
But really nit have any free time to implement rar5 compatibility. Can we get from 7zip or 7zip.sharp projects? |
Hi Adam, I may have some bandwidth to help work on Rar5 support. Do you have a sense for how much work is involved or how to proceed? I see that rarlabs has open sourced the rar5 unrar source code in C. Would the plan be to port this code? I also noticed there is a rar5 branch in SharpCompress but I'm not sure what the status of that branch is. -Brien |
The RAR5 branch is nothing basically. Really the work should just be implementing reading the headers: https://www.rarlab.com/technote.htm So the work isn't so bad. I think the decompression is all the same but that needs to be tested. |
So just parse the headers and use the existing RAR4 decompression code? Sounds like work on the order of days to weeks... or am I being optimistic? EDIT ----- |
I believe that's the work. It shouldn't be too bad. I think you're not far off on the estimated time :) |
Ok... so just so I have this straight, RAR5 is primarily a change to the archive format and the decompression algorithm has not changed??? So any compression gains are via algo params and/or archive format efficiency? |
That's my understanding. I think he just didn't like the header format and it was a little bit of a mess. Honestly though, I'm scared I'm wrong about the algorithm not changing but it needs testing. |
I'm going to try to get in touch with the winrar developers to get some confirmation (emailed [email protected]). For reference here's a list of updates from wikipedia:
|
hey adam- i'm running devstudio 2017 (latest patch) with resharper 2017.2.2. i had to edit the sharpcompress csproj to remove the net35 target since it's not installed on my machine. the solution compiles fine but for some reason resharper sees a bunch of unresolved calls from the test project to sharpcompress, eg entry.WriteToDirectory() shows up as red even though i can Ctrl-B and follow the reference fine. i deleted my resharper cache and restarted to no avail. when i try to "Run" any [Fact] from the test project it fails with the dump below. any tips to getting this setup? thanks!
|
disregard.... figured it out (cache clearing and extension disabling fixed it) |
marathon coding session and most of the header logic is done. i assume you are ok with the winrar source license terms (particularly clause #2) as it seems as though the unpack*.cs source code was already ported from it. i'll have to port unpack50.cpp over for RAR5 support.
|
Impressive! I converted the unrar code from the java version. But yes, no problem with keeping everything free and open source :) |
hey adam so.... it's going to be a monster of a patch when it's done. i've done an initial port and no debugging of the rarlabs unpack5 code but unsuprisingly it doesn't quite work, my approach was just to pull in the minimum amount of code and try to integrate it with the existing stuff that came via your port of junrar. i think it may not be worth the debugging effort to fix the code though because the unpack15/unpack2/upack5 code is pretty tightly integrated and the end result would be pretty untrustworthy in my eyes. some examples of issues are liberties taken when junrar ported to java (lack of unsigned types/casting); the current unrar codebase uses size_t in places and supports buffers up to 4GB. it would also be unproductive to try to identify and reapply all code changes over the past ~10 years to the unrar codebase. so, that's just a really long explanation leading up to my thought that i'd be better off just re-porting the entire unpack codebase afresh directly from the unrar cpp codebase. i'd use the current code as a guide so i'm not that intimidated by the idea. so.... will you have any issues accepting a megapatch that is basically a rewrite of the unrar stuff? or would you like me to approach it differently somehow? |
I just pushed the code to my repository if you want to take a peek. |
Doing a fresh port would be great. I never attempted to do that myself because of time and lack of experience reading C++ Once things are looking closer to being complete, I can review or help. My personal life is a mess at the moment otherwise I'd volunteer to do more. |
@coderb you still working on this? I'm interested in pushing this along if possible. |
hey adam, i need to fill in the following:
the branch implements the new code side by side with the old code, so if desired it could be pulled into the main branch at any time. it is enabled / disabled via the call to new Unpack() in RarArchive and RarReader. -brien |
Yeah I ran into the Unpack30 build issues. I'll have to stare harder at this at another time. Thanks for the work. It will be nice to have a fresh port. Hopefully, it performs well as a fresh port. |
you should be able to it to build if you define RarV2017_RAR5ONLY which excludes the older algos from the new implementation. |
@coderb I'm being lazy and integrating the legacy with your new port to cover the V3 case. There are some missing test files you had. Other than that and fixing up encryption, it's working well. |
that's cool. i didn't really mean to leave it like that but just got too busy with the real world. if you tell me which files are missing i can provide them. -b |
@coderb thanks! the files are:
|
hmm, it's been a while...
|
Fix rar 5 format comment