OSError 28 with basic file write on version 2 microbit

[rhubarbdog]

text ="hello phil\n"
    with open("test.txt", 'w') as f:
    f.write(text)

crashes with OSError 28

[microbit-carlos]

Hi @rhubarbdog,

For issues that V2 specific they should be opened in https://github.com/microbit-foundation/micropython-microbit-v2/issues

However, I've tried this script in both V1 and V2 and works fine:

# Imports go at the top
from microbit import *

text ="hello phil\n"
with open("test.txt", 'w') as f:
    f.write(text)
display.scroll("done")

Would you be able to provide an example that fails? Ideally in a new issue in https://github.com/microbit-foundation/micropython-microbit-v2/issues ?

Thanks!

[rhubarbdog]

it may be that i have a couple of huge bytearray's allocated. i'll try on a clean microbit

[rhubarbdog]

yes it may be lack of file space my program is 20145 bytes. Here's a copy it (tries to) run for 5 hours random sampling the circle radius 1 inscribed in a square to calculate pi. after about 2 or 3 hours micro python just freezes. the animation on the screen stops which changes every 10 loops, in a REPL session there is no exception error and you cant ctrl-c to stop micro python

microbit.py.txt

[microbit-carlos]

Thanks for the additional info @rhubarbdog! Are you using the latest MicroPython releases? I haven't looked at the details yet, but could be related to https://github.com/microbit-foundation/micropython-microbit-v2/issues/105 ? which should be fixed in the 2.1.0 and 1.1.0 releases.

[rhubarbdog]

There may be an issue with replacing a file with the same name

[microbit-carlos]

At least from https://github.com/microbit-foundation/micropython-microbit-v2/issues/105, the issue in that case explicitly about using the same filename, but the filesystem not sweeping and freeing any erased filesystem blocks, to be able to have enough free space to write a new file. So if a programme was constantly writing a file, deleting it, writing to a different file name, deleting it, and repeat, then it would end up with the same problem.

However, this issue was fixed in MicroPython for micro:bit v1.1.0 and v2.1.0. Which version are you using?

[rhubarbdog]

i'm using version v2.0.0-beta.5 as shipped with uflash, should it be fixed?

[microbit-carlos]

That's a very old version, I'd recommend downloading the hex from: https://github.com/microbit-foundation/micropython-microbit-v2/releases/tag/v2.1.0

And then transferring your main.py file with microFS: https://github.com/ntoll/microfs

Or the online micro:bit Python Editor, which is quite nice too, specially if using Chrome with WebUSB: http://python.microbit.org

[rhubarbdog]

now using version 2.1.0 beta of microbit.hex and the initial issue of

f =open("text.txt", "w")
f.write("message")

no longer causes OSError28 and my program to find pi completed a 4 hour run last night and has now been going for 12 hours so micropython freezing may not be an issue any more. how ever now that i have to use microFS to to copy my program and class definition i am experiencing a lot of failures with the error message Expecting 2 values to unpack, only found 1 i don't believe this to be a microFS problem and there are still issues on a file system with a 17kb class definition of decimal numbers when replacing file names or finding free blocks. https://github.com/ntoll/microfs/issues/38

[microbit-carlos]

Yes, that is an issue in microFS, also captured in:

• https://github.com/ntoll/microfs/issues/34

I had an unfinished PR (from my personal account, this one is a work which I keep separated). I've push it as a draft PR in case you'd like to use that version in the meantime:

• https://github.com/ntoll/microfs/pull/39

And I'll close this as resolved in the current release, thanks @rhubarbdog!