Repository navigation
put --verify: the board keeps talking while it hashes a big file - #213
Merged
Merged
Conversation
Verifying a copy hashes the file on the board in one exec, which printed
nothing until it finished. mpremote gives up on a reply after 10 s with no
byte from the board, so an 8.5 MB file on an SD card that took longer to hash
was reported as a failed copy though it had landed intact ("timeout waiting
for first EOF reception"). The board now prints a dot every 64 KB while it
hashes, which mpftp ignores, and reads 2 KB per step instead of 512 bytes. A
board that really stops answering still times out after 10 s.
Closes #202
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.
putno longer reports a failed copy for a big file that landed intact. Verifying a copy hashes the file on the board in one exec that printed nothing until it finished, and mpremote gives up on a reply after 10 s with no byte from the board ("timeout waiting for first EOF reception"). The board now prints a dot every 64 KB while it hashes, which mpftp ignores, and reads 2 KB per step instead of 512 bytes. A board that really stops answering still times out after 10 s of silence. The same hashing serves serial, WebREPL and BLE, so all three get it.I reproduced the issue on an ESP32-S3 over WebREPL with an 8,589,932-byte random file on its internal flash: the released mpftp uploaded it in 3 min 20 s and then failed with "timeout waiting for first EOF reception". With this change the same
putfinished in the same time and reportedverifiedwith a SHA-256 equal to the local file's. A new test incli/tests/test_hash_file.pyhashes a file of that size through the board-side code and checks it prints at least one byte per 64 KB; it fails without the change. Not checked on the SD card of the board in the report.Closes #202