Print

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

[CoreyEMTP]

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!

[Roman]

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?

[CoreyEMTP]

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?

[Roman]

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

[CoreyEMTP]

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.

[Roman]

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

[Roman]

Did a first check and there's nothing weird, it simply renamed the wrong named file and removed the obsolete folder entry. Using 7-Zip 22.01 (x64).

The problem with your file is that it keeps directory entries alone. So your file got a folder entry and a file entry. cmpro detects an obsolete folder entry and a to-be-renamed file entry...The rename successfully renames the file and the folder is obsolete and gets removed and this of course will cost, especially when you use solid archives.

7z can also store files with path information without having a folder entry. Then you only got 1 entry in your zip and the rename simply renames it. No removal necessary then.

clrmamepro by default uses that mode....you can e.g. alter your example dat to use "<rom name="bla/this is what the rom should be named.txt" size="16" crc="2ecae73f"/>". After doing a full scan/fix round, you will have a 7z with a subfolder (bla) and a file but in general only 1 entry is in the 7z.

don't know the beloning 7z option for it though.....

So....actually there is nothing wrong as far as I can see

[CoreyEMTP]

But that's exactly the problem, the DAT won't say "bla/game name.iso", it will say "game name.iso" only. In this case the source of the 7zip is external, so I don't control how it's created. So when it encounters the 7z with "bla/bla.iso", it doesn't appear to rename "bla/bla.iso" to "game name.iso", which would have the effect of leaving a 7z with "game name.iso" in the root and an empty "bla" folder. Instead, what I'm (purely) guessing is it's attempting to rename "bla.iso" to "game name.iso", failing, and then deciding it needs to extract the whole thing.

It's simple to demonstrate with the test sample 7z I sent. You can try the two rename operations above directly with 7zip's rn command to see the effects.

I could be completely wrong and it's just the time cost of doing the two (rename and delete empty folder) operations, but the length of time it takes sure seems like it's doing a complete rebuild every time.

Thanks so much for looking into this!

[Roman]

Your datfile does not have subfolders. Your archive does have a separated subfolder and a separated file.
And here we face the problem: Your 7z file stored such information separately, i.e. you have 1 folder and 1 file.
So clrmamepro detects the folder and says it is unneeded and removes it (which may cost a bit depending on solidness/etc).
Then it also finds a wrong named file...this is renamed with the rn option which takes no/very less effort.
So clrmamepro finds 2 things which both get fixed, one is an unneeded folder and one is a wrong named file.

Keep in mind, 7z (and also zip) can store files in subfolders without creating an extra folder entry.
This extra folder entry is the problem in your case. If file would be stored with subfolder information on file level in the archive, you'd only have 1 clrmamepro operation, a wrong named file "bla/wrong name" -> "correctName"

My example was a datfile with subfolders.
Subfolders are only supported when they are specified on rom name level like  <rom name="bla/this is what the rom should be named.txt"...>
When having such definitions, the rebuilder and scanner will automatically create 7z without separated folder structures stored, but of course you still have subfolders in the archives....
I've attached an example for subfolders without extra dir entries. If you play around with that file and dat, you shouldn't see any extra effort in removing data, just pure rn operations when you alter the dat.

So, to sum it up: The problem in your case is that there are actually 2 operations and they are intented to be there based on the structure in the 7z file. Your example 7z archive keeps subfolder information separated instead using subfolder information on filename level. For clrmamepro, there is an unneeded folder and a wrongly named file. Reading the zipfile will give you 2 entries. This is completely independent from the external packing tools or the defintion of the dat.

However, rebuilding the files resolves the problem once and for all since it will create subfolders on filename basis

[CoreyEMTP]

That's interesting, plumbing the depths of these apps I'll continue to leave to the experts! It's a little odd how it stores the structure, no? That seems to be the default result from a command line add operation in 7z. Regardless, thank you for the answer!