fix: keep Steam out of an endless update loop
Steam compares its installed files against its manifest at every start and restores whatever differs, which is why its launcher entry carries -noverifyfiles. The entry in ~/.config/autostart never got it: it points at /usr/bin/steam, a shell script, so it fell through the Chromium filter in mca_autostart_apply and was left alone. A Steam started at login therefore verified, found the web helper script 46 bytes larger than the manifest says, restored it, and the path unit patched it straight back - an update dialog that begins again every few seconds and never finishes. The same client started from the menu was fine, which is what made it look like a problem of Steam's own. The autostart entry now carries the switch as well. It follows the Steam setting rather than the autostart one, because leaving it out while Steam is patched is exactly what causes the loop. That covers the entry that exists; a terminal or a script still starts Steam without the switch. So the patch no longer fights back either: a script that was patched before, is not patched now, and belongs to a client that is still running has just been restored by Steam, and doing it again would only have the two of them undoing each other. It waits for the next apply with Steam closed - the helper is started once, at the start, so patching it now would not have helped that session anyway. Also: Steam does not checksum that script, it compares sizes - the log says "Verifying file sizes only" - while the comments and the documentation claimed otherwise. And the status screen now tells a patch that is waiting from one that is missing, instead of reporting both as not patched yet.
This commit is contained in:
1 parent
4004023297
commit
f42d80598f
9 files changed
+135
-23
No files matched your search
@@ -118,17 +118,26 @@ Steam's own installation:
|
||||
~/.local/share/Steam/ubuntu12_64/steamwebhelper_sniper_wrap.sh
|
||||
```
|
||||
|
||||
Steam checksums that script at every start and restores it when it differs, so
|
||||
its launcher entry also gets `-noverifyfiles`. **The trade-off is real**: with
|
||||
verification off, Steam no longer repairs a damaged installation by itself. That
|
||||
is why Steam is a switch of its own rather than part of the general handling —
|
||||
turn it off in the settings and Steam is left completely alone.
|
||||
Steam compares the installed files against its manifest at every start — by
|
||||
size, not by content — and restores whatever differs, so its launcher entry gets
|
||||
`-noverifyfiles`. So does its entry in `~/.config/autostart`, which Steam writes
|
||||
as soon as it is set to run at login: that one bypasses the menu entry entirely,
|
||||
and without the switch a Steam started at login finds the patched script,
|
||||
restores it, gets patched again, and never gets past its update dialog.
|
||||
|
||||
**The trade-off is real**: with verification off, Steam no longer repairs a
|
||||
damaged installation by itself. That is why Steam is a switch of its own rather
|
||||
than part of the general handling — turn it off in the settings and Steam is
|
||||
left completely alone.
|
||||
|
||||
The script comes back on every client update. The watcher notices and puts the
|
||||
patch back.
|
||||
|
||||
Starting Steam from a terminal without `-noverifyfiles` undoes it for that one
|
||||
session; the next start from the menu has it again.
|
||||
Starting Steam some other way — from a terminal, from a script — leaves the
|
||||
switch out and Steam puts its own copy back for that session. The patch returns
|
||||
at the next apply with Steam closed; it is deliberately not repeated while the
|
||||
client is running, because the two would only undo each other and the helper is
|
||||
started once, at the start.
|
||||
|
||||
## Applications installed later
|
||||
|
||||
|
||||
Reference in new issue
Block a user