Linux/Mac: DLC Directory Ordering Issues

NOTE: OSX's historical filesystem, HFS+, does not have this problem but starting with 10.13/High Sierra, APFS is starting to be used, and that does appear to have the same problem that Linux users have. If anybody has experience setting up alternate mountpoints in macOS, let us know (or edit this page) to let us know how to address it on those platforms.

This is a rather bizarre issue, due to some cross-platform differences between Windows and Linux, and because of some behaviors of the Borderlands engine. It's worth noting that this issue doesn't actually affect much - you'll miss out on some statements which modify gun parts, mostly - so don't sweat it if you don't want to deal with this.

Basically, when looking for DLC on your hard drive, Borderlands looks inside the steamassets/dlc directory and loads the mods in the order they're given by the kernel. On Windows, the filesystem driver will return the directories in alphabetical order by default. On Linux, the order of the directories is effectively random. (When looking at a directory listing via ls on Linux, the ls command does the sorting for you. If you want to see the "native" order in which the directory entries are given, you can run "ls -U" or "ls --sort=none".)

As the engine loads these DLC, some of the property names get dynamically-assigned number suffixes, and the numbers depend on what order the DLC is loaded. Mods which try to edit these values need to hardcode a number to use -- any mod written/tested on Windows is going to be using the numbers you get by sorting the directories alphabetically. For instance, the internal part list collection for one class mod from the Dragon Keep DLC has this property name:

GD_Aster_ItemGrades.ClassMods.BalDef_ClassMod_Aster_Assassin:ItemPartListCollectionDefinition_28

However, the last number could easily be something else, like:

GD_Aster_ItemGrades.ClassMods.BalDef_ClassMod_Aster_Assassin:ItemPartListCollectionDefinition_42

And on other Linux systems it could be something different. There's no way to actually predict what number it'll be. This doesn't have a super wide impact, since there aren't that many mods which actually touch these variables, but UCP does contain a few statements which do, and you'll risk not getting the full effect of some mods.
So, how do I fix this?

Unfortunately, the only real fix for this is to mount your Borderlands DLC directory under a separate filesystem which supports sorting directories alphabetically. No native Linux filesystem does this. It's possible to disable some features on an ext4 filesystem, so that directory entries will be given in the order in which they were created. So theoretically you could create an ext4 partition, use the following tune2fs command on it:

# tune2fs -O ^dir_index /dev/foo

... and then carefully copy the DLC directories into that filesystem, one at a time, in alphabetical order. That method seems quite fragile to me, though, and I wouldn't recommend that even though you'd still be using a native Linux FS.

What I've done on my own system is to just resign myself to using NTFS. The Borderlands 2 DLC dir contains a little over 6GB of data, so I created a new 10GB LVM LV, used "mkfs.ntfs /dev/vg/bl2dlc" (obviously substitute the proper device name there), copied over all the DLC data into that new filesystem, and then added the following to my /etc/fstab -