Skip to content

Comments

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
henrikstengaard:fix-fat-load-entries
Feb 18, 2026
Merged

Fix fat load entries update end of entries when cluster doesnt contain end marker entry#58
LTRData merged 1 commit intoLTRData:LTRData.DiscUtils-initialfrom
henrikstengaard:fix-fat-load-entries

Conversation

@henrikstengaard
Copy link

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 added when 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 (_endOfEntries variable) 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 exception An item with the same key has already been added is 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 _endOfEntries variable 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.

@henrikstengaard
Copy link
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.

@henrikstengaard henrikstengaard marked this pull request as ready for review February 17, 2026 11:31
@henrikstengaard
Copy link
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.

@LTRData LTRData merged commit cbb822c into LTRData:LTRData.DiscUtils-initial Feb 18, 2026
1 check passed
@LTRData
Copy link
Owner

LTRData commented Feb 18, 2026

Perfect! Thanks a lot for your contribution!

I'll get new NuGet packages out soon!

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants