search

ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.18k stars 173 forks source link

[Feature Requests] Removing Stray Non-Steam Game Files and Data #10184

Open sonic2kk opened 8 months ago

sonic2kk commented 8 months ago

Your system information

Please describe your issue in as much detail as possible:

When adding a Non-Steam Game, Steam will generate a seemingly random AppID, adding the same game with the same information will always produce a different AppID. This part is fine. The problem is that Steam leaves behind some information and files in this process. Some examples:

Non-Steam Game Grids

Non-Steam Game grids are not removed. Steam sets grids in ~/.local/share/Steam/userdata/<id>/config/grid, and the names are associated with the game's AppID. For Non-Steam Games, this might be 240315734_hero.jpg. But when the Non-Steam Game is removed, Steam won't remove this artwork. If someone is using animated library artwork, this could get really large really fast, as some animated assets can exceed double-digit megabytes. And since the artwork cannot be re-used again for that game as the AppID is random, these files are entirely unused. There is a case where the same AppID could be generated for the same game or an unrelated game.

Some utility software, like Steam-ROM-Manager and SteamTinkerLaunch, generate consistent AppIDs by writing a deterministic AppID for the shortcut entry into shortcuts.vdf, so in those cases the artwork can be re-used, but I still think it makes more sense for Steam to remove these stray files.

A user can perform this step manually, but I'm not sure how many users would think to remove the artwork first.

Non-Steam Proton Prefixes

Non-Steam Proton prefixes are not removed. When running a Non-Steam Game with Proton, as far as I can tell it always creates a compatdata at ~/.local/share/Steam/steamapps/compatdata/<nonsteam-appid>. This could also just be the compatdata in the default library folder that a user selected, but I didn't check and my default library folder is the one on my boot drive, so the Non-Steam compatdata folders are created there.

Steam doesn't remove the compatdata when regular Steam games are refunded, removed from account, or uninstalled. In the case of uninstalled games that does make sense, a user may choose to reinstall the game and they would want to keep their save data. But for Non-Steam Games, again because the AppID is different each time the game is added, the prefix can never be re-used, so it is effectively ~300mb lost for each Non-Steam Game ran via Proton.

This one may be better as a setting somewhere, since utility software can set a deterministic AppID for Non-Steam Games and in thoose cases the prefix can be re-used, but it would also be fair enough to ignore those tools and expect users to manage and back up their Non-Steam compatdata folders.

This is also the only part of this feature request that is specific to Steam for Linux :-)

CompatToolMapping Entries Stay in config.vdf

This one is less severe. Steam has a file called config.vdf (text VDF, not a binary VDF file like appinfo.vdf or shortcuts.vdf) which stores a lot of information, including a block called CompatToolMapping. This section stores information about which games (by AppID) are using which compatibility tools. The name of the compatibility tool is based on the internal name of the tool as defined in its compatibilitytools.vdf file. The first entry, "0", is the default global compatibility tool.

Non-Steam Games are also added to this file, their entries using the unsigned integer AppID. When a shortcut is removed from Steam, this entry is not removed with it. This has two implications:

  1. When adding a Non-Steam Game via Steam, because the AppID is random, this entry is effectively unused when a game is removed and re-added. The entry should be removed since it will not be used again, and since the AppID has a (cosmic) chance of being used again for another Non-Steam Game, that new game could incorrectly use this compatibility tool mapping. If this mapping is for a tool that is no longer installed, the mapping will likely be corrected to just be blank.
  2. When using a third-party tool, if this tool does not update existing entries in config.vdf, it may either add a new mapping which could conflict/get discarded/is just all around not a great idea, or it may ignore an existing entry and not set a compatibility tool.

It seems better to me overall that, if Steam is going to generate a random AppID, it should discard, it should discard any information hinging on this AppID as it is effectively unusable once the game is removed.

This issue only covers games being removed directly from Steam and not when shortcuts.vdf is modified directly or removed. In those cases, I don't think it's possible for Steam to know that Non-Steam Games were removed, though for config.vdf it may be feasible to check if there are entries for AppIDs that are no longer in the library. The same could possibly be said for grids and compatdata. But in those cases, Steam has a higher chance of removing something unintentionally, so I can understand the perspective of simply doing nothing in cases where shortcuts.vdf is modified. But when using the client directly, I think it makes sense to do this sort of cleanup.

There may be more examples, but these are just the ones I have encountered :-) And to be clear, I don't think any of these are "bugs", hence why I have labelled this as a feature request.

Thanks!

Steps for reproducing this issue:

Non-Steam Game Grids:

  1. Add a Non-Steam Game to Steam from the Steam Client.
  2. Set some artwork, either manually putting into the grids folder or setting it directly from the client.
  3. Remove this Non-Steam Game.
  4. Artwork persists at the Steam game grids folder.
  5. Re-add the Non-Steam Game, with all of the same information as before (path, exe, name, etc).
  6. Artwork is not re-used, because the AppID is different.

Non-Steam Game Prefixes:

  1. Add a Non-Steam Game to Steam from the Steam Client.
  2. Right-click on the game -> Properties -> Compatibility -> Force the use of a Steam Play Compatibility Tool
  3. Select a Proton-based compatibility tool, such as "Proton 8.0".
  4. Launch the game with this compatibility tool selected and then close it.
  5. Navigate to ~/.local/share/Steam/steamapps/compatdata
  6. There should be a new compatdata created with the AppID of the Non-Steam Game (these AppIDs are always 9 digits, making them stand out).
  7. Remove this Non-Steam Game from Steam.
  8. The compatdata is not removed
  9. Re-add the Non-Steam Game, with all of the same information as before (path, exe, name, etc), force this game to use the a Proton compatibility tool like earlier, launch and close the game
  10. A new compatdata will be created for the new AppID for the Non-Steam Game, and the old compatdata will persist

Non-Steam Game config.vdf Entries

  1. Add a Non-Steam Game to Steam from the Steam Client.
  2. Right-click on the game -> Properties -> Compatibility -> Force the use of a Steam Play Compatibility Tool
  3. Select a Proton-based compatibility tool, such as "Proton 8.0".
  4. Navigate to ~/.local/share/Steam/config/ and open config.vdf
  5. Look for the CompatToolMapping block, and at the bottom there should be an entry for the Non-Steam Game (this AppID is always 9 digits, making it stand out, and the newest entry is always appended to the bottom of this CompatToolMapping)
  6. Remove this Non-Steam Game from Steam.
  7. In config.vdf, the mapping for this AppID in CompatToolMapping is not removed.
  8. Re-add the Non-Steam Game, with all of the same information as before (path, exe, name, etc), force this game to use the a Proton compatibility tool like earlier, and check config.vdf
  9. The old mapping entry will still be there, and a new entry for the new AppID will have been created and appended as the newest entry at the bottom of the mappings.

Restarting Steam does not affect the behaviour of any of these three cases.

sonic2kk commented 8 months ago

Another potentially related bit to this: Steam stores user-collections information for removed Steam shortcuts in localconfig.vdf. When these shortcuts are removed Steam still keeps them in localconfig.vdf. I think this information may also be pulled from a LevelDB so it may also/actually need to be removed from there in the first place.

sonic2kk commented 3 months ago

Steam does now seem to remove compatdata folders for Non-Steam Games but I'm not sure if the other parts of this issue are solved.

sonic2kk commented 1 month ago

Steam will remove Non-Steam Game compatdatas as noted above, as well as their CompatToolMappings from config.vdf. However it is still missing the following: