Repository navigation
Fix filesystem writability from USB - #10659
Merged
Merged
Conversation
dhalbert
pushed a commit
that referenced
this pull request
Jun 10, 2026
… bypass STA_PROTECT while they hold the lock Since #10659, filesystem_is_writable_by_python() returns false on any USB-device-capable board after main.c boot (CONCURRENT_WRITE_PROTECTED and USB_WRITABLE are both set). vfs_fat_diskio.c:disk_ioctl(IOCTL_STATUS) calls this function and reports STA_PROTECT when it returns false, so f_open(FA_WRITE) returns FR_WRITE_PROTECTED. This affects every non-USB-MSC writer that calls f_open directly through FatFS: - BLE File Transfer (supervisor/shared/bluetooth/file_transfer.c): all WRITE/MOVE/MKDIR/DELETE commands fail with STATUS_ERROR_READONLY even when the board has no host on the bus. This is the original #10972 repro on CLUE running from battery. - Web workflow PUT/POST/MOVE/DELETE (supervisor/shared/web_workflow): same path, web-editor #460/#506 surfaces this as a read-only error. - storage.remount(readonly=False): can take the lock but then can't actually write while the lock is held. Each of these already calls filesystem_lock() to claim the blockdev LOCKED flag before writing. USB MSC does NOT go through filesystem_lock; it grabs LOCKED directly via blockdev_lock() inside tud_msc_is_writable_cb. So filesystem_lock() is exactly the right place to grant temporary write permission via IGNORE_WRITE_PROTECTION, mirroring the pattern main.c uses around boot.py. After this change: - filesystem_lock() is the single source of truth for 'I'm the local writer right now'. Holders can f_open(FA_WRITE) and operate normally. - USB MSC continues to be mutually excluded via LOCKED; it never sets IGNORE_WRITE_PROTECTION because it doesn't go through filesystem_lock. - _is_writable_by_python and _is_writable_by_usb are unchanged; the symmetric mutex from #10659 is preserved. - Python direct open(FA_WRITE) without a lock still requires storage.disable_usb_drive() or storage.remount(readonly=False) — same as current behavior. Fixes #10972
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
2 participants
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.
storage.mount(..., readonly=True)#10657.#10648 mistakenly prevented USB writes all the time. Fixing it was more complicated than one might think
self->blockdev.writeblocks[0] = MP_OBJ_NULL;turns off write for everyone, and is not a good way of setting read-only for host but not CircuitPython or vice-versa. So use theblockdevMP_BLOCKDEV_FLAGs exclusively. viafilesystem_is_writable_by_python()andfilesystem_is_writable_by_usb().boot_out.txtnot to be written in most cases, because now the read-write check on the flags is done at a lower level. So add a new flagMP_BLOCKDEV_FLAG_IGNORE_WRITE_PROTECTIONto turn off write protection duringboot.pyexecution. We can't just temporarily toggleMP_BLOCKDEV_FLAG_USB_WRITABLE, becauseboot.pymight do astorage.remount(), which changes that flag, and we can't tell if it was changed inmain.cor in theboot.pyPython code.Tested with all four combinations of {
CIRCUITPY,/sd} x {read-write, readonly} on a Feather RP2040 with an Adalogger Featherwing. Also tested the three drives presented by Fruit Jam in their regular states to check proper read-only/read-write.