Print

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

[newuzer]

Hi Roman,

Got one for you to check.
crlmamepro 4.047 used, default settings.
Scan/fix "MAME 0.258 ROMs (merged)" to "MAME 0.259 ROMs (merged)" loses a ROM for the trackfld set.
Content and steps (text file) to reproduce are in the zipfile.

With kind regards,
NU.

[Roman]

Well, yes, interesting. It all happens since one of the rename step fails ("Unpack failed on file -> E:\Temp\test3\trackfld.zip\hyprolymb\3.a4") and you/cmpro continues with fixing the unneeded fixes...
I will have a closer look at it tomorrow.

[Roman]

Hmm....actually it works for me fine now.

By the way, scanner's fix missing automatically looks in your backup path for matching files which were removed in a previous unneeded case.

So I run a full fix scan, it reports missing rom: hipoly\1.11d and missing rom: hipoly\2.4a
Pretty normal for now, since they were moved to backup. Another scan will show them up as fixable and cmpro wants to readd them fine.
So nothing is lost.

Today I don't get the unpack file problem which may be the cause of the reported issue (an unpack to backup failed but the file was removed).
I will look into that again but for now I cannot repeat it. The unpack might have failed because for whatever reason the backup file already exists (however cmpro uses a new file name then....weird...)...as I said...I will double check that.


Update: Hmm...ok..one thing...yesterday I've tested it with the released exe and today with a debug version. Same code basis but updated visual studio (and of course debug mode)...maybe that's the difference....Will check when I'm done with real life work...

[Roman]

ok I've tried it again with the released version....and I can't repeat it at all.
Simply running a full fix scan twice ends up with a good set, nothing's lost.

[newuzer]

Well, that's weird and interesting indeed.
I constantly end up with this:
missing rom: hipoly\2.4a [size: 8192] [CRC32: 2d6fc308] [SHA1: 1ff95384670e40d560703f2238998a8e154aa4cf]
It's not in my backup folder.

I get this, when I do a scan/fix all answering with "yes" only:

Do you want to rename the following wrong named ROMs?
hyprolymb\2764.1 -> hipoly\1.11d
hyprolymb\3.a4 -> hipoly\2.4a

Set:   Track & Field
Name:   trackfld
File:   D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to add the missing ROM?

Set:   Track & Field
Name:   trackfld
File:   D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to remove the file?

Set:   Track & Field
Name:   trackfld
File:   D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.18a
Do you want to remove the file?

Set:   Track & Field
Name:   trackfld
File:   D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.4a
Do you want to remove the file?

Missing
·Sets                 0/1
·ROMs                 2/57
·CHDs                 -/0
·Samples              -/0
·Bytes                16kb/1mb

New Scan

Set:   Track & Field
Name:   trackfld
File:   D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to add the missing ROM?

Missing
·Sets                 0/1
·ROMs                 1/57
·CHDs                 -/0
·Samples              -/0
·Bytes                8kb/1mb

Ending up with this:
missing rom: hipoly\2.4a [size: 8192] [CRC32: 2d6fc308] [SHA1: 1ff95384670e40d560703f2238998a8e154aa4cf]

In backup there is:
hipoly\1.11d SHA-1: 057981ad3b04239662bb19342e9ec14b0dab2351
hipoly\2.4a SHA-1: 4fbb2fcdf9bc7a3d273dbc27b8157f163ff9bf11
hipoly\2.18a SHA-1: b6827592095543c92384a7e8b817a741d249cff8
hyprolymb\3.a4 SHA-1: d031b033d23d50a5f708f630945602e61d52d1e4
hyprolymb\2764.1 SHA-1: 057981ad3b04239662bb19342e9ec14b0dab2351

Do you get these exact same steps?

My guess is that is goes wrong in the very first rename hyprolymb\3.a4 -> hipoly\2.4a
3.a4 is the 2.4a one missing in the end and 2.4a is already there before the rename.
After the rename hipoly\2.4a is still there, but is the wrong one (SHA-1: 4fbb2fcdf9bc7a3d273dbc27b8157f163ff9bf11)
That's why I get this step later:
Set:   Track & Field
Name:   trackfld
File:   D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.4a
Do you want to remove the file?

hyprolymb\3.a4 (the one I need)is gone after the first rename.
So it looks like the rename/move step fails here.
I tested it on 2 different systems, same result.

Regards, NU.

[Roman]

Guess what, while I can't repeat it on one machine, I did the test on another this morning and there I can repeat it. Hmm...Maybe some kind of order/timing problem...I will do further checks.

[Roman]

Found and fixed....was an index problem when a backup is done when a rename failed (since the new name already exists).

New version later today....

Thanks a lot for finding that one

[newuzer]

Any time
Thanks for fixing (confirmed), Roman.

NU.

[Roman]

nice finding......it actually backup'ed the wrong file (when there were more than 1 in the queue....in a failed rename...blablabla...) Thank god the new scanner won't have such special things....

[newuzer]

Well, simplicity rules, however I'm not so sure if that goes for MAME and it's exceptions
I'm interested to know why you couldn't reproduce it on the one machine.
If it was a timing issue, I can understand, but to me this looked very much like a repeatable sequence.

With kind regards,
NU.

[Roman]

For that test I've used a rebuilt archive, not the one you had in your archive. The problem is based on an archive file index / order problem.

When a rename operation fails (and in that case, 2 renames fail since the right name already exists in the archive), it moves the not renamed ones to backup (so they can be picked up later on again). So it made a backup of file 5 and 6 for example. So far so good. Unfortunately, it directly removed the files, so it copied 5 to backup, removed 5, copied 6, removed 6 without having the indexes refreshed in between. So when it removed 5, copying 6 was simply the wrong file.
In my case the archive order was simply the other way around. It copied 6, removed 6, copied 5, removed 5, so it always picked the correct ones. To understand this: The backup copy is index based, the removal is filename based at that point...
So it only happens when more than 1 file failed during rename (where the right name files also exists in the archive)

The fix is pretty simple, do the removal of all of the backup'ed files after the copy....

[newuzer]

Aha, that explains it. Interesting.
Thanks for that.

With kind regards,
NU.