disk: fix data corruption on 256-byte sector images#362
Open
erichelgeson wants to merge 1 commit intomainfrom
Open
disk: fix data corruption on 256-byte sector images#362erichelgeson wants to merge 1 commit intomainfrom
erichelgeson wants to merge 1 commit intomainfrom
Conversation
Two related bugs surfaced on images formatted with 256-byte SCSI sectors (fixes from PR #348, simplified): 1. start_dataInTransfer() used readSectorsDirect with count >> 9 when fastseek was enabled, silently dropping the trailing 256 bytes on odd-block transfers and reading the wrong 512 bytes when the file position was not 512-aligned. Gate the direct-read path on bytesPerSector == SD_SECTOR_SIZE; 256-byte images take the regular img.file.read() path. 2. ImageBackingStore::read/write kept m_fsfile's position stale while serving contiguous raw-block I/O. On the first unaligned access the code flipped m_iscontiguous=false and fell back to m_fsfile still sitting at offset 0, corrupting both reads (wrong data) and writes (overwrote the image header). Sync m_fsfile from m_cursector before the mode transition in both read() and write(). Co-Authored-By: Per Mårtensson <pm@sweproj.com>
BlueSCSI Memory ReportCompared against release Memory Usage
Symbol Region ChangesPico_2_Audio_SPDIF: 3 symbols moved FLASH → RAM (+12 B)
Pico_2_Audio_SPDIF: 9 symbols moved RAM → FLASH (-298 B RAM)
Pico_2_DaynaPORT: 3 symbols moved FLASH → RAM (+12 B)
Pico_2_DaynaPORT: 9 symbols moved RAM → FLASH (-298 B RAM)
Pico_Audio_SPDIF: 13 symbols moved FLASH → RAM (+2.0 KB)
Pico_Audio_SPDIF: 43 symbols moved RAM → FLASH (-5.3 KB RAM)
Pico_DaynaPORT: 34 symbols moved FLASH → RAM (+7.2 KB)
Pico_DaynaPORT: 3 symbols moved RAM → FLASH (-1.2 KB RAM)
Ultra: 4 symbols moved FLASH → RAM (+16 B)
Ultra: 9 symbols moved RAM → FLASH (-298 B RAM)
Ultra_Wide: 4 symbols moved FLASH → RAM (+16 B)
Ultra_Wide: 9 symbols moved RAM → FLASH (-298 B RAM)
|
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.
Two related bugs surfaced on images formatted with 256-byte SCSI sectors.
start_dataInTransfer() used readSectorsDirect with count >> 9 when fastseek was enabled, silently dropping the trailing 256 bytes on odd-block transfers and reading the wrong 512 bytes when the file position was not 512-aligned. Gate the direct-read path on bytesPerSector == SD_SECTOR_SIZE; 256-byte images take the regular img.file.read() path.
ImageBackingStore::read/write kept m_fsfile's position stale while serving contiguous raw-block I/O. On the first unaligned access the code flipped m_iscontiguous=false and fell back to m_fsfile still sitting at offset 0, corrupting both reads (wrong data) and writes (overwrote the image header). Sync m_fsfile from m_cursector before the mode transition in both read() and write().
Replaces #348