You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What compatibility tool are you using?: Proton 9.0 (temporarily switched to Proton-GE in an attempt to remove steam-runtime-sniper but it did not let me, but also Proton is not relevant to the issue)
What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt? 0.20240806.0
What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt? 0.20241118.108551
What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt? 0.20241118.108552
Please describe your issue in as much detail as possible:
I'm running Steam from the Flatpak.
Steam Runtime Sniper creates a folder Steam/ubuntu12_64/steam-runtime-sniper/var/tmp-XXXXXX in its file structure where the XXXXXX changes every time Steam launches. I tried looking for other reported issues about this folder and it's allegedly being hardlinked from somewhere else rather than unpacking the runtime again every launch, but I'm also far from the only person that's had a weird issue with this folder.
I use rsync to backup my home directory. If I have launched Steam at any time since the last backup, the tmp-XXXXXX folder will change its name. At backup time approximately one gigabyte of data at the remote server will be deleted and a presumably identical gigabyte of data will be copied again as if it were completely new files.
Is there a way to make Steam stop recreating/renaming this folder? I tried to get my friends to reproduce this problem and apparently this folder was not getting renamed for them. I don't know any details about their setup other than it's a different distro but they were also using a Flatpak.
Of course I can work around the problem by excluding this folder in my rsync command. That's fine. But I think this is a problem that should be solved at the runtime so that less technical users don't have to worry about it. I think it's reasonable to expect someone could want a one-click backup solution with no strange gotchas to work around.
Steps for reproducing this issue:
Launch Steam
Backup your home directory
Close and relaunch Steam
Backup your home directory again
Watch your backup software delete Steam/ubuntu12_64/steam-runtime-sniper/var/tmp-XXXXXX and copy Steam/ubuntu12_64/steam-runtime-sniper/var/tmp-YYYYYY
Repeat ad nauseum until your NAS' storage wears out
The text was updated successfully, but these errors were encountered:
Steam Runtime Sniper creates a folder Steam/ubuntu12_64/steam-runtime-sniper/var/tmp-XXXXXX in its file structure where the XXXXXX changes every time Steam launches.
Yes.
it's allegedly being hardlinked from somewhere else rather than unpacking the runtime again every launch
That's 99% true. Directories, empty (0 byte) files and symlinks are newly created every time, but non-empty files are hard links to the corresponding version of the file as distributed with Steam (so the amount of disk space taken is trivially small: it's only metadata, no data).
Is there a way to make Steam stop recreating/renaming this folder?
No, there is not. In general it is technically necessary for it to have a unique name: when more than one game runs at the same time, or when the Steampipe depot gets updated while a game is running, the running game needs to be using an independent "view" of the runtime, so that its root filesystem will not unexpectedly disappear from under it and cause a crash.
(The copy under steam-runtime-sniper is used to run Steam itself rather than games, so it doesn't necessarily have that constraint; but fewer code paths mean fewer bugs, so it's mechanically the same as what's used to run the actual games.)
A Steam installation already contains a very large amount of data that comes from Steam's various CDNs and does not need to be backed up, and in particular none of the SteamLinuxRuntime_* and steam-runtime-* directories need to be backed up, so I would recommend adding wider exclusion rules than just var/.
One thing that we could usefully do to make many backup tools avoid this directory would be to create a var/CACHEDIR.TAG (for tar --exclude-caches and similar), although unfortunately rsync doesn't support that anyway. Or we could maybe create a var/.rsync-filter for rsync -F along the same principle.
Your system information
steamapps/common/SteamLinuxRuntime/VERSIONS.txt
? 0.20240806.0steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt
? 0.20241118.108551steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt
? 0.20241118.108552Please describe your issue in as much detail as possible:
I'm running Steam from the Flatpak.
Steam Runtime Sniper creates a folder
Steam/ubuntu12_64/steam-runtime-sniper/var/tmp-XXXXXX
in its file structure where theXXXXXX
changes every time Steam launches. I tried looking for other reported issues about this folder and it's allegedly being hardlinked from somewhere else rather than unpacking the runtime again every launch, but I'm also far from the only person that's had a weird issue with this folder.I use rsync to backup my home directory. If I have launched Steam at any time since the last backup, the
tmp-XXXXXX
folder will change its name. At backup time approximately one gigabyte of data at the remote server will be deleted and a presumably identical gigabyte of data will be copied again as if it were completely new files.Is there a way to make Steam stop recreating/renaming this folder? I tried to get my friends to reproduce this problem and apparently this folder was not getting renamed for them. I don't know any details about their setup other than it's a different distro but they were also using a Flatpak.
Of course I can work around the problem by excluding this folder in my rsync command. That's fine. But I think this is a problem that should be solved at the runtime so that less technical users don't have to worry about it. I think it's reasonable to expect someone could want a one-click backup solution with no strange gotchas to work around.
Steps for reproducing this issue:
Steam/ubuntu12_64/steam-runtime-sniper/var/tmp-XXXXXX
and copySteam/ubuntu12_64/steam-runtime-sniper/var/tmp-YYYYYY
The text was updated successfully, but these errors were encountered: