Every Windows install of my game failed, and Steam blamed the player's disk

I got a screenshot from a Windows machine with a Steam dialog on it: DOWNLOAD FEHLGESCHLAGEN — Fehler beim Schreiben auf den Datenträger. Download failed, error writing to disk.

That is a message about a bad drive, a full disk, or antivirus. It is not a message about my game. The same machine had installed another game into the same steamapps folder ninety seconds later, which ruled out all three. So the next place to look was the one file nobody thinks to read: Steam\logs\content_log.txt.

Failed updating depot 5188191 while creating symlink (Disk write failure)
"C:\...\steamapps\downloading\5188190\linux\.DirIcon"

Not a write. A symlink. And look at the path: a Windows client was staging a folder called linux.

The cause

Unelevated Windows has no SeCreateSymbolicLinkPrivilege — creating a symbolic link needs Developer Mode or administrator rights. Steam's content pipeline hits one, cannot make it, and aborts the entire install.

Why was a Windows player downloading Linux files at all? Because I had put all three platforms in one depot. A depot is Steam's unit of content, and I had reasoned that one depot was simpler than three: the launch options already pointed at windows/Catacrawl.exe, macos/Catacrawl.app and linux/Catacrawl.sh, so each platform would just run its own folder.

Each platform did run its own folder. Every platform also downloaded all three. And two of those three are full of symlinks: the extracted Linux AppImage has .DirIcon → love.svg, and the macOS bundle carries thirty-nine framework aliases — SDL2.framework/SDL2, Versions/Current, and so on. The first one Steam reached killed the install.

So every Windows install of Catacrawl had always failed, for everyone, since the first build went up. I develop on a Mac. My own installs worked perfectly.

The fix, and the thing that made it worse before it got better

One depot per operating system, each with its OS filter set, each installing at the install root. Windows players now download 2 MB instead of 98 MB, which was a pleasant accident. The macOS and Linux depots keep their symlinks, because those systems have them and because codesign flatly refuses a framework bundle without Versions/Current — flattening the app was never an option.

Then I documented the deploy order backwards, and it cost a day. My note said: upload the new build first, then publish the Steamworks settings, because publishing first applies the new Windows-only filter to the old build and leaves macOS and Linux owners with nothing to download until the new one goes live. That reasoning is correct about the risk and wrong about the mechanism. SteamPipe reads the published app config, not the draft. A depot that exists only in the unpublished draft is not a depot you may upload to:

ERROR! Failed to initialize build on server (Access Denied) for depot 5188192

So the order is forced: publish, upload, set live, and do all three in one sitting because the window between the first and the third is a window where two platforms have no installable build.

What I actually changed afterwards

Not the docs. A preflight. tools/steam/check_depot.sh now runs before every upload and refuses anything a client cannot install, checked against each depot's own target OS: symlinks in a Windows depot, paths that differ only in case (fatal on Windows and macOS, both case-insensitive — while writing this, a cp between two such names silently deleted love.dll), reserved device names like CON, characters Windows forbids, paths near MAX_PATH, and a depot whose launch target is missing.

The lesson is narrower than "test on Windows", which I could not do and which would not have been the insight anyway. It is this: a build that compiles, runs and uploads is not a build that installs. Nothing about this was visible from my machine, from a green test suite, or from the Steamworks build list — only from a Windows client's log file. And Steam reports the failure as a disk error on the player's own machine, so the player will not report it to you either. They will just refund.

It works now. The first successful Windows install of this game happened three weeks after the first Windows build went up.