Print

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

[Roman]

ok...while the 32k path support seems to work (wonder if anyone tested it yet)...I'm fiddling around with getting rid of killing parent/clone relationships when you got name/hash collisions within such a set relation....

Current situation: you can either force split merge mode or cmpro removes parent/clone relationship if a hash collision is found, no matter if you use split merged sets (where the problem does not occur) or not.... Only full merged sets would have a problem.

Future solution: In case you got a hash collision *AND* use full merged sets (scanner, rebuilder destination, merger destination), cmpro will store clone sets in set subfolders, while the parent and not affected clones keep their naming.
As a plus I want to introduce an optional setting which allows you to store all parent/clones that way, Parent files in the archive root, clones in subfolders.
The names will change instantly (depending on the size of the used database) if you switch the merge mode....

I've attached some screens...as demonstration sets I used some old 1942 MAME database entries which have a hash collision within their clones...1942abl and 1942p share some equally named rom files while their hashes differ...

1.png: showing split merged mode, all files keep their old naming
2.png and 3.png: switched to full merged mode, the affected rom names change to setname/romname format
4.png: a not affected set keeps the old naming, no matter if full merge mode is enabled or not

Works pretty fine already....you end up with subfolders for hash collisions.... I've decided to put all roms of the set in question into subfolders, not only the ones with hash collisions...looks better in my opinion...

To Do:
- add the option for the new merge mode where you always want to create clones in subpaths
- export dat function should of course use the normal naming
- check the other well known database read-in correction: nodumps which have a real-dump name clone inside their parent/clone relation....wonder if I can introduce something similar...

[Roman]

while looking at it...

in case of a hash collision it might make even more sense to mark all clones to use subfolders....
so a fully merged set got subfolders as soon as you you one or more hash collisions within its parent/clone relationship...In the posted pictures that would mean that the set in 4.png would also get subfolders...even if that clone does not have a real problem.

It's simply that the to-be-created fully merges zip/7z/rar would look better and more understandable.....parent files on root...and all clone files in subfolders named after the clone set....

...and a general option to use that in any case (not only hash collisions)...

[f205v]

...and a general option to use that in any case (not only hash collisions)...

This I like very much! 

[Cassiel]

ok...while the 32k path support seems to work (wonder if anyone tested it yet)...

Not yet, but planning too... busy converting TBs of archives from RAR2.9 to RAR5.0!

[Roman]

;-)

[Roman]

coming closer....

- option for new full merge mode is in.....(hi f205v ;-))
- general handling of the subfolders works fine
- export uses the original naming
- "Possible wrong nodump definition found" dat parser warning prompt is also removed.....this is simply a special case of hash collision and so it'll be handled the same way as other hash collisions...

have to check one minor (nodump) merger thingie...and I guess then we can have a test round....