When ClrMAMEPro finds a file with wrong name, it prompts for renaming. If there is a file with the target name already, CMP simply overwrites it, instead of prompting or failing or creating an alternate name or anything! That applies both to .ZIP files and to ROM files inside them. I have lost many ROM and .ZIP files in the past, as I hadn't noticed that stupid (mis)behavior of CMP, files that I was sure I had before running CMP. Currently, when I run CMP, everytime it prompts for a rename, I have to check if the target name already exists. If it does, I make a back-up of the entire .ZIP file, so I can undo the stupid overwriting after it is done and nicely says I have missing files.

Now, my question is, is there a workaround to that? Is there an option I hadn't seen that makes CMP avoid destroying files with conflicting names?

Edit: I have just run CMP 3.103a with MAME 0.118, and I missed an entire ROM set, thanks. Instead of overwriting the target conflicting file, CMP simply deleted the origin file (I hadn't backed it up, I just made a copy of the target file, as I used to do with previous CMP...) Wonderful, CMP does sh** again...

> Now, my question is, is there a workaround to that? Is there an option I hadn't
> seen that makes CMP avoid destroying files with conflicting names?

It's not a workaround, it's one of the main functions in cmpro!
In the "settings" window there is a "Make backups to folder" options with a togglo. Check it and select your preferred backup folder. If you do this, you will never ever loose a file again.

ciao
f205v

You're wrong:

- it doesn't apply to sets because if a set (zipfile) gets renamed and the 'new name' already exist, the rename operation simply fails. There's an additional scanner advanced option to force the overwriting but then the files are moved to the backup option.

- in case of roms (files inside the zips), you may got a small point. They get replaced. Simply because according to the datfile the to be replaced file is not correct (otherwise cmpro's other check options would already find a correct name / or indicates it as unneeded etc.) Circular renames are handled fine by the way (meaning 2 files in the zip gets their names exchanged). The unneeded fix makes backups by default as well.

So only when you disabled some check options (which cmpro warns you to do) it will replace a file within a zip like any other zipprogram will do and you're asked if you really want to fix the name (that has nothing to do with 'destroying'). According to the datfile that replaced file isn't even a valid one.

For the rebuilder you already got a mechanism which per default makes backups of to-be-replaced files.


Roman Scherzer

Your reported case of a renamed file replacing a different one can only happen when you a got an old zipfile and the new datfile says: delete one (otherwise you got a circular rename) and rename one to that deleted one's name. Pretty uncommon unless the datfile author is a weirdo 8). But then the unneeded check would detect the unneeded one first and moves it to backup, so again, nothing gets overwritten.

So I guess you didn't keep all check/fix options enabled. Send me a repeatable example.


Roman Scherzer