Add API to provide cache and data directories #934
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is very work in progress, I look forward to getting some input on this:
The goal with this PR is to strongly define all of the locations on the filesystem where a mod should read/write files. Currently the only defined directory is
./config
. This is useful for a few reasons, its easier for the developer as they do not need to implement platform specific code, better for the user as all of the mods files are located togeather and allows for new technology such as the fabric-sandbox.This PR adds 4 new directories that mods can use to store data:
getCacheDir()
returns an instance specific directory for mods to store data that should be cached across runs. Fabric loader uses this to cache the remapped jars. The contents of this directory can be regenerated if deleted.getGlobalCacheDir()
returns a location that is shared across all instances of Fabric Loader (regardless of Launcher or Game). This can be used to cache files across multiple instances, an example of this might be downloading addional files required for your mod. As above contents of this directory can be regenerated if deleted.getDataDir()
returns an instance specific directory for mods to store user generated data. This directory should be included in mod packs. An example of this may be client side map data (when playing on an MP server), schematics, blueprints. Basically anything that isnt a human editable file should go here (otherwise it lives in/config
).getGlobalDataDir()
is similar to the global cache dir, but may be included in computer backups or synced across computer (E.G Active directory on windows). This directory may be used to store files such as private keys to encrypt secrets, the secrets themselves, or just user configuration that should persist to all instances of the game.It is not expected that a user will ever manualy edit files in these locations. A sandbox may grant full access to all of these directories, without any isolation. Thus untrusted code must not be executed from these locations.
A mod ideally should not be saving any files outside of these locations + /config and the save directory.
On a server the global directories are stored within the servers directory, and are not shared between instances.
I am very much open to feedback on these locations, we should try our best to ensure that they are good, as changing them later will be difficult to do without introducing breaking changes.
Extra care needs to be taken to test this on a range of linux platforms/launchers, especially those using Docker, Flatpacks and Snaps. This can be tested easily by copying this code in a mod.