Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libloot fails to find master on Linux because of case-sensitivity #67

Open
khadoran opened this issue May 28, 2020 · 6 comments
Open

libloot fails to find master on Linux because of case-sensitivity #67

khadoran opened this issue May 28, 2020 · 6 comments
Labels

Comments

@khadoran
Copy link

I found it when using libloot v.0.15.1 with Skyrim Special Edition. The following load order is used:

[...]
HearthFires.esm
[...]
AyleidCitadel.esp
[...]

Both files, of course, exist with the name matching the above.

AyleidCitadel.esp contains Hearthfires.esm as master (note the lower case f) which causes loading of the plugin to fail (missing master) on Linux.

Even on Linux with the string comparison being case-sensitive, the names in the TES4 record should be compared case-insensitively when trying to find the corresponding master.

The corresponding mod can be found here: https://www.nexusmods.com/skyrimspecialedition/mods/11307

@Ortham
Copy link
Member

Ortham commented May 28, 2020

This isn't an issue with LOOT: if AyleidCitadel.esp has Hearthfires.esm instead of HearthFires.esm, that's an issue with that plugin (except not really, I think it's unreasonable to expect case correctness when it's not normally required).

Have you tried installing Skyrim SE in a case-insensitive filesystem?

@khadoran
Copy link
Author

Yes, that's why I thought, LOOT should handle it. I don't have any case-insensitive file system to test it with and a virtual file system would be too large as I need it for 4 games.

Would an option to "enforce using case-insensitivity" make sense to let the user decide?

@Ortham
Copy link
Member

Ortham commented Jun 1, 2020

No, emulating filesystem case-insensitivity at an application level sounds like a recipe for all sorts of weird edge cases to me. It's bad enough that libloot already has to attempt to compare filenames case-insensitively without getting the filesystem involved, I don't want to open that can of worms any further.

@khadoran
Copy link
Author

khadoran commented Jun 6, 2020

Sorry for my late answer.

I understand your concerns, especially looking from a library's point of view. I just hoped for an easy way to do automated installation and load order management provided by libloot with a Linux-native application. So, I guess, using the Windows version of loot with wine will also do the trick and I just do the mod installation with Linux-native application.

Thank you for the clarification.

@Ortham
Copy link
Member

Ortham commented Jun 7, 2020

For future reference, loot/loot#1095 is also about case-sensitive paths on Linux and offers a couple of solutions.

@Ortham Ortham added the linux label Jun 7, 2020
@Ortham
Copy link
Member

Ortham commented Aug 22, 2023

Aside from data read from game files not matching the case of filenames in the filesystem, libloot also hardcodes the following file extensions and uses them to construct paths that may fall foul of case-sensitivity:

  • - Textures is used to construct BSA filenames to look for when searching for BSAs associated with a plugin.
  • .ba2 and .bsa are used to construct archive filenames to look for when searching for BSAs associated with a plugin.
  • .ghost is used to construct plugin filenames to load when the unghosted filename is given but does not exist.
  • Condition evaluation looks for lowercase .esp, .esm, .esl extensions and .ghost extensions on those.

It's possible to reimplement these to avoid using the string literals as part of filenames, though it would be slower and more complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants