Fix file sizes in the data tab (WIP) #1453
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The bug was that if a file had an origin from an archive, the size from the archive was always shown even if the conflict was won by another mod.
When a file from disk is added for the first time to the register (in
DirectoryEntry::onFile()
), its file size isNoFileSize
by default because it's not available. This is forwarded to the Data tab, which will get the size on disk of the file the first time it's shown in the tree. However, if one of the origins of the file is from an archive, bsatk helpfully gives the size, so that's added to the register (seeDirectoryEntry::addFiles()
, not in diff below).The problem was that if another origin was added that has a higher prio, that file size from the BSA was never cleared to
NoFileSize
, which prevented the Data tab from getting the size on disk and always displayed the size from the BSA.So the file size is now set to
NoFileSize
when adding a file from the disk. This clears whatever size might be have been set if a previous origin was from an archive.I also removed
Cached::override()
, I'm not sure what the purpose was (yes, I wrote it). It looks like it was to prevent fetching the file size again if it was available from a BSA, but it makes no sense and would prevent the file size from being updated ever again even if the winning origin of a file changed. So that's gone too.Fixes #1454.