Print

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

[newuzer]

Hi Roman,

We ran into this issue with the dogfight entry in SoftList msx1_cass.xml.

<rom name="dogfights\ zero fighter - dog fighter (1985)(microbyte)(es)[bload'cas-',r].cas" size="8534" crc="94a480e2" sha1="da0f4e2660ca03e3403e7d22945ea9bae89ab571" />

Notice the leading space before the "zero".
I agree it being a bug (reported) that needs trimming, but is there a way for CMP to (always) warn if this is the case instead of doing it silently?
It would be easier to notice and report bugs like these.
It now took someone using RomVault (not trimming) to notice the 2 byte difference in result between the datfile and the ROMs set.

Also referring to:
https://www.emulab.it/forum/index.php?topic=5942
https://github.com/mamedev/mame/commit/f898e47c0335fd5469645dc0e6a1b8df2b67fae1

With kind regards, NU.

[Roman]

Erm...since when does MAME use subfolders in its xmls?

Anyhow, cmpro does support them but for cmpro the rom name is the full (relative) path, including "dogfights\"...so a space in the middle somewhere is not checked at all since normally it's valid. I think I do trim the complete entry though (left/right)...but definetly not checking anything inside.

I take a note, but don't expect anything anytime soon.

[newuzer]

It was an entry from a generated merged XML, not the raw XML

[Roman]

But wouldn't it then be a job for the generator to trim?

[newuzer]

No, it's something clrmamepro changes from source to end result, so the warning should be there IMO.
The generated entry (filename) is the same as the RAW source XML.

[Roman]

Erm..no, cmpro does not change anything!
If the dat holds the "\ ", then it's taken over. So again: how was the dat being generated?
If you've exported it with cmpro, then the original dat (before merge) holds the " " or you have a space in your naming patter (profiler settings: %f\%1 -> %f\ %1)

[newuzer]

The ROM entries in the generated (not with CMP but with SabreTools) datfiles are 1-on-1 copies of the original raw XML file entries.
Hence the reference to the commit that fixes the original XML, which contained the leading space in the first place.
After rebuilding with CMP, the filename in the zipfile does not have the leading space.
Apparently with RomVault it does.
So somewhere in the process, the leading space is lost.

[Roman]

Well, most likely the archive operation (where maybe a file unpack to disk is involved) kills the space since I assume that 7z / zip unpack will create the file on disk without the leading space....and then the file is repacked to the destination. Maybe even the OS itself kills the space, too.

So...what are your rebuilder settings, if 7z is involved, the files will definetly be unpacked first and recompressed via 7z.exe from your disk....

[newuzer]

Everything default, no 7z involved, just zip.
Yes, the OS kills the leading space.

[Roman]

Ok, I had a closer look.
If you have a datfile with "bla\ blabla", the space gets already trimmed when the datfile is loaded/parsed.

[newuzer]

Ah, great, good catch.
Would it be possible to add a warning to the parser?

[Roman]

Possible yes, however pretty unlikely since there is no real development going on these days.....I put it on the list though

[Roman]

Actually I saw that a new zip archive lib is out.....so I got a reason to update cmpro....and quickly added your request

[newuzer]

Neat, thanks!
Works like a charm.
Happy holidays!