Print

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

[NvrBst]

This has been a problem for a while but thought I'd report. Information.

Old Set: My File - Great.7z
New Set: My File (Great).7z
clrmamepro: Version 4.011a (same with older ones though)
7zip version: 9.20

"My File - Great.7z" contains a single "My File - Great.iso"

After updating any of my sets dats, filename changes (maybe ~25%) become fatal to me, and cmpro permanently deletes my files. It has come to the point where I usually have to say "no to all", manually backup any files, then let cmrpo corrupt most renames, and then drag-n-drop the manually backed up files for rebuild; as you can guess tedious. This is what I usually observe:

1. During first scan it says "rename request: yes, yes to all, no, no to all". Say yes.
2. Warning log says: "7z: ERROR SZ_ERROR_MEM -> E:\set\My File - Great.7z\My File - Great.iso".
3. cmpro creates a 22byte "backup" which contains no files, and not a valid zip: "My File - Great.zip".
4. cmpro deletes "E:\set\My File - Great.7z" (which at this point is a valid .7z).
5. New scan.
6. Warning log says: "Corrupt Archive File: E:\cmp\backup\set-name\My File (Great).zip | Reason: NO ENTRIES".


Note: I recently updated to 9.30 alpha in hopes it isn't a cmpro problem, but, I think it is, and is probably related to how cmpro handles double quotes as I reported something like this before and cmpro fixed the issues with how it was handling double quotes for 7z, but, ideally these two would be implemented as well even if a cmpro fix is done:

My Suggestions for cmpro: 1: If backup is turned on, validate the backup file before deleting the set version.
My Suggestions for cmpro: 2: Stop progress if an error cmpro cannot handle occurs. Something like "Unexpected/Unhandled error with X occured. Proceed or Stop?". This gives the user time to manually look at the state of the system and decide "ok I need to backup that file because cmpro is probably going to delete it now and that backup it created is corrupted data". This should be good even if backup is turned off.

Let me know if you need more information.
EDIT: My cmpro backup folder, and cmpro set are on different drives if this information helps.
EDIT:
cmpro 7z: Executable: C:\ProgramFiles\7-Zip\7z.exe
cmpro 7z: Compress: a -y -r -ms=off -mx0 %1 %2
cmpro 7z: Delete: d -y -ms=off -mx0 %1 %2
cmpro 7z: Rename (unchecked)

[Zandro]

This problem stems from a 4GB (2³² bytes) limitation somewhere. Be sure you use a 64-bit version of 7-Zip (and of course clrmamepro), and avoid use of ZIP as traditional implementations of it are also not 4GB aware.  CMPro might back up as ZIP however, so that would be a problem.

Newer versions of 7-Zip support direct renaming of 7zipped files without recompression, but I have been unable to get it to work yet, using 7zr.exe 9.22b.

Not sure if this is still relevant, but this post from 2010 (result #1 when Googling the 7z error message) offers a probable solution.

[NvrBst]

Ahh. Yes it was x64 version of 7z "7-Zip 9.20 (x64 edition)", but now I am on "7-Zip 9.30 (x64 edition) alpha" to see how it goes. It is also the 64bit version of cmpro (exe named cmpro64.exe). But my RAM is very low on that system (3GB); hopefully thats not causing the problem.

As you say it might be because cmpro uses zip internally to backup files, and, thats what is having problems with the large iso files. I do notice sometimes cmpro backups valid files (for example when I update mame) and I usually just drag-n-drop the backup folder back on the scan window afterwards to rebuild them; so that could be happening here, but, it errors out with zipping during backup?

"Decompressed files" isn't really an option for me, and I don't have the "Decompress Rom & check crc32" option checked, maybe one of the other options causes the same behaviour though. I'll look into the new "7zip rn" option (i seen it on the cmpro compress window, but, new features sometimes scare me with cmpro hehe). If I run into the problem again on 7.30 then i'll try turning on the "7z rn" option.

[oddi]

NvrBst: If i remember right in 7z 9.30 have bug about that , try with 9.28alpha. I used this version and t7z-merged sets.

[Roman]

hmm...first of all I'd say it doesn't play a role if you're using a 32 or 64 bit version of 7z or cmpro. 7z file format supports archive sizes bigger than 4gig and so does cmpro. The currently 7z SDK C based handling of compress and decompress files is lousy....it simply tries to decompress everything into memory...you go to hell if you're working with big files..or solid archives. So running into a 7z out of memory error is relatively simple to achieve with around 4GB RAM....

That's one thing. The other thing is that cmpro of course should not lose any file because of such an error. I try to rebuild such a scenario and check where it fails...

...and somewhere in the future I might be able to switch to the 7z SDK C++ based handling...which is hell, too...but works on mem blocks hopefully...

[SpaceAgeHero]

I just ran into this issue for the first time too.
Any news on a solution, Roman? :-)

[Roman]

get more ram or use zip

no solution yet aince Im too busy with real life at the moment. but is is on m list

[Roman]

actually I had a little time and I guess it's 'fixed' now...in terms of "if the add file to 7z operation fails for you due to 7z internal error (memory/etc)....it was at least not cmpro which removed the file with the old name..."

...or shortly: if 7z.exe kills your file now...tough luck


in other words: you might want to use this:

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