Print

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

[marcsandusky]

Roman,

With the last two TOSEC releases, I have noticed a rebuilder problem.  Know-good files that were previously identified correctly were no longer being identified during the rebuild process and were unhappily skipped.  The notes indicated that new SHA1s have been added to many DATs recently.  Disabling MD5 and SHA1, leaving only CRC32, seems to solve the problem.  A good example is the "Apple II - Compilations - Games - [DO] (TOSEC-v2013-10-29).dat" file.  The following entry no longer recognizes the ROM when SHA1 and MD5 are enabled:
game (
   name "ABM (1980)(Muse) & Invasion Force (19xx)(Gordon Lurie) & Missile Defense (1981)(On-Line Systems) & Norad (19xx)(-) & Planet Protector (19xx)(-)[cr] & Rocket Command (1980)(Bozo NYC)"
   description "ABM (1980)(Muse) & Invasion Force (19xx)(Gordon Lurie) & Missile Defense (1981)(On-Line Systems) & Norad (19xx)(-) & Planet Protector (19xx)(-)[cr] & Rocket Command (1980)(Bozo NYC)"
   rom ( name "ABM (1980)(Muse) & Invasion Force (19xx)(Gordon Lurie) & Missile Defense (1981)(On-Line Systems) & Norad (19xx)(-) & Planet Protector (19xx)(-)[cr] & Rocket Command (1980)(Bozo NYC).do" size 143360 crc f0760736 md5 cbc6dd038436029aaaab86e02be0a46a sha1 aa97ac5aac86d2fa614434af3377072926a10e1c )
)

Again, this is a rebuilder issue only.  If the image is manually copied to the correct directory, then the image is correctly identified and recorded by the scanner.  Do we have a possible line length issue in the parser?

Thanks,

Marc Sandusky

[oxyandy]

Using CMP 32 Official Release 4.015...
Using Common Folder structure of:
D:\Apple\II\Compilations\Games\[DO]
I was able to Rebuild perfectly..
ABM (1980)(Muse) & Invasion Force (19xx)(Gordon Lurie) & Missile Defense (1981)(On-Line Systems) & Norad (19xx)(-) & Planet Protector (19xx)(-)[cr] & Rocket Command (1980)(Bozo NYC).zip
(and yes, I ensured "Additionally test SHA1/MD5 for matches" was ticked...)

[Roman]

well...if the sha1 don't match you either have a wrong file or the sha1 stated in the dat is wrong.

[Cassiel]

or the sha1 stated in the dat is wrong.

The CRC32/MD5/SHA-1 in the DAT is definitely correct. 

Since this particular image has a very long file name due to containing multiple software in one dump, I would guess that the whole path length issue is what is causing your problem.

[Roman]

well....long names....good point, however why does it work for him when sha1/md5 checks are disabled...hmm...could be interesting to do a test here...maybe it was unpacked temporarily to calculate the sha1 etc....

Was it packed? If yes, which archive type?

[Cassiel]

Hmmm... amendment to theory:

If a zip archive then CMP just reads CRC32 from zip header right? But if checking SHA-1/MD5 then it extracts to 'temp' folder and hashes the file? (I'm guessing)

I would wager the temp folder + filename is too long, wherever CMP is installed.

Anyway... enough interfering from me. Just thought I'd jump in since was reading board and caught my eye as the TOSEC guy. 

[Roman]

Yes something like that
Time to introduce 32k filepath support

...hmm...sha1/md5 values are calculated in memory....so no unpack to a folder....so the problem is somewhere else...

[Roman]

ah...I got a scenario where I can repeat the behaviour.....
so assume it gets fixed...

[Cassiel]

Dammit! I thought I was being so smart... hahaha

That's good news, and even speedier than normal.   

[Roman]

oops..my fault...had a typo in the sha1 and so it simply did not match...
rebuilds fine here......with a destination folder e:\test2...will now check a folder with a longer path..

...however we still don't know which packer marcsandusky used (if any...)

update: ok...with a longer filename you will get a prompt saying that it failed creating the file...but this also happens with no md5/sha1 check enabled..

...so unless we get some additional information from marcsandusky I can't say it's a problem on cmpro's side...




update:
so theretically it would already help if marcsandusky does the following: go to the "about" screen and drag'n drop the file in question in the window...cmpro will then calculate the hashes and shows them....a screenshot of this output would already be a great help..

[marcsandusky]

HashMyFiles reports this for the file:

Filename   
ABM (1980)(Muse) & Invasion Force (19xx)(Gordon Lurie) & Missile Defense (1981)(On-Line Systems) & Norad (19xx)(-) & Planet Protector (19xx)(-)[cr] & Rocket Command (1980)(Bozo NYC).do

MD5
CBC6DD038436029AAAAB86E02BE0A46A

SHA1
AA97AC5AAC86D2FA614434AF3377072926A10E1C

CRC32
F0760736

The file seems to be OK.  It seems that I also had a problem rebuilding Progretto Snaps cabinet files as well.  Let's assume that something on my end is wrong.  I will go off and do a clean install and see if everything is working.  Sorry for the interruption.

Thanks,

Marc Sandusky

[Roman]

hmm..interesting...at least the hash values are ok...

so does it simply skip the file or does it show a prompt or something?

[oxyandy]

Hi Marc,
Experience has taught me, keeping ALL paths as short as possible gives room for error.
So for P: Drive -- It's P:\_CMP
I usually keep a copy of CMP on the same drive as my set CMP is working with too.
*Obvious advantage*
Let's say I had my CHDs in P:\CHD
A quick CHD Scan would instantly move 'Outdated CHD files' to CMP's backup folder..
P:\_CMP\backup\CHD

Not the case if CMP was on C:, then Gigabytes worth of 'Outdated files' would have to travel from P: to C: = time consuming (Using default backup path anyway)

A TOSEC set, is best kept on a dedicated partition, so the first nested folder would be;
P:\Acorn\Archimedes\Applications
If dedicating a partition was a problem, then (esp TOSEC) I would go P:\_T\Acorn\Archimedes\Applications
But like Roman says, if Rebuilding and Destination path + filename is too long, you would get a Msg Box Error.