Skip to content

v0.3.3 — the updater can actually update now

Choose a tag to compare

@github-actions github-actions released this 09 Aug 07:32
· 6 commits to main since this release

The in-plugin updater could not actually update anything on a normal install — and told you it had. Both defects were already fixed in Steamcord and had never been carried over here.

Fixed

Updates failed with Permission denied. Decky root-owns the plugin's top-level directory (and only that, plus plugin.json). The updater replaces each file by writing a temporary file next to it and renaming it into place, which needs write access to the directory — so creating that temporary file failed, even though the files being replaced belong to you and are perfectly writable.

Overwriting an existing file's contents only needs write permission on the file itself, so that is now used as a fallback when the temporary file cannot be created but the destination exists and is writable.

A failed update was reported as a success. apply() returns a dictionary, and {"ok": False, "error": …} is always truthy in Python. The boot-time auto-updater therefore treated every failure exactly like a success: it announced that the update had been installed and restarted Decky anyway — and did it again at the next boot, since the installed version had not moved. It now reads the result and logs why it gave up.

How this was found

Not from a report: the plugin failed to update itself on a real machine, logging Permission denied on its temporary file and, on the very next line, that the update had been installed. That contradiction is what exposed the second defect.

The fix was checked against the real failing scenario — an unwritable directory holding a writable destination file — with the actual code, not a reimplementation: contents replaced, permissions correct, no temporary file left behind.