Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.54%. Comparing base (9a37780) to head (dc46cf1).
Report is 3 commits behind head on master.

@@           Coverage Diff           @@
##           master   #17090   +/-   ##
=======================================
  Coverage   98.54%   98.54%           
=======================================
  Files         169      169           
  Lines       21890    21890           
=======================================
  Hits        21572    21572           
  Misses        318      318           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

I've added the TransportError handler back in, and a test script to verify it and everything else.

This looks good now, thank you.

I have some feedback on the test, which is just a suggestion, not necessary to get this merged: it's possible, and simpler in the case at hand, to define an actual filesystem in Python, rather than a block device. And then make that filesystem raise the relevant exception. Eg something like this (untested!):

class FS:
    def setup_error(self, er):
        self._cur_error = er
    def mount(self, readonly, mkfs):
        pass
    def chdir(self, path):
        pass
    def open(self, path, mode):
        raise self._cur_error

fs = FS()
vfs.mount(fs, "/fs")
setup_error = fs.setup_error

It's possible, and simpler in the case at hand, to define an actual filesystem in Python, rather than a block device. And then make that filesystem raise the relevant exception.

Good call on that, that'd definitely make the test shorter and less clumsy -- makes for better documentation of what it's trying to do, even if it's not a technically necessary change.

I'll implement this and retest; also, I should probably test under Windows first too, just to be sure, now that I have an environment for that set up.

I've updated the test with the simplification suggested -- which also let me replace the touch commands with even-more-noopish cat commands.

I've re-tested the full mpremote test suite with a WSL2 Linux mpremote host and RPi Pico2 device; I've confirned that the test cases in f54195c discriminate regressions on all the aforementioned issues in this thread.

Running the test from a Windows 11 mpremote host (using an MSYS2 bash shell) against the same RPi Pico2 device has revealed an interesting deviation:

--- test_errno.sh.exp   2025-04-24 10:02:53.218824300 -0400
+++ test_errno.sh.out   2025-04-24 10:02:57.736379400 -0400
@@ -20,6 +20,6 @@
 mpremote: cat: EPERM.py: Operation not permitted.
 expect error
 -----
-mpremote: cat: EOPNOTSUPP.py: Operation not supported.
+mpremote: cat: EOPNOTSUPP.py: Unknown error.
 expect error
 -----

It seems that os.strerror doesn't include a message for the EOPNOTSUPP errno under Windows (at least, not in Python 3.12.10, the version I tested with).

The fact there's a platform difference in what set of errnos are available leads me to think it might be better to rethink searching the error text for e.g. the symbol name strings EAGAIN and instead parse for the [Errno 11] part of OSError: [Errno 11] EAGAIN:. (And perhaps, extend that to the OSError: (30, '') format micropython falls back to for errnos it doesn't recognise.)

After a couple more hours working through other possible parsing strategies, I'm forced to conclude that trying to parse all the different ways micropython might output an OSError trace would go well outside the scope of this PR.

As proposed, this operates correctly on the subset of errors that the commands it's used for can produce; let's just let that be sufficient, even if it does technically break when you artificially inject more pathological error conditions.

I was looking at test coverage for mpremote ( which is a hassle due to bash, but possible ) and noticed that the test cases do not exercise all errors that could be thrown.

I assume that you now have these covered by the additional test that you added.

mpremote is currently at ~55% test coverage. Ill work on a PR for coverage test and reporting, always nice to push the dial up.

mpremote is currently at ~55% test coverage. Ill work on a PR for coverage test and reporting, always nice to push the dial up.

Sounds good!

As proposed, this operates correctly on the subset of errors that the commands it's used for can produce; let's just let that be sufficient, even if it does technically break when you artificially inject more pathological error conditions.

Yes, good to be pragmatic. Now merged.