Print

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

[Roman]

simply create a dat with one set and all files in it :-)

[Roman]

and now back to the original problem....Yay...I can repeat it on a network drive ;-)
Since I used a network drive on the other side of the world it was way too quick that it could have calculated the checksum that fast....interesting....after some coffee and cake I will investigate this later tonight.

but on the other hand I guess it is related to the length of the path...

\\something here\Emulation\ISOz\NINTENDO GameCube (Redump.org) (NKit)\2 Games in 1 - Bob L'eponge - Le Film + Tak 2 - Le Sceptre des Reves (France) (Disc 1) (Bob L'eponge - Le Film)\2 Games in 1 - Bob L'eponge - Le Film + Tak 2 - Le Sceptre des Reves (France) (Disc 1) (Bob L'eponge - Le Film).nkit.gcz

is beyond the path limit while
\\something here\Emulation\ISOz\NINTENDO GameCube (Redump.org) (NKit)\2 Games in 1 - Bob L'eponge - Le Film + Tak 2 - Le Sceptre des Reves (France) (Disc 1) (Bob L'eponge - Le Film).zip
is not

I know of at least one Window library call which has a problem with such long names (some directory tree walk call).....will test later if it's related to that one....if so I need to find a walkaround (sigh) (see comment on the nightly build post)

[retaliator]

Thanks Roman for investigating this, I appriciate it and of course your hard work for this nice program!

Btw., I also tried a shorter path on my NAS and it hadn't worked either with uncompressed files.

[Roman]

You need to reach something below 260 chars includong the filename

[retaliator]

Confirmed, testing with "\\SYNOLOGY_DS414J\public\GC\4x4 Evo 2 (USA)\4x4 Evo 2 (USA).nkit.gcz" works fine. But with the set in same place "\\SYNOLOGY_DS414J\public\GC\007 - Agent im Kreuzfeuer (Germany)\007 - Agent im Kreuzfeuer (Germany).nkit.gcz" it doesn't work.

[Roman]

Actually I found the cause....

\\?\c:\dir\file.txt UNC Drive path   32k bytes
\\?\UNC\server\share\dir\file.txt UNC Server path 32k bytes

means that you (actually cmpro (*)) needs to specify a different prefix for a network path...

When doing so it will at least start to calculate the hash...but there seem to be other places where such a long network path fails...so I need to check some other stuff as well.

(*) the nightly build of cmpro sees if a path is too long and automatically adds \\?\ in front of it (as long it's not a network path or a relative path). But for network paths it needs to add \\?\UNC\ ..

[retaliator]

I tried to put \\?\UNC\ in settings by using F2, but it seems like it doesn't change a thing. After hitting return it's back to \\SYNOLOGY_DS414J\public\Emulation\ISOz\NINTENDO GameCube (Redump.org) (NKit)\ .

Maybe I did something wrong? Should the path be \\?\UNC\\\SYNOLOGY_DS414J\public\Emulation\ISOz\NINTENDO GameCube (Redump.org) (NKit)\ ?

[Roman]

\\?\UNC\SYNOLOGY_DS414J\public\.....

(just one (1) backslash \  after UNC) ...but since cmpro's nightly build auto-adds/removes it you may run into trouble....gimme some time to fix it (in the meantime I found the reason for the other problem, too...there was a not mapped file operation which did not run through the prefix adder...)

try this:
http://mamedev.emulab.it/clrmamepro/binaries/cmpro20191006.rar

[retaliator]

Works fine now! Many thanks Roman!!

About oxyandys request:

Like an option to simply 'ignore setname' this way an existing dat such as:
NINTENDO GameCube (Redump.org)
..\007 - Agent im Kreuzfeuer (Germany)\007 - Agent im Kreuzfeuer (Germany).nkit.gcz
Could be used to store / scan all files at root level 'minus' the subfolders.

That would be nice not forced to put every file in a folder...

[Roman]

Thanks for reporting and helping...

Well, about that "I want them all uncompressed in a folder" support.....you need to see how MAME originally works. A set usually contains more than one file (gfx roms, sound roms, dumps holding the code etc), so they got a container, a folder named after the set, holding these files. Using an archive (7z/rar/zip) is pretty the same - a container (again named after the set).

Scanning/Merging/Rebuilding is built around this.

I see your point when it comes to 1-file-per-set collections. Keeping them decompressed leads to the a bit obsolete storage method with the extra folder.

What you can do is to change the datfile definition to only define one set where all files are stored. This would allow to have all files in one folder (named after the setname defined in the dat). Cons: you loose additional information like a detailed description per set (however as you can see from these big filenames, they simply put all in there...) and you get the scan results after finisihing this one giant set.

Theoretically I can add an option which changes a loaded datfile into an one-set-billion-roms dat......time will tell

[retaliator]

This isn't anything of rush, Clrmame is already my favorite rom auditing tool. Thanks for your hard work!!

[oxyandy]

Here is a basic response just to say thanks Roman for even considering this.
When I have time in the next few days I will point out a few issues you may not even be aware of.
As you know I like to include detail in my posts so will not just make a 'rushed post',
I'll take my time and draft a really decent response, include screenshots and real examples to remove any ambiguity.
Cheers 👍
Oxyandy

[Roman]

better I run for cover..... ;-)

[oxyandy]

Hi Roman,
other than RAM and HDD what could cause hash computations to be an incorrect result please (wrong CRC calculated)
Thanks
EDIT: silly question I know 🤣
Failing: motherboard, processor, i/o controller, inadequate or failing power supply.
Time to dump this hardware (well most)
Scanner Output: "wrong crc32: Some_file.bin [wrong: 537b1a1f] [right: f38a3b0f]"
Yet, independently - Some_file.bin is actually f38a3b0f

[Roman]

theoretically any involved driver or hardware...or even software (a virusscanner might block the access...but that should end in a missing or not accessible file rather than a bad hash)