Preface / Introduction

If you've been playing Minecraft for awhile and got into modding recently, then you'll sooner or later end up in a tangled mess of multiple files which serve the same purpose. Modding Minecraft, going across multiple platforms, needing to reconfigure controls, figuring out where specific screenshots are — for the average human being, it's pain and suffering to stare at their computer, only to not figure out where things are on its media, or end up with a corrupted mess of a game because they loaded a world with different content than when they had started.

Before reading on, there are a few things which need to be understood first to know what exactly this article will cover, prior to improving your existing installations and comprehend what exactly these mythical, magical symbolic links are.

Scope

This will assume the following from individuals reading it:

• There is an interest in modifying the game beyond use of resource packs
  
• There is no interest using third-party launchers — Nothing else but Mojang's launcher binary exists
• Viewers are capable of, and do not mind reading mind-numbingly boring, dry, lengthy text about a subject to do something very cool.

What this guide will not cover, as there is other content which present this information better than I ever could:

• Installing mod loader platforms
• installing specific combinations of modifications*
• Use of resource packs — archived and unpacked.
• Modification of Java launch parametres

*: Some mods will be mentioned as examples.

Understanding this, there shouldn't be any difficulty encountered when reading, aside from the stringing of long words. For anything outside of this scope not covered in brief, don't ask questions to anything else but your preferred Internet search provider. I'm sure there's another article on PMC which would answer all of your other burning questions should you seek it out.

Profile management

Not many people getting into this stuff for the first time — or even the second time — know about this, but this foreknowledge will help to understand how I have things set up on my end, which will make the examples provided here easier to understand.

In brief (without pictures); From the official Minecraft launcher: Visit the installations tab. For each installation, there is an ellipsis (…) which provides other options than Play, choose Edit. From there, the game directory and its browse button beckons — Click it, and select any location. But there is a place the launcher already provides to keep the various game binaries organized which you can also use to keep individual game profiles organized.

Organizing the dirty way

The versions directory, held within .minecraft — Visit it and behold as every version of the game available locally is displayed. But what if you hadn't launched the game yet? If using formal releases of the game which aren't pre-releases or snapshots, they'd simply go by version number. So let's say 1.16.4 already exists but you're a PvP nerd who needs 1.12. The game will generate a directory in .minecraft/versions named 1.12, but only to host the game binary (JAR) and backend configuration (JSON). Everything else can exist there too if any of these version directories are used to store files generated by the game as defined in each profile's Game directory — And since you already know the directory is going to be named 1.12, you can create this directory on the launcher's behalf.

If you missed the mark on a directory name there, or just used something you would recognize for the time being, that is fine. Game directory can be changed and files can be moved to the new location later, just understand that the files must be moved by you since the launcher will never move files for you. Understand if following this advice, the game binary and backend config are separate, independent entities that must remain in its respective directory at versions — there is no reason to reuse these files elsewhere.

Modded Minecraft

If a mod loader had been installed, then there already exists a place to put mod files in versions since each platform will create its own binary and backend config to load mod content. Their respective directories are also a good place to keep a variety of other directories directly related to that particular build of the game — The core build can be modified, for other profiles using the same build to use, which is something this forum thread will explain as a practical use of symbolic links.

Mod loader platforms only function because they modify existing files. So before installation of any platform, its respective game of the correct version for the installation binary must be ran first to generate a local copy in .minecraft/versions. But like typical version directories, all other files — mods, configurations and vanilla files can also exist where the modified game binary and backend config exist.

Symbolic links

This won't be a comprehensive about symbolic links, only cliff notes. There are two types of symbolic links:

• Soft links
  These are absolute references to file locations. While portable between machines if configured correctly (using relative paths and going up directory levels through your system's text console) they are more likely to break on a local machine because they require the original file to exist. Without such, each link is broken as it refers to a non-existent file. Compatible partition formats for these kinds of links are NTFS, Ext4 and APFS.
• Hard links
  These are direct references to an index / ID of an existing file. Journaling partition formats will typically keep mutually exclusive the location of a file and its index reference. This means when a file is removed from a media, its index in the journal is free to represent another file as no file refers to a specific index. Hard links also use an existing index, and the original file will not be considered removed until all copies of the file no longer exist
  
  That's right — A file with hard links will be considered existing even if the original file had been removed from the system, because all files representing its index had not been removed. Compatible partition formats for these kinds of links are NTFS and Ext4. Apple's APFS will auto-convert hard links to soft links if they had existed previously. Do note that open-source systems actively dissuade users from creating hard links, and hard-linking directories usually isn't possible at the kernel level because that could cause breakages in the file tree structure used by practically every OS in existence.

What to use?

If uncertain, use soft links. Windows further complicates things by providing two types of directory links — soft-linked directories and junctions. Google is your friend here, though if using junctions in Windows, they'll be recognized as compatible symbolic links on any open-source system should the reader of this writ choose to abandon Windows in favour for an alternative OS, most likely using the Linux kernel, so whatever is used really doesn't matter.

Issues on Windows

Due to how painfully difficult it is to use mklink and Powershell cmdlet New-item, only examples for persons using a system with the Linux kernel will be presented, as GNU Coreutils' ln is the easiest to comprehend and use. All hope is not lost for Windows users, however — A solution for making symbolic links easier to create by Hermann Schinagl exists for adding GUI features which both define the files / directories to be linked and their destination by the name of Link Shell Extension, and as a user of open-source solutions i couldn't be any more jealous of how this is implemented. It really is that good and I recommend it for people getting into application of bigger game mods on Windows.

Examples

For people who are still reading this far in and are interested in exercising this, here are a few examples which can be used on a regular basis to use separate profiles while recycling such things as controls, screenshots and adding otherwise world-breaking mods into a new directory for individuals who are wanting to give use of symbolic links a try.

The following assumes GNU / Linux only because of issues previously mentioned for Microsoft Windows. See the section above for something Windows users can install which would allow practical application of symbolic links without having one's own eyes glaze over staring at a text console and needing to be an insufferable nerd.

Screenshots to pictures

Pictures taken using the F2 key (default for taking a screenshot) are kept in .minecraft/screenshots but what if for sake of organization screenshots were kept in pictures instead? The following will work to perform as such, assuming there was content which exists in the first place — if not, screenshots could be deleted outright. While not necessary, the following steps will also create a separate directory inside of pictures to keep content made in the game tidy.
mkdir -p $HOME/Pictures/minecraft/screenshots
mv $HOME/.minecraft/screenshots/*.* $HOME/Pictures/minecraft/screenshots
rmdir $HOME/.minecraft/screenshots
ln -s $HOME/Pictures/minecraft/screenshots $HOME/.minecraft/screenshotsIf keeping separate directories for separate profiles, different directories based on existing profile names can be used to keep them distinct, while putting images in a specific location more familiar to you. The above is functional code, as $HOME is a variable used for /home/$USER, $USER being the current active user of a system session.

Use of "Core" installations

For users of mods, this will come in relatively handy to create what is essentially a template for future mod packs and self-made mod suites. After defining what is considered "Necessary" for a mod platform — whatever will be used across every single profile thereafter — and executing said profile for configuration, and possibly testing in a new temporary world to make sure things are exactly how they're suppose to be by matter of opinion, everything can be linked into a separate game directory location quite easily.

The example below assumes use of separate profiles keeping everything which isn't default in $HOME/.minecraft/versions, using Fabric loader. cd is used to keep things simple. OptiFine is highlighted, under assumption there is a desire to try out multiple video rendering methods or in case there are issues with OptiFine, using template as a means of continued play if OptiFine were ever updated and somehow becomes non-functional.
cd $HOME/.minecraft/versions/fabric-loader-0.10.8-1.16.4
mkdir $PWD/_optifine
cd $PWD/_optifine
ln -s $PWD/../* $PWD
rm -rf $PWD/fabric-loader-*.* $PWD/mods $PWD/config
mkdir $PWD/mods
mkdir $PWD/config
ln -s $PWD/../mods/* $PWD/mods
ln -s $PWD/../config/* $PWD/configWhy the removal of mods and config after initial linking? Because new directories were made which allow for reuse of existing JAR and JSON files while allowing for addition of new files, without tainting the source mods and config directories. This means OptiFine and OptiFabric could be included and it won't be in the template.

Since this is an example about OptiFine, OptiFine-only emissives-capable resource packs wouldn't be a problem because the capability in vanilla simply does not exist, and wouldn't directly affect gameplay. What would affect gameplay is use of other biomes and features like Immersive Portals. Modpacks would also probably include a lot of features not included in vanilla and thus, should have their mods and config held entirely separate from template similarly, as well to never share saves and mod-specific servers with other profiles / installations of the game.

Use of resource packs for different game versions

Have a beloved resource pack which should be for almost every available version of Minecraft? Want to pick and choose textures between versions of a mod? Fear not — These two examples will allow for compatibility _while_ using more current graphics where applicable. This first one assumes use of VanillaTweaks in its unpacked form; decompressed and in its own directory somewhere on local system for both 1.12 and 1.16. (Assuming $HOME/Documents/minecraft/resourcepacks for this.)

If one wanted to use the borderless glass from 1.16.4 for 1.12, should both variants exist unpacked in the assumed directory for this example:
cd $HOME/Documents/minecraft/resourcepacks/1.12/VanillaTweaks/assets/minecraft/textures/block
rm -rf $PWD/*_stained_glass.png $PWD/glass.png
ln -s $PWD/../../../../../1.16.4/VanillaTweaks/assets/minecraft/textures/block/*_stained_glass.png $PWD
ln -s $PWD/../../../../../1.16.4/VanillaTweaks/assets/minecraft/textures/block/glass.png $PWDcodHaving separate resource pack directories are completely meaningless without a means to use them, so symbolic links can help in this regard. Assuming everything from above, this example would replace 1.12 and 1.16.4 resource pack locations with the content from $HOME/Documents/minecraft/resourcepacks:
rm -rf $HOME/.minecraft/versions/1.12/resourcepacks $HOME/.minecraft/versions/1.16.4/resourcepacks
ln -s $HOME/Documents/minecraft/1.12/resourcepacks $HOME/.minecraft/versions/1.12/resourcepacks
ln -s $HOME/Documents/minecraft/1.16.4/resourcepacks $HOME/.minecraft/versions/1.16.4/resourcepacksOnce finished, assuming both examples were followed a profile for 1.12 and 1.16.4 would be using the same kind of resource pack, but with differences per-version when acquired from VanillaTweaks.net, except being unpacked, 1.16.4 glass textures would be used in 1.12 — a distinct advantage for people doing PvP stuff in 1.12 having more clear glass.

tl;dr: Do I need this?

No. Absolutely not. If you have a sizable storage media and don't mind duplicates for everything, then carry on not using any kind of links in the local device's filesystem. If files are stored on an ExFAT or FAT32 partition, then linking is impossible because those formats are not journaling partition formats, so reading this whole thing is a massive waste of time and effort understanding something which could never be. But being aware of this option can lead to some very powerful directory management for persons with lacking media space or for neat freaks who want to keep their filesystem as DRY as possible — DRY as in, Don't Repeat Yourself.