Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save space by using a generic prefix #1806

Closed
2 tasks done
Rabcor opened this issue Oct 23, 2018 · 4 comments
Closed
2 tasks done

Save space by using a generic prefix #1806

Rabcor opened this issue Oct 23, 2018 · 4 comments

Comments

@Rabcor
Copy link

Rabcor commented Oct 23, 2018

Feature Request

I would like it if proton had a generic proton prefix (something like compatdata/proton/pfx) which it would use as the default prefix for all games that don't need prefix specific workarounds. This way potentially large amounts of disk space could be saved.

I confirm:

  • that I haven't found another request for this feature.
  • that I have checked whether there are updates for my system available that
    contain this feature already.

Description

As things stand, proton doesn't seem to do anything on a per-prefix basis for any game, so the compatdata directory with all the per-game prefixes is mostly just a collection of duplicate prefixes.

On average these prefixes seem to add 1GB+ to space needed for installed games. Additionally, sometimes prefixes will be created with unrelated user files (for example save-games for other titles than the one the prefix is used for) further adding to this space use.

This should be an option, whether it should be the default can be debated. As things stand it is better to have per-game prefixes because it allows for better testing (if users need to modify their prefix, let's say by installing .NET Framework or some DX redists, they may as a side effect be able to run other games out of the box too.) but when proton is more mature, having one generic prefix that can be used for all games that don't need specific workarounds would be highly preferable.

I would suggest looking into how lutris handles prefixes (sometimes referred to by them as runners) for insights into better ways for implementing multiple prefixes while still using one (or few) prefixes for most games.

Justification

Excessive use of disk space for no real gain to the end-user. (With just 14 games installed I am using 15gb of disk space for proton prefixes alone)

Risks

False compatibility reports from users who have modified their prefix. (This may be avoidable if steam/proton will install with a configuration utility, something similar to winetricks/protontricks, which would create a separate prefix for a target game when the user wants to make changes, preferably with an option to override the generic/main proton prefix as an option for advanced users/people who don't intend to make compatibility reports)

@dlove67
Copy link

dlove67 commented Oct 23, 2018

Symlinks could be a better option, since you could then keep the prefixes for each AppID, but push changes when needed.

@lucifertdark
Copy link

Proton already has a default prefix in the main Proton folder, for me it's in "Proton 3.16/dist/share/default_pfx" it's copying the contents of that to the compatdata folder for each game.

@kisak-valve
Copy link
Member

Hello @Rabcor, this feature request is already being discussed at #1011, so I've gone ahead and transferred this issue report to #1011 (comment).

Closing in favor of the existing feature request.

@Rabcor
Copy link
Author

Rabcor commented Oct 23, 2018

Symlinks could be a better option, since you could then keep the prefixes for each AppID, but push changes when needed.

Well I would have suggested that but both wine and steam seem to have issues with symlinks. I recall not being able to use proton if I symlinked my steam library to a different location for example. I believe it's because wine cannot follow symlinks to executables, or something like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants