Fix fat load entries update end of entries when cluster doesnt contain end marker entry#58
Merged
LTRData merged 1 commit intoLTRData:LTRData.DiscUtils-initialfrom Feb 18, 2026
Conversation
…n end marker entry
Author
|
I switched the PR to draft as there might be more corner cases to this issue. I used my custom build nuget packages with this fix, but it fails after more files are creates in a subdirectory with same exception thrown. |
Author
|
After more testing it turns out I didn't build nuget packages properly and the latest changes from by branch was not included. Rebuild the nuget packages and repeated tests and can confirm it works. |
Owner
|
Perfect! Thanks a lot for your contribution! I'll get new NuGet packages out soon! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR fixes an issue with FAT partition when creating 20 files in a subdirectory where each file is created with a new instance of FatFileSystem.
This results in the exception
An item with the same key has already been addedwhen the subdirectory contains 16 entries with a FAT formatted floppy using a cluster size of 512 bytes. The 16 entries consists of a self entry, a parent entry and 14 file entries, each with the size of 32 bytes and in total 32 * 16 = 512 bytes.When the FatFileSystem loads directory entries, it creates an internal dictionary with entry position as key (used for fast lookup) from the position in of the entry in the cluster and that method only sets next entry position (
_endOfEntriesvariable) when it reaches an entry with end marker name / end of cluster. The next entry position is used when new entries are added and since it's not updated after loading directory entries, it will start from 0 cause entries to be overwritten and this is why the exceptionAn item with the same key has already been addedis thrown. This is also why no new cluster is allocated for the new entry that should have been added to the end of entries in the cluster.To fix the issue, I have added a line at the end of the while loop that loads entries from a directory to ensure
_endOfEntriesvariable is always set to the next entry position. The variable is still updated, if end marker entry is reached.Two tests was added used to compare the difference between creating one FatFileSystem instance used to create 20 files and creating a FatFileSystem instance for each file to create.