emmercm / igir

🕹 A zero-setup ROM collection manager that sorts, filters, extracts or archives, patches, and reports on collections of any size on any OS.
https://igir.io/
GNU General Public License v3.0
390 stars 18 forks source link

arcade strategy creates zips with empty files (CRC 00000000) #695

Closed nottanumber closed 1 year ago

nottanumber commented 1 year ago

Paste the command

thanks for fixing the other one so fast

similar issue to #691 but a bit different

npx igir@latest zip copy test clean report --dat $MAME_EXE --input '.\ROMs-New\194*.zip' --output .\ROMs-Sorted\ --merge-roms merged

couldn't repro with just input being 1942.zip alone

Describe the bug

ERROR: 0.258 (mame0258): .\ROMs-Sorted\1942.zip: written zip has the file 7.bin with the CRC 00000000, expected 30f13e78

correct 7.bin exists alongside this one in the generated zip

Expected behavior

no duplicate files in zip

Debug logs

ERROR: 0.258 (mame0258): .\ROMs-Sorted\1942.zip: written zip has the file 7.bin with the CRC 00000000, expected 30f13e78

DAT(s) used

mame0258 exe

igir version

2.0.1

Node.js version

v20.6.1

Operating system

win

Additional context

No response

emmercm commented 1 year ago

A few clarifying questions @nottanumber:

Pasting an unzip -l 1942.zip might help debug here.

emmercm commented 1 year ago

I'm able to reproduce when trying to build a merged 1942 set given a relatively complete MAME v0.258 set.

I don't know why it's 00000000, but I suspect the root issue is because of different clones having different 3.bins, from pleasuredome:

<rom name="1942abl\3.bin" size="32768" crc="f3184f5a" sha1="a566c344ee1f63580d41aca95ece9ad1f7a135d2" />
<rom name="1942p\3.bin" size="16384" crc="108fda63" sha1="6ffdf57a04bcfae9fdb2343f30cff50926188cbf" />
cinnamonmatexfce commented 1 year ago

I suspect the root issue is because of different clones having different 3.bins, from pleasuredome:

Hey @emmercm, it's not strictly related to a specific DAT (or XML) per se (PleasureDome, in this case). Rather, merged sets do want subfolders inside Parent (this being .zip and/or folder) indeed. This is done in order to overcome samename roms conflicts (which happen very often precisely in the case of merged sets).

In this case, an output like that would be expected:

/1942/
    sb-0.f1
    sb-1.k6
    sb-2.d1
    sb-3.d2
    sb-4.d6
    sb-5.e8
    sb-6.e9
    sb-7.e10
    sb-8.k3
    sb-9.m11
    sr-01.c11
    sr-02.f2
    sr-08.a1
    sr-09.a2
    sr-10.a3
    sr-11.a4
    sr-12.a5
    sr-13.a6
    sr-14.l1
    sr-15.l2
    sr-16.n1
    sr-17.n2
    srb-03.m3
    srb-04.m4
    srb-05.m5
    srb-06.m6
    srb-07.m7
    1942abl/

        3.bin
        5.bin
        7.bin
        9.bin
        11.bin
        13.bin
        14.bin
        16.bin

    1942p/
        1.bin
        2.bin
        3.bin
        04.bin
        5.bin
        6.bin
        7.bin

        9.bin
        10.bin
        11.bin
        12.bin

This is the case when you merge entire 1942abl and 1942p clones sets inside their own subfolders, even if there's only one rom which has name-collision: <rom name="3.bin".


I'm hoping being somewhat useful here! 👋

emmercm commented 1 year ago

You're entirely right @cinnamonmatexfce. I had done the merge/split code knowing this subdirectory structure, but some code elsewhere was stripping subdirectory information from archived files. I'll have a fix shortly!

github-actions[bot] commented 1 year ago

:lock: Inactive issue lock

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Comment generated by the GitHub Lock Issues workflow.