Repository navigation
tools: a refused delete sends the board no path - #95
Merged
SensoriumEmbedded merged 1 commit intoNov 10, 2026
Merged
Conversation
Link.delete() sent the drive byte and the path whatever its token's reply was. A board with any IO handler but the menu's current answers a file command with FailToken and "Busy!" and goes back to reading one-letter serial commands, so it ran the path as commands: in /c128test/t80b.prg the 'e' reset its EEPROM to defaults, 'c' cleared the debug log and 't' changed bus timing. post() deletes first, so every push to a busy board did this, and the post token's own "Busy!" afterwards hid it. delete() now goes through ack() like post(), listdir() and launch(), so a refusal stops it and is reported as the delete that was refused. The fake board in the tests refuses file commands while busy and records the bytes the firmware would run as commands.
kfox
marked this pull request as ready for review
November 10, 2026 15:05
SensoriumEmbedded
left a comment
Owner
There was a problem hiding this comment.
Thank you for catching this one, an EEPROM reset from a file push is a nasty one to track down!
I reviewed this merged onto current main (ac24701). Nothing to change, merging now.
Thank you!
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.
Link.delete()intools/bench/trlink.pysent its drive byte and path whatever the reply to its token was. While any IO handler other than the menu's is current, the full firmware answers a file command withFailTokenandBusy!and reads nothing more (SerUSBIO.ino, theCurrentIOHandler != IOH_TeensyROMrefusal), so the path bytes that followed were run as one-letter serial commands. Pushing/c128test/t80b.prgto a board with REU+USB Mouse/Disk as Special IO reset its EEPROM to defaults (theein "test"), cleared the debug log (c) and started a timing command (t).post()deletes first, so everypush.pyto a busy board did this, and theBusy!on the post token that followed hid it.delete()now checks its token reply withack(), aspost(),listdir()andlaunch()already did. A refused delete sends nothing further and fails asdelete <path>: FAIL - Busy!. The delete's second reply is still not checked, because the firmware answers "File not found" for a new file, which is the usual case for a push.The other bench tools were checked for the same pattern:
spans.pyalready checks for the ack before each payload, and the rest send each command in one write or send nothing after a reply.Verification
test_a_busy_board_is_sent_no_path_to_run_as_commands, pushes to a fake board that refuses file commands while busy and records every byte the firmware would run as a command. Before the fix it failed withb'\x01/c128test/t80b.prg\x00' != b''; after, it passes. Putting the oldself.rd(2)back in place of the ack check makes it fail again.python3 -m unittest discover -s tools/bench: 86 tests, OK.npm test: pass.Reviewed at
low(23 changed code lines), no findings.