Make filesystem writable from CircuitPython when off USB

[tannewt]

Right now we're strict about requiring explicit remount of the filesystem to make it writable. Instead, we can detect when we're mounted by a host and be smarter about who should have write access.

So, if you are off USB you'd be able to read and write the filesystem without any CircuitPython specific code.

If you are off USB and then plug it in:

• If you have a file open for writing, then the filesystem will be read-only to the host.
• If your code isn't running or all open files are read-only then the host will be able to write and CircuitPython won't.

If you are on USB and iterating on code that writes to the filesystem:

• When your code isn't running the computer will be able to mount writable.
• When the drive is mounted and you save it will trigger a reload. If your code tries to open a file for write it will fail as it does now and it will likely stop running (unless you catch the exception).
• When your code isn't running and the computer ejects the drive it will reload your code with the ability for CircuitPython to write to the file system. The host will not see the drive until the user code stops. At that point the drive will mount on the computer as writable again.

Does this make sense?

[dhalbert]

With these rules, it will still be somewhat tricky to debug a data-logging app or similar when USB is connected. You'd still need something in boot.py to enable/disable writing until you got it all debugged.

When your code isn't running and the computer ejects the drive it will reload your code with the ability for CircuitPython to write to the file system. The host will not see the drive until the user code stops. At that point the drive will mount on the computer as writable again.

On Windows, "Eject" does not really mean unmount, it just means "flush"; the drive stays mounted. Not sure how to fully unmount on Windows.

A long time ago I suggested we might provide two visible filesystem partitions: one that is r/w to the host only and one that is r/w to CPy only. I can't find any issue describing this, so maybe I never wrote it up. Its disadvantage is that you have to decide the partition sizes in advance, and that's an issue with smaller SPI flash chips.

[TG-Techie]

could it write to internal flash then move to the spiflash when next unmounted or reset?

[ladyada]

TG, my use case is with needing to 'cache' online data and displaying it within the same runtime so moving files on reset wouldnt be able to use that technique

[tannewt]

@dhalbert Ah windows throws my ideas out the window. Will keep brainstorming but close this.