Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Zandro]

The newest version of cmpro x64 (4.012) contains an updated UnRar64.dll (5.0), which introduces a lockup/freeze scenario that pegs the CPU at max until cmpro is terminated.  This is caused by attempting to read, least from the Rebuilder, a multipart RAR that itself has been zipped or RAR'd. Example here. With the previous DLL version (4.20) it failed gracefully with the reported message: foo.part1_12345.rar got volume open error. Using the new DLL with an older version of cmpro does the same lockup, while using the old DLL with the new version of cmpro returns the error message.

[Roman]

well....it's the dll which comes with latest winrar....I will check this within the upcoming week....

[brun0]

I can confirm this issue

I was able to reproduce the problem on three different computers

[Roman]

haven't changed a single bit of my code...and only replaced the dll/lib part for compiling.....will see if I need to update the calls a bit...but I highly doubt it....

you may want to test the latest one here: http://www.rarlab.com/rar/UnRARDLL.exe

...I may have some limited time tonight or end of the week....

[Roman]

hmm...I cannot repeat the behaviour here.....(Win7, 64bit)....

I've used your (Zandro) test files, rebuilt them to a zip or to a rar...multiple times, scanned, nothing is locked....

Did I miss something?

[Zandro]

The issues persists with the 5.1 DLL. test.zip must not be decompressed. Target test.zip directly, not the contained RAR files it will attempt to decompress.

[Roman]

ah....now I see what you mean...it's the missing callback when it asks for a volume change (since a rar in a zip will be decompressed with a temporary name and it won't find the other part due to a different naming...)...

so here we go:

http://mamedev.emulab.it/clrmamepro/binaries/cmp20131216.rar

[Zandro]

We're back in operation! Thanks

[haynor666]

I've also noticed that with latest winrar clrmamepro does not wan't to remove files inside rar files but packing works good.

[Roman]

file removal from a rar file works fine here....

Be sure that you got winrar binary reachable (via %PATH%) and check Settings->Compressor->Rar if the delete cmd line is correctly set....

[Starshadow]

I've also noticed that with latest winrar clrmamepro does not wan't to remove files inside rar files but packing works good.

I'm encountering this as well, with WinRAR 5.01 x64 and clrmamepro 4.012 x64. It does not occur in clrmamepro 4.011a with WinRAR unchanged.

I've built a test dat and then rarred the files in various ways. (Dat attached, rar files Here.) Extract the rar files from the zip to a folder and then rebuild the dat with that folder as the source and "Remove Matched Sourcefiles" checked.

Rebuilding under clrmamepro 4.011a, everything behaves as expected. file5 is deleted from the rar file but the rar file itself is not deleted because it contained other files. file6's rar file is untouched because it is a multi-part rar file that contained other files. All other rar files are deleted.

Under clrmamepro 4.012 however, the results are different. file1 is deleted from the rar file, but the rar file itself is not deleted leaving a rar file containing only an empty folder. file2, file3, file4 and file6 are not deleted at all (Produces warning message: "can't remove file(s) from..."). file5 is the only one that is deleted in the same way as under 4.011a.

[Roman]

hmmm....looks like the updated rar lib got some problems with getting the correct rar-part names...I got the filename in the filename fields AND in the archive name fields...where I usually expect the part name...looks a bit odd....

well, the wrong name leads to the remove failure...
will check the lib...

[Roman]

ok...changed the way to get the volume names (also via callback)....
http://mamedev.emulab.it/clrmamepro/binaries/cmp20131220.rar

modifying multi-part-rar files seems to fail though...but this is a general limitation (if I run it from a commandline I get the same error)....hmm...don't know if that was different in the past.

[Starshadow]

ok...changed the way to get the volume names (also via callback)....
http://mamedev.emulab.it/clrmamepro/binaries/cmp20131220.rar

Sorry, but the only difference I see running this build is that part 2 and 3 of file4's rar get deleted, but not part 1. Everything else is the same.

modifying multi-part-rar files seems to fail though...but this is a general limitation (if I run it from a commandline I get the same error)....hmm...don't know if that was different in the past.

Modifying multi-part rar files has always failed. You're right, it is a WinRAR limitation. However in clrmamepro 4.011a, if all the files in the archive were going to be deleted, the archive files themselves were deleted without an attempt to modify them. That doesn't seem to be working anymore.

[Roman]

Hmmm nothing really changed regarding this aspect....only the rar dll....I will have another look over the weekend...
I got an explanation for not deleting part 1 already....that should be an easy fix....actually I guess that will also solve the rest....

[Roman]

http://mamedev.emulab.it/clrmamepro/binaries/cmp20131221.rar

[Starshadow]

http://mamedev.emulab.it/clrmamepro/binaries/cmp20131221.rar

Rar deletion is working fine again in this build. Thanks!

[haynor666]

So, after all there is was bug in rar deleting. Thanks for the fix Roman

Now there is only left 7z bug.

[Roman]

Not really a bug...actually it seems that some things did change with the new dll...(or maybe I used it wrong in the past but it did work).

1) callbacks....there are some callbacks which you can use to e.g. calculate hashes (blockwise dataprocessing), ask for a password or ask for a different filename when a multi-set rar can't find the next archive....In the earlier dll it was no problem to have the last one not used and unraring simply fails when the next part was not found. In the current dll it freezed...by adding some code to the callback it fails again

2) deleting rar files (not the files in the archive) (single or multi-part). In the past I've used a routine from the dll which gives you the archive names (either one or the single multiparts names). That changed and I had to use the callbacks now to determine the names.