-
Notifications
You must be signed in to change notification settings - Fork 52
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
Files recognized as archives inside mods are extracted and not properly added to the mod #2367
Comments
I think we can look into repacking if we need to deploy an archive as an archive. |
I don't know if I would want to have something like a BSA extracted as loose files in our data store. Repacking on Apply seems quite a potential slowdown if you are dealing with a higher number of archives. I think I would rather lean towards the opposite, of extracting during mod installation, for only those installers that require this. |
See relevant comment:
Sounds good, there are some games where mods are supposed to contain zip files, so we should store the archive in the filestore still, hopefully restricting the extraction by file extension limits the size overhead problem. |
The issue is that we index and extract archives when they get added to the app. We don't know how the files are going to be installed, since we're just adding the files to the app. As such, when we actually get to the installer we already have indexed, extracted, and backed up all files. The only thing the installer can do at that point is repack the files from the NX archive into whatever archive format we had originally. |
|
There is a difference from getting the list of files contained in BSA and extracting and backing up all the files contained in a BSA. Doing the second would be big waste of time and space. For BG3, I get the list of files in the pak files from the pak header, I don't extract the pak files and backup all the contents. |
Bug Report
Outline:
If a mod added to the library contains a file that the app recognizes as an archive, the app will attempt to extract the contents of that archive, and the file entry is recorded as 0 sized file. It's unclear where the nested files end up.
This breaks installation of any mod that contains a file in archive format that should not be extracted.
Details
This was noticed in #2193, where a
Credits.xlsx
file (archive format containing Excel sheet) was missing from the App installation of a SDV collection.Investigation revealed that the file was being recognized as an archive, and a 0 sized ghost entry was present rather than the full archive as expected.
Steps to reproduce
What is the expected behaviour?
Not sure yet.
The reason this happens in the first place is to support the installation of certain mods that come with nested archives that need to be extracted during installation. We want to have all the files available upfront, before installation.
Tentatively, my assumption would be that we would want to potentially index all the child files, but also index the parent archive.
This could have the very bad downside of the app backing up data twice, both the archive contents and the archive itself.
If we encounter an entire game where such archives are common (e.g. if this where to happen for something like BSA archives), that would be pretty disastrous space efficiency wise and have big negative impact on Download finalization time (overhead of extracting the inner data).
The text was updated successfully, but these errors were encountered: