Firstly, thank you for your wonderful program.

Secondly, I was hoping for some help. I'm not sure if this is a bug or something I can fix with my language settings in Windows XP or neither.

Here are my symptoms:

I rebuild a set with some nonstandard ascii chars in it, and the rebuilder alters the rom name inside the set. For example:

*Removed Examples since they would not display in the preview*

When I scan the set with "Fix Names" checked, it will rename the file creating a corrupt zip:

*Corrupt Zipfile: XXXX.zip | Reason: DOUBLE FILEENTRY IN ZIPFILE

So my guess is that the same thing that is causing the rebuilder to misname it on the first try causes it to be renamed improperly during the scan, resulting in two files in the zip with the same name.

So anyhow, maybe someone can help me. Is there a nice language setting I can change in windows xp sp1? I am currently just keeping the "Fix Names" unchecked while scanning this set.

Characters, I have noticed that seem to cause this issue include the following. I have had to change this since they did not show up in the preview:
® - R in a circle
³ - Superscript 3 (Cubed)
´ - Forward asterisk
ø - lowercsase 'o' with a slah through it
à - uppercase 'A' with a tilde '~' above it
Ð - uppercase 'D' with a horizontal line intersecting the vertical bar on the left


I'm using v3.88, Windows XP sp1. My current Language settings are set to "English (United States)".

I can upload the examples to a website should they be needed.

Thanks.

> I can upload the examples to a website should they be needed.

Sounds interesting.
Please mail them to me....and add the used datfile!
clrmame@clrmame.com

The thing is, there are two ways to store such characters in the zipfile: a wrong way and a correct way 8) So I need a zip which wasn't touched yet and tell me what you're doing to get the error.

I already tested your listed characters and they work fine. It could be that you got a bad zip in the first case where the character conversion gives something bad and while adding a file with correct conversion gets you the same entry...sounds a bit complicated but I remember there were bad zips in the net with wrongly stored chars...

anyway...send me a zip and dat and tell me exactly what you tried to do.

By the way....one of the ` ´ is reserved for internal use and can't be used...don't remember which one though...People should use ' anyway 8)


Roman Scherzer

> > I can upload the examples to a website should they be needed.
>
> Sounds interesting.
> Please mail them to me....and add the used datfile!
> clrmame@clrmame.com
>
> The thing is, there are two ways to store such characters in the zipfile: a
> wrong way and a correct way 8) So I need a zip which wasn't touched yet and tell
> me what you're doing to get the error.
>
> I already tested your listed characters and they work fine. It could be that you
> got a bad zip in the first case where the character conversion gives something
> bad and while adding a file with correct conversion gets you the same
> entry...sounds a bit complicated but I remember there were bad zips in the net
> with wrongly stored chars...

Thanks Roman,
I'm at work now, so I'll email the pertinent files when I return home.

One thing I wanted to point out was that I would unzip the bad zips to a folder and rebuild from scratch. So I'm not sure if this would cause the issue you described since no zip existed in the destination folder and the source folder contained only files (non-zipped).

Anyhow, just some more info that make give you some ideas.


Thanks Again.

Well...I created a simple dat with rom name using the listed characters and rebuilt files with it...no problem. Changed the name, used fix missing...no problem either...

...so I really need your zips then I guess.


Roman Scherzer

Ok,

now I know what's causing the issue.

Well...mainly it's because the datfile uses non-ascii characters, ie unicode chars (byte size) which are mapped to 0 to 255 DEPENDING ON THE used codepage. That's why it works flawlessly here and fails for US (could be viceversa for other chars though).

So the next version of cmpro will have a new option to turn on/off Ansi2OEM/OEM2Ansi conversion which the user has to decide.

Although this will have some consequences for viewing the zipfile. Depending on the viewer (winrar, winzip fails btw...) you see the correct spelling or a mapped one....

And the double entry is caused by a wrong conversion, too...should be fixed with the next release, too.

To sum it....don't use such dats ;)



Roman Scherzer

> Ok,
>
> now I know what's causing the issue.
>
> Well...mainly it's because the datfile uses non-ascii characters, ie unicode
> chars (byte size) which are mapped to 0 to 255 DEPENDING ON THE used codepage.
> That's why it works flawlessly here and fails for US (could be viceversa for
> other chars though).
>
> So the next version of cmpro will have a new option to turn on/off
> Ansi2OEM/OEM2Ansi conversion which the user has to decide.
>
> Although this will have some consequences for viewing the zipfile. Depending on
> the viewer (winrar, winzip fails btw...) you see the correct spelling or a
> mapped one....
>
> And the double entry is caused by a wrong conversion, too...should be fixed with
> the next release, too.
>
> To sum it....don't use such dats ;)
>
>
>
> Roman Scherzer
>

As an aside, I'm hitting the same problem using a couple of DAT files created by others (I'm not sure I can mention who/what here!) and language settings are UK English.

Thanks for implementing a fix :)

Cheers,
Terra Cresta

> As an aside, I'm hitting the same problem using a couple of DAT files created by
> others (I'm not sure I can mention who/what here!) and language settings are UK
> English.


Well...use the latest version and you probably have to toggle the OEM/ANSI conversion option in settings->zipsettings for such dats.


Roman Scherzer