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

Thanks...I will look at it over the weekend

actually no....fixing a wrong name or removing a file should simply do its job.

Maybe you've got special access rights on your folder? Maybe the files are somehow in use by other apps ....you said you copied them...so maybe you copied them with access rights used for the "other machine"...and this may be a problem now...but actually you could test that by manually trying to remove one of the copied files.

It would be the latter. The DAT file is fine, with the correct name. The "problem" lies in large 7zip files with incorrectly named ROMs within subfolders that would benefit from a simple rename rather than a complete rebuild. Admittedly these files are poo, but handling them would increase clrmame's speed when confronted with them.

I've attached a trivial example that I hope illustrates it better.

Looks like that was what caused that issue.

Right now, I updated to .249 and used the rebuilder.   

It seems that there are a lot of files with "wrong name", but the tool indicates that they were not fixed.  I have all the fix options selected.   Any idea why the tool will not fix the zip file by renaming and/or deleting extra files in the zip?

So you have a dat where the rom name is "game/game.iso" or you got a set "game" where "game.iso" is one of its roms but your 7z file has a subfolder???

If you got a dat handy.....that would be fine since I could simply exchange hash/size information and retry with a a small 7z file....doesn't need to be some iso dump

That's what I initially thought, until I started playing around on the command line and found using 7zip correctly (i.e. the way -they- want you to) it was exponentially faster than what occurs with clrmame. I'll try to prep one for you, but in the meantime maybe a clearer illustration:

File:
Game.7z

Contains:
Game/
Game/Game.iso

If you attempt to use the rn option to change "Game.iso" to "Game2.iso" (assuming that's the correct name), it will fail with file not found. You must use "Game/Game.iso" to "Game2.iso", which will result in the following structure:
Game/
Game2.iso

...after which I assume it's trivial to do a delete on the empty/unneeded "Game/" folder.

Does that make more sense?

Sounds more like you're using solid archives which always require a complete repack of the archive on a change.

Do you have an example file and dat?

So, I have a bunch of archives with the roms in subfolders within the 7zip. I enabled the rename function under the compressor settings, but it still seems to be rebuilding the entire archive. I believe the problem is related to the fact that unless you specify the FULL path within the archive to the file you wish to rename, it will fail as file not found. It also does not accept wildcards. It does, however, allow for a "move" operation to be done with the rename.

Bottom line what I'm asking, is there any way to have clrmame essentially make up the functionality lost in the 7zip implementation by having clrmame pass the full path to the %2 parameter of the rn? It would tremendously speed up processing of 7zip files that require only a name change.

Thanks!

ARMAX MAME Dat 0.249 https://www.mameguide.info/MAME_(20221027).7z

Due to the fresh install you might have some different (default) settings compared to the old installation.
On a quick first view it looks like you had different settings related to the interpretation of merge attributes in the datfile...

Profiler -> Options-> "Parse ROM 'merge' Tags" and Parse DISK 'merge' Tags

I think the current default is that both are enabled which makes sense while years ago I think only the chd one was ticked (because back then merge attributes were not that reliable).

With both ticked you will save a bit of diskspace (however when trying to fix the wrong names, you most likely also see unneded ones afterwards which can also be fixed.....it's all about identical roms in a parent/clone relationship with different names).