Windows portable EXE creates a `Saved games` folder in EXE directory even if a different `savepath=` is specified.

[nimaid]

Version: ScummVM 2026.3.0, Windows x64 zipfile, portable mode

Summary

When running the Windows zipfile version of ScummVM in portable mode (scummvm.ini included in the same directory as scummvm.exe), no matter where the saved games folder is set using the --savepath= argument or via the savepath= field in scummvm.ini, a folder named Saved games is created in the same directory as scummvm.exe. Games do actually save to the savepath= location, but even if that is set somewhere other than the directory where scummvm.exe resides, if the scummvm directory is read-only, it will fail to launch with the following error: Cannot create ScummVM Saved games folder

Recreating

The easiest way to recreate this is to make an ISO with the following directory structure:

MyCD.iso\
  - scummvm\
    - scummvm.exe
    - scummvm.ini
  - Run.bat

The scummvm.ini file can be blank.

The contents of Run.bat should be as follows:

@echo off

set "SCRIPT_DIR=%~dp0"
if "%SCRIPT_DIR:~-1%"=="\" set "SCRIPT_DIR=%SCRIPT_DIR:~0,-1%"

set "SCUMMVM=%SCRIPT_DIR%\scummvm\scummvm.exe"

set "SAVE_DIR=%APPDATA%\ScummVM\Saved Games"
set "SCREENSHOT_DIR=%USERPROFILE%\Pictures\ScummVM Screenshots"
set "LOG_DIR=%APPDATA%\ScummVM\Logs"

if not exist "%SAVE_DIR%" mkdir "%SAVE_DIR%"
if not exist "%SCREENSHOT_DIR%" mkdir "%SCREENSHOT_DIR%"
if not exist "%LOG_DIR%" mkdir "%LOG_DIR%"


start "" /b "%SCUMMVM%" --savepath="%SAVE_DIR%" --screenshotpath="%SCREENSHOT_DIR%" --logfile="%LOG_DIR%\logfile.log"

As you can see, the savepath along with the other paths are set in the %APPDATA% and %USERPROFILE% folders on the C:\ drive, so one might expect that portable ScummVM would have no reason left to try and write to the program directory, which of course, on a CD is read-only and would fail.

Mount MyCD.iso as a virtual disk (modern Windows supports this natively), and run Run.bat. You should get the error: Cannot create ScummVM Saved games folder

Now extract that ISO to a folder named MyCD. Try running Run.bat again, and note how while the program starts up without issue, it creates an unused Saved games folder next to scummvm.exe. This confirms the error was due to ScummVM trying to write to the read-only CD.

Desired Behavior

The desired behavior is for the Windows zipfile in portable mode to create a new saved games folder wherever is specified in either the scummvm.ini file or via the --savepath= argument. This way, it would be possible to run scummvm.exe from read-only media like a CD while saving the data somewhere on the local hard drive. Currently trying to do this *would* work if it weren't for the hard-coded folder failing to be created in the same folder as scummvm.exe regardless of the actual setting for the --savepath= argument or the savepath= field in scummvm.ini.

Bug Location in Source Code

I have tracked down the issue to [a specific line of code in backends/saves/windows/windows-saves.cpp](​https://github.com/scummvm/scummvm/blob/ff4e32d90c625b512ed0346bc5d3c7f6ef6e9ac3/backends/saves/windows/windows-saves.cpp#L41):

...
    if (isPortable) {
        Win32::getProcessDirectory(defaultSavepath, MAX_PATH);  // <-- BUG HERE
        // Should override this behavior if `savepath` is specified via argument or `scummvm.ini`
    } else {
        // Use the Application Data directory of the user profile
        if (!Win32::getApplicationDataDirectory(defaultSavepath)) {
            return;
        }
    }

    _tcscat(defaultSavepath, TEXT("\\Saved games"));
    if (!CreateDirectory(defaultSavepath, nullptr)) {
        if (GetLastError() != ERROR_ALREADY_EXISTS)
            error("Cannot create ScummVM Saved games folder");
    }
...

I'm not familiar enough with the structure of this project to make a PR to fix it. But I hope this bug report is at least detailed enough to enable someone else to fix it soon! Thank you all so much for all you contribute to this project! <3

[sluicebox]

The question is if portable-mode paths override the command line. This ticket assumes they shouldn't. But maybe it was our intent to override everything. (It was a long time ago.) It's a question of priority.

The pull request I added portable mode: ​https://github.com/scummvm/scummvm/pull/3499

This ticket looks AI generated and that kills any enthusiasm to engage with it. "The easiest way to recreate this is to make an ISO"... oh yeah that's the easiest way to test a command line argument.

At this point I'm only posting in self defense so that someone else isn't fooled by into taking the wrong action. Obviously the "Bug Location in Source Code" is nonsense. Again, I'm just posting in self dense.

This ticket has upset me. I regret checking the tracker today. I fear for my future on a project where every time I sit down to do some work I'm rewarded with these frustrations and wastes of time.