21
clrmame Discussion / Re: 7zip alpha 'rn' command renaming inefficiency
« on: 12 March 2013, 19:34 »
Looks good! Thanks as always. 
- 12 August 2026, 23:32
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
22
clrmame Discussion / Re: 7zip alpha 'rn' command renaming inefficiency
« on: 12 March 2013, 16:58 »
Here you are. I created a small test dat and duplicated the bug on a fresh install of clrmamepro 4.010 32-bit with minimal config changes.
File 1.7z contains a good rom in a subfolder with no unneeded roms.
File 2.7z contains a good rom and an unneeded rom not in a subfolder.
File 3.7z contains a good rom and an unneeded rom in a subfolder.
If you run a scan with 'fix unneeded' enabled, you will see the unneeded rom in File 2.7z deleted, but the unneeded rom in File 3.7z not deleted.
File 1.7z contains a good rom in a subfolder with no unneeded roms.
File 2.7z contains a good rom and an unneeded rom not in a subfolder.
File 3.7z contains a good rom and an unneeded rom in a subfolder.
If you run a scan with 'fix unneeded' enabled, you will see the unneeded rom in File 2.7z deleted, but the unneeded rom in File 3.7z not deleted.
23
clrmame Discussion / Re: 7zip alpha 'rn' command renaming inefficiency
« on: 11 March 2013, 17:11 »
I think I have encountered a bug that resulted from the changes to the way files are deleted from archives. I have some roms in 7z archives that have been removed from their dat. The scanner detects the files as unneeded and copies them to the backup directory, but then the rom is never actually deleted. These particular roms all have backslashes in their names, which results in the rom file being inside a series of subfolders in the archive. I suspect this might be causing the check for file existence to fail, and the deletion command is not issued. The same roms when stored in the root of the archive without the subfolders are successfully deleted.
24
clrmame Discussion / Re: 7zip alpha 'rn' command renaming inefficiency
« on: 21 January 2013, 23:46 »
That did the trick. My archive was only processed once to rename a file inside it. Thanks a lot.
You mentioned removing multiple files at once. If you could rename multiple files at once too, that would eliminate even more extra processing. The 7z 9.30 documentation claims it supports multiple renames on the command line, but it doesn't seem to work for me. I'm not sure about rar. Maybe a thought for the future.
You mentioned removing multiple files at once. If you could rename multiple files at once too, that would eliminate even more extra processing. The 7z 9.30 documentation claims it supports multiple renames on the command line, but it doesn't seem to work for me. I'm not sure about rar. Maybe a thought for the future.
25
clrmame Discussion / 7zip alpha 'rn' command renaming inefficiency
« on: 20 January 2013, 16:33 »
I very much appreciate all the recent improvements that have been made in regards to cmpro's handling of 7zip archives. It's far and away the best it's ever been. But there's one thing that's bothering me about the use of the 7zip alpha 'rn' command.
If I'm correct, before calling 7z.exe 'rn' to rename a file inside an archive, it looks like cmpro calls 7z.exe 'd' to delete any file that already has the new name. Now, this is as much 7zip's fault as cmpro's, but instead of recognizing when no file exists with the new name to delete and quitting, 7z.exe processes the entire archive anyway. This results in the entire archive being processed once for a usually fruitless delete, and again for the actual rename, making any 7zip file rename operation take exactly 2x longer than it should. When renaming sets of many large archives, this time adds up quickly.
If possible, could you please add a check to see if a delete is actually required before calling 7z.exe 'd'?
Thanks.
If I'm correct, before calling 7z.exe 'rn' to rename a file inside an archive, it looks like cmpro calls 7z.exe 'd' to delete any file that already has the new name. Now, this is as much 7zip's fault as cmpro's, but instead of recognizing when no file exists with the new name to delete and quitting, 7z.exe processes the entire archive anyway. This results in the entire archive being processed once for a usually fruitless delete, and again for the actual rename, making any 7zip file rename operation take exactly 2x longer than it should. When renaming sets of many large archives, this time adds up quickly.
If possible, could you please add a check to see if a delete is actually required before calling 7z.exe 'd'?
Thanks.
26
clrmame Discussion / Re: Using "Rename Profile" causes XML dat corruption
« on: 29 November 2012, 00:11 »use this:
http://mamedev.emulab.it/clrmamepro/binaries/cmpro20121128.rar
You got it! That build does not cause the corruption. Thanks for the quick fix.
27
clrmame Discussion / Using "Rename Profile" causes XML dat corruption
« on: 28 November 2012, 16:04 »
After renaming an XML dat profile via right-click -> "Rename Profile" in the Profiler window, the XML dat becomes corrupted and the profile will no longer load properly. This image shows the original dat on the left, and the same dat after being renamed on the right. The problem is the duplicated tags and extra </header> tag after the first </header> tag. Manually removing these repairs the dat. Non-XML dats are not affected. I am using clrmamepro 4.08b x64 on Windows 7 x64.
If I could throw in a somewhat related feature request: it would be nice if upon updating a previously renamed profile with a new dat version, the custom profile name was carried over after the update. Currently the profile name is overridden by the new dat, and any custom name must be re-entered.
Thanks!
If I could throw in a somewhat related feature request: it would be nice if upon updating a previously renamed profile with a new dat version, the custom profile name was carried over after the update. Currently the profile name is overridden by the new dat, and any custom name must be re-entered.
Thanks!
28
clrmame Discussion / Re: parse " - " as "\" so it become subfolders
« on: 03 October 2012, 23:06 »
You can get your desired effect by using the 'create folders' batch files that come with the TOSEC DAT pack to create an empty directory tree, and then manually setting the ROM path for each DAT to the appropriate folder in the tree. It takes a bit of work to set up, but after that it's all nice and organized.
Thanks!
30
clrmame Discussion / Re: some updated build
« on: 05 September 2012, 14:35 »
Excellent! It's working great for me so far.
The new 7z alpha also supports renaming files inside 7z archives from the command line. Is there any chance of support for renaming files that way in cmpro if its supported by the user's copy of 7z.exe? It would be preferable to the current unarchive/rename/rearchive method.
Thanks.
The new 7z alpha also supports renaming files inside 7z archives from the command line. Is there any chance of support for renaming files that way in cmpro if its supported by the user's copy of 7z.exe? It would be preferable to the current unarchive/rename/rearchive method.
Thanks.
31
clrmame Discussion / Re: looking for datfile for mame v0.37b7
« on: 28 December 2011, 12:11 »but when i click on the download link it tries to save 'index.php' instead of the zip. is there a way around this?
It downloads ok for me. Maybe you have a browser extension that's interfering? Try disabling some if you do or try a different browser.
32
clrmame Discussion / Re: looking for datfile for mame v0.37b7
« on: 28 December 2011, 01:39 »
Obtained by running:
mame.exe -listinfo > "MAME 0.37b7.dat"
on a 32-bit Windows XP VM.
mame.exe -listinfo > "MAME 0.37b7.dat"
on a 32-bit Windows XP VM.
33
clrmame Discussion / Re: Feature Request: More descriptive warnings
« on: 04 December 2011, 02:34 »
Ah, I never realized you could right-click on warnings. This works just fine. Thanks.
34
clrmame Discussion / Feature Request: More descriptive warnings
« on: 02 December 2011, 21:01 »
When running the Rebuilder, occasionally messages are logged to the Warnings window like "CRC error" or "Volume Open Error" without specifying which file caused the error. It would be more useful if these messages included the path and name of the offending file like with the "can't remove file(s) from..." messages. Thanks.
35
clrmame Discussion / Re: Feature Request: Bump LZMA SDK version to support LZMA2
« on: 02 March 2011, 17:46 »
I agree that switching to 7z.dll calls is the best way for you to go in the long term. In the short term however, would it be possible to support (optionally perhaps) calling the external 7z.exe for extraction as well? I brought this up once before if I recall as a possible solution to the issue surrounding extracting very large files directly into RAM. That isn't really a problem for me personally anymore, at least for files smaller than about 11GB, but you have to admit that temporarily storing entire files in RAM before dumping them to disk all at once is awfully inelegant.
I should also point out that 7z.exe has a well documented command line interface where 7z.dll has only a .cpp file for documentation with lots of nasty looking things they didn't teach me about in my CS courses.
I should also point out that 7z.exe has a well documented command line interface where 7z.dll has only a .cpp file for documentation with lots of nasty looking things they didn't teach me about in my CS courses.
36
clrmame Discussion / Re: clrmamepro 3.137d
« on: 01 March 2011, 21:39 »
That was very quick! I've confirmed set list exports are working again. Thanks.
37
clrmame Discussion / Re: clrmamepro 3.137c released
« on: 01 March 2011, 18:18 »
I have found a bug. Exported Set Lists in 'Set' and 'CSV' format no longer have line breaks in this version.
38
clrmame Discussion / Feature Request: Bump LZMA SDK version to support LZMA2
« on: 28 February 2011, 21:45 »
I would like to request that you investigate the possibility of updating the version of the LZMA SDK used in clrmamepro in order to properly support 7z archives using the LZMA2 compression method. clrmamepro is already able to compress files with LZMA2 by modifying the 7z compress arguments, and it is able to read file names and hashes from 7z archives using LZMA2 like any other 7z archive. However, errors arise when clrmamepro tries to extract an LZMA2 compressed file from a 7z archive (either for renaming or backup). I know the LZMA SDK has a long and storied history of being pretty terrible, but if it's as simple as updating the version, I would really appreciate if you would. My reasoning for wanting this is that I'm encountering files which come out larger after being compressed with LZMA, and this 'feature' has been disabled with LZMA2, so I would like to be able to deploy it across all my sets without the major inconvenience of needing to manually maintain the files. That's what clrmamepro is for, after all. Thanks for your attention, and the time you put into clrmamepro.
Thanks for your attention, and the time you put into clrmamepro.
39
clrmame Discussion / Re: Problems with files ≥4 GB
« on: 12 May 2009, 23:07 »So for now: I don't waste time with 7z.
Can't blame you. I had no idea the 7-Zip code was so convoluted. I did find one other possibility though, to look at in your free time.
http://akky.cjb.net/download/7-zip32.html
Outdated, but English documentation
It seems to be a 7zip dll with an actual API
. The source is included so you should be able to compile a 64 bit version.
40
clrmame Discussion / Re: Problems with files ≥4 GB
« on: 12 May 2009, 18:29 »
The 7z.dll in a x64 7-Zip install should be 64bit. I'll email mine to you just in case.