Introduction
One of the problems with loading loose file mods into Fallout 4 is the Case issue. Specifically Windows is case insensitive when it comes to folder names. On the other hand Linux is case sensitive. In some cases it is a problem that needs to be solved.
When talking about case insensitive or case sensitive folder naming, what is specificity meant is that windows sees the folders “test and “Test” as the same folder. Windows does not enforce capitalization differences of names.
Most File systems used on Linux, do see a difference between “test” and “Test”. These are two different folders.
If we install a mod on a Linux system, we have a chance of ending up with two folders only differentiated by capital and small letters. This is a problem because even though WINE and Proton can run Windows programs on Linux Systems, they cannot control how files are saved and arranged in storage.
The Issue
Fallout 4 mods that use loose files can experience issues based solely on the differences between how Windows and Linux based systems handles file and folder names. In this article we will specifically focus on folder names.
For our first example let us create a folder called “meshes” in Windows 10. In the same location lets create a folder called “Meshes”. Windows will inform us that the folder called “meshes already exists.
And if one searches for the folder “Meshes”, one ends up at the folder “meshes”.
What this means is that Windows ignores the case of letters in folder names.
If we perform the same exercise on a Linux based system, Linux will happy create both folders; “meshes” and Meshes”. This means that Linux folder names are case sensitive, and “meshes” is not the same folder as “Meshes”.
Lets next look at an example from a common and popular Fallout 4 Mod; Caliente’s Beautiful Bodies Enhancer (CBBE). Lets extract the mod files to a folder. If we look inside the “Required” folder we find the folder “meshes”.
Now if we look inside the folder “14 Outfits Vanilla – Vanilla”, we find the folder “Meshes”. If we extract the files we need from the mod, then on a Windows system we will have either “meshes” or “Meshes” depending on which one was extracted first. And everything needed will be in that one folder.
However if we do it on a Linux based system we will have both the “meshes” and the “Meshes” folders. This means our files are now spread across two folders instead of all being in one folder.
This type of issue is not an emulation or translation error, but an example of how different file systems handle folder names differently. On Windows you are probably using the NTFS file system (or maybe a FAT file system). On Linux systems you could be using ext4, xfs, btrfs, zfs, etc.
This is not the sort of thing a translation layer, like wine or proton, will either catch or correct.
Fix it With BASH
Warning: The below script was written and tested in BASH 5.3.9. While it may run on older versions, it has not been tested. Likewise it has not been tested with other non-BASH shell environments. Proceed with caution.
To determine your shell and version, use the following commands.
echo "$SHELL"
echo "$BASH_VERSION"
In this article I am going to create a BASH script that will scan an extracted Fallout 4 Mod folder, and fix name issues that can cause problems with some mods.
I should note I am assuming manual modding, and a specific order of events.
- Unpack the Mod Archive into a temporary folder
- Run the script in the temporary folder before installing the mod
- Install the mod.
- Clean or delete the temporary folder
Note also that mods using only ba2, esp, and esl files do not have this issue. It is only applicable to mods with loose files.
Scripting: Shebang
As with all bash scripts, we start with a Shebang. A Shebang is the first line of a script identifying the type of shell.
#!/usr/bin/env bash
Note, some might be more familiar with the shorter #!/bin/bash Shebang. However, not all distributions store files in the same locations. If bash is not accessible via the bin directory the script will not run.
Scripting: Comments
Any time I write any sort of program or script, I want to include some basic information close to the top of the file. This reminds me of what I was doing at the time. It can be especially important if you open a script months or years later. So always use comments, as they do not take up much space. At a bare minimum I recommend including the following comments right after the Shebang.
# title :
# version :
# author :
# last update :
# description :
# Usage :
This is my minimum suggestion. You can always add more. However I need to point out that while adding more comments does not take up much storage space, there is a maintenance cost in keeping comments updated. So do not go overboard.
Scripting: Variables, Constants and Arrays
My standard practice, especially for scripts not making function calls is to define all my variables and constants up front. When dealing with functions and sub routines, you can run into local versus global issues. But since this script is short, so I will define everything up front.
Since this script works with Fallout 4 mod folders, we need to define the path and folder name. As opposed to hard coding them, I will be pulling them from the command line.
ModFolder="${1:?Usage: $0 <ModFolder>}"
$0 is the script name, and $1 is the first user-supplied argument. Using bash parameter expansion, ${1:?message} causes the script to immediately exit with message if $1 is unset or empty. Since $0 expands to the script name, the message in this case is “Usage: <script name> <ModFolder>.
Next we need a list of problematic folder names. We use an associative array with the problematic names as the key, and the correct names as the value.
declare -A NameMap=(
["meshes"]="Meshes"
["textures"]="Textures"
["materials"]="Materials"
["actors"]="Actors"
["character"]="Character"
["characterassets"]="CharacterAssets"
)
The declare -A declaration creates an associative array. Each entry maps a key (the problematic name) to a value (the corrected name). When we encounter a folder name that matches a key, we can look up the corrected value by key and apply the fix.
Locating the Problematic Folders
This next section of code can appear somewhat complex, mainly because several things are going on at once. While I am presenting the code as a single block, there are several independent but related processes occurring. The key is to understand the individual processes and how they relate to each other.
find "$ModFolder" -depth -type d -print0 |
while IFS= read -r -d '' Dir; do
base="$(basename "$Dir")"
new="${NameMap[$base]:-}"
if [[ -n "$new" && "$base" != "$new" ]]; then
mv -n -- "$Dir" "$(dirname "$Dir")/$new"
fi
done
The find command is used to search the $ModFolder recursively The -depth option starts at the deepest level of the directory structure. The -type d option specifies directories only. And -print0 will output every folder within the directory structure separated by a NUL character.
Each result is piped to a while loop. IFS stands for Internal Filed Separator, in this case NUL, preventing things like line feeds and spaces being used as separators. The read -r option reads raw data, not escaping special characters like back slashes. The -d ” option sets the NUL as the deliminator between entries. And Dir is the variable each new folder path and name is temporally stored in. This loop will continue until there until no more NUL entries are found, that is we reach the end of the find provided directory names.
The basename function is used to strip the path information from the directory name stored in $Dir, which is then stored in the $base variable.
Next we query the associative array, NameMap, using the folder name stored in $base. If there is a key match, then the variable $new will be set to that keys value. If there is no match, then the :- sets $new to an empty string.
The if/then statement makes two checks, both of which must be true. First we check if $new is an empty string with -n “$new”. Next is the and clause, “&&”, meaning both conditions must be true. The second condition is that $base != $new. Since $base is the key and $new is the value for that key, they should not be equal.
Once we have a folder that needs to be corrected we call the mv command. The -n option keeps mv from affecting an already existing entry. The — shows the end of options. $Dir is the path and folder pulled by find. The dirname command keeps the path and drops the folder for $Dir. Then we add the slash, “/”, and $new which contains the new folder name.
We finish looping when we run out of folders.
Conclusion
To help with the installation of mods based on loose files on Linux, the bash script presented will scan an extracted mod archive and find/correct any folder naming convention issues. Specifically the difference between how Windows and Linux handle case in folder names.
Below is the file in its entirety. Just copy the code into a text editor and save it with an .sh extension. Don’t forget to change the file permissions, making it executable.
Complete Script
#!/usr/bin/env bash
# title : FO4ModCaseFixer.sh
# version : 1.0.3
# author : Retired Techie
# last update : 2026 JUL 22
# description : Reads base folder and adjusts case on problematic folder
# Usage : FO4ModCaseFixer.sh ./<path to mod folder>
# get mod folder from command line
ModFolder="${1:?Usage: $0 <ModFolder>}"
# build Associative Array
declare -A NameMap=(
["meshes"]="Meshes"
["textures"]="Textures"
["materials"]="Materials"
["actors"]="Actors"
["character"]="Character"
["characterassets"]="CharacterAssets"
)
# Recursively scan/change problimatic mod folder
find "$ModFolder" -depth -type d -print0 |
while IFS= read -r -d '' dir; do
base="$(basename "$dir")"
new="${NameMap[$base]:-}"
if [[ -n "$new" && "$base" != "$new" ]]; then
mv -n -- "$dir" "$(dirname "$dir")/$new"
fi
done



Leave a Reply