Hi! It's another Linux blog post! But Windows' users get to have fun with this too, and without needing to bang on their plank as often by means of Hermann Schinagl's Link Shell Extension utility. In spite of that, GNU Coreutils' ln is much easier to understand textually, and people of good mental health with sufficient critical problem solving skills should be able to match up commands to actions via such a utility.

Introduction

Mods are great. But, the issue with mods is when they update. If you use mods which update a whole lot and need to link them across multiple profiles, or simply want to provision for linking across multiple profiles should one mod somehow be compatible with multiple platforms (i.e. Architectury API-dependent mods), then this guide will help you out.

Concept

If you want to use a mod that continually updates and may have multiple releases per Minecraft version (i.e. OptiFine), and if you're already using links like I am for use across multiple profiles (for either testing, or specific configurations for different game experiences) then when a mod has an update for your specific game version available, it can be a right pain in the ass to maintain and manage these mods across multiple profiles.

I already use a similar setup personally for my local filesystem, because while I use an open-source partition format for my Linux-based system (by mandate), I use NTFS to keep compatibility with Microsoft Windows so if I do anything in my NTFS part, it'll apply to both my Windows and Linux system instances — if my partition label changes, I can easily resolve this problem by creating one link and the other links will take as a directory which exists, so long other links aren't broken in the process of referencing it. Very useful for transferring personal effects to another disk, or preparing to migrate — Post-migration, just establish the link once more if necessary and fix everything in one fell swoop.

Localizing this idea to Minecraft, and playing by the rules of your system while using Ext4, APFS or NTFS, one can make many, many profiles with the same core suite of mods and so long naming on the local filesystem remains consistent, links to certain mods can be re-established after upgrade and that will literally be used as-is, which means if the name of a file matches an existing reference, then existing references will use the replacement as if it were the original.

Mind this probably won't work entirely with hard links. hard links rely on an existing index and a new file typically means a new index, so softlinks should be used to be on the safe side. But the core link other links will use should be hard linked if possible, if keeping the original and link copies in the same partition.

Execution

So let's say you keep your mods in .minecraft/versions to not mix things up.
> cd $HOME/b/.minecraft/versions/fabricMods
> ls --format=single-column $PWD
'[1.16.2][Fabric]+RPG-HUD-3.8.1.jar'
architectury-1.2.68-fabric.jar
bedrockify-0.1.9-1.16.2+.jar
fabric-api-0.28.4+1.16.jar
lambdacontrols-fabric-1.5.0+1.16.2.jar
light-overlay-5.5.4.jar
modmenu-1.14.9+build.13.jar
optifabric-1.8.16.jar
OptiFine_1.16.4_HD_U_G5.jar
Lots of mods, right? And lots of different version numbers to keep track of. If you have any more than three profiles in Minecraft using most of the same stuff, re-linking gets real annoying, real fast.

Let's do something about it. A quick fix in this instance would be to create a new directory where only the most current release (or releases relevant to a specific Minecraft build) is linked. If you need something version-specific (like a couple weeks back when you needed to have a specific version of Fabric API to use OptiFabric) then you can just pull from your mods repository a specific release. But for multiple Minecraft versions you can (and should) have directories for specific versions of the game.

For brevity, we'll just go with the second-most current version of Minecraft since not every server and mod is at parity with 1.16.5. So in this instance 1.16.4 would be the most current game version. Nonetheless. we'll still make directories for specific mod versions that may become updated over time.

Let's say you do this in current directory where those mods are at.> mkdir $PWD/1.16.4
> cd $PWD/1.16.4

From hereon, it should be understood that ".." is used to represent one level up. This is mostly universal across modern and legacy operating systems, and for those which support symbolic linking going up a specific number of directories can be used with symbolic links.

For the current directory, while "." and "$PWD" are functionally similar, they are not the same and if using such in scripting, caution should be taken to ensure appropriate syntax for ongoing tasks is used for best results. In this context — a written tutorial about managing one's local filesystem — "$PWD" is exclusively used as a working example to highlight the current directory in use, even if "." is equally as functional. Both can be used.

Once in there, then the following can be done to link everything:> ln ../* .If you follow this example all of the time, you will and must have to delete like mods of different versions, and incompatible mods depending on what conflicts with any profile upon execution. Afterward, rename them, one at a time with mv or using your file manager. This might take awhile, but use some friendly names. This is what I came up with:> ls --format=single-column $PWD
rpg-hud.jar
architectury.jar
bedrockify.jar
fabric-api.jar
lambdacontrols.jar
light-overlay.jar
modmenu.jar
optifabric.jar
optifine.jarNow of course, you do not get version numbers. But you should already know in your mind which is what, and if you do not then no fault of mine if you elect to not keep a sticky note or text file of some kind to keep track of changes yourself. This is where soft links reign supreme — While they can't be used like the actual file as in, if the original were moved, the reference breaks when the original were moved, they're easier to trace using basic terminal commands. If you use soft links, then you can find which files are linked with the following:
ls -l | grep lrwxAnything which begins with "lrwx" represents a link with read, write and execute privileges. Likely, links will be 777 in octal format — owners, groups and others have permissions to manipulate it. You can't fix this, but it doesn't need fixing because links will functionally inherit the permissions of the original file anyway.

Use and updates

So right... all of the above is done... now what? Since the first-level links had been established, those can now be used for every profile using 1.16.4. and they take basically no space! They aren't zero-byte, as in, they're a handful of bytes each but it's a sore sight better than them taking up more space as duplicates. So now these links are established, they can be used elsewhere as soft links. As follows:> cd ../../fabric-loader-0.10.8-1.16.4/mods
ln -s ../../fabricMods/1.16.4/* .The game will use and respect these files as the actual files. But then, updates happen. As OptiFine for 1.16.4 was updated today as of this writing, changing the version of OptiFine in use would be as simple as saving the file where your Fabric mods are, and re-establishing the link. Building off of the previous examples presented here:> cd $HOME/b/.minecraft/versions/fabricMods/1.16.4
> rm -rf ./optifine.jar
> ln -s ../OptiFine_1.16.4_HD_U_G6.jar ./optifine.jarHow is this easier? For a single profile, it isn't — In fairness, for something unique (like say, immersive Portals, Twilight Forest, Aether etc.) such drastic non-vanilla, game-altering mods can be used as-is, since they likely wouldn't be in multiple profiles unless you have multiple profiles using these modifications with different renderers or different resource pack configurations. (At which point, it would be easier to create different settings files with different resource pack configs for convenience sake). But if using the same suite of mods across multiple profiles, replacing a link is better than replacing every single instance in every single profile.

This isn't limited to just game mods either — if you like to keep game saves somewhere else as a layer of data security (should your system or effects partitions fail, your game saves exist on-site but on another disk) you can re-establish your system, then re-link your world saves once your new system instance is configured, sans whatever other data you might had lost.

Overall, if you get heavy-duty into modding, then being especially persinikity about how your files are kept and used on your local filesystem now should save you hours of regret in the future.