Misleading error message when JSBOOT.ZIP is write-protected

[thp]

I tested "SpaceButton" recently, and due to the way I transferred the game to my retro PC (using a CD-R), the game files were read-only, which resulted in an error message "Script name missing". Once the write-protection has been removed on the game data files, the game started working normally.

Steps to reproduce:

1. Download https://superilu.itch.io/spacebutton
2. Copy the files to a folder on a Windows 98 SE machine (not sure if relevant)
3. Select all files, open file properties, check the "Read-only" attribute
4. Try to start the game using run.bat (from within Windows, again not sure if relevant)

Expected result:

• Game gives an error message that the files are read-only, or game works with read-only files

Actual result:

• Game exits with the message "Script name missing."

[thp]

The message seems to come from here:

DOjS/src/DOjS.c

Line 888 in edeb867

fprintf(stderr, "Script name missing.\n\n");

Since the run.bat doesn't specify a script file, and JSBOOT.ZIP exists, and main.js in there is the file that should get picked up (I assume), this might be relevant:

        if (check_zipfile1(autostart_script)) {
            // we found a ZIP file with the name of the EXE and it has a MAIN.JS
            DOjS.params.script = autostart_script;
            DOjS.params.run = true;
        } else if (check_zipfile1(JSBOOT_ZIP AUTOSTART_FILE)) {
            // we found MAIN.JS inside JSBOOT.ZIP
            DOjS.params.script = JSBOOT_ZIP AUTOSTART_FILE;
            DOjS.params.run = true;
        }

check_zipfile1 in turn is defined here:

DOjS/src/zipfile.c

Line 780 in ee98b9e

bool check_zipfile1(const char *fname) {

..which in turn uses check_zipfile2(), which is here:

DOjS/src/zipfile.c

Line 812 in ee98b9e

bool check_zipfile2(const char *zname, const char *ename) {

Could be that one of these fails if the ZIP file is write-protected?

    struct zip_t *zip = zip_open(zname, 0, 'r');
    if (!zip) {
        return false;
    }

    if (zip_entry_open(zip, ename) < 0) {
        zip_close(zip);
        return false;
    }
    zip_entry_close(zip);
    zip_close(zip);

[thp]

I was able to reproduce the issue with DOSBox by making the files read-only (e.g. chmod -w * in macOS / Linux).

DOSBox says:

Warning: file ./JSBOOT.ZIP exists and failed to open in write mode.
Please Remove write-protection

So something is definitely trying to open the file in write mode and that fails.

Edit: Only making JSBOOT.ZIP read-write (keeping the rest of the files read-only) makes the game also boot up, so it seems to be some issue with reading ZIP files?

[thp]

Further digging shows:

DOjS/3rdparty/zip/src/zip.c

Line 800 in ee98b9e

struct zip_t *zip_open(const char *zipname, int level, char mode) {

..which calls mz_zip_reader_init_file_v2_rpb():

DOjS/3rdparty/zip/src/miniz.h

Line 5983 in ee98b9e

mz_bool mz_zip_reader_init_file_v2_rpb(mz_zip_archive *pZip,

..and that calls fopen() like this:

  pFile = MZ_FOPEN(pFilename, "r+b");

The r+ mode opens it in read/write mode, which makes it fail.

[SuperIlu]

updated to kuba/zip 0.2.5.
Will be fixed with v1.9