kevinjwalters
commented
5 years ago Note: 128 entries in total coming back from os.listdir().
Closed kevinjwalters closed 5 years ago
kevinjwalters
commented
5 years ago Note: 128 entries in total coming back from os.listdir().
dhalbert
commented
5 years ago It certainly looks like the filesystem is corrupted. I'm not sure it has to do with your marker files, except that perhaps the file metadata was not written completely before the board was reset. If you could copy everything back and reformat the filesystem, that would probably help.
>>> import storage
>>> storage.erase_filesystem()That was my first thought but I then wondered if this could be an obscure listdir bug? This probably gets limited used, I've only used it a hand full of times.
Is there an fsck equivalent library call to independently check the health of the file system? Actually
there's the crappy old DOS remant, chkdsk and that does show problems:
C:\Users>chkdsk e:
The type of the file system is FAT.
Volume Serial Number is xxxx-xxxx
Windows is verifying files and folders...
Windows found errors on the disk, but will not fix them
because disk checking was run without the /F (fix) parameter.
Removing nonvalid long folder entry from \...
File and folder verification is complete.
Windows has checked the file system and found problems.
Run CHKDSK with the /F (fix) option to correct these.
2,072,576 bytes total disk space.
1,024 bytes in 1 hidden files.
47,104 bytes in 33 folders.
871,424 bytes in 262 files.
1,153,024 bytes available on disk.
1,024 bytes in each allocation unit.
2,024 total allocation units on disk.
1,126 allocation units available on disk.This was still usable so I would not have noticed this problem had it not been for listdir(). I'm just cleaning it up now as I'm trying out 4.0.0 rc1 and don't everything pristine.
dhalbert
commented
5 years ago Are you still seeing this after reformatting the filesystem?
There is no health check built in, but the typical fsck or chkdsk could probably work. The first block of the filesystem is actually simulated because it contains unchanging info.
kevinjwalters
commented
5 years ago No, I'd left it in its slightly broken state because I was interested in when/how the problem would manifest itself in ways a typical user would see. The corruption must have been minor and not had much impact.
I've run storage_erase() now and copied over new lib directory. chkdsk runs clean on both of my CPXs.
I've been using multiple boards recently plugged into the same host and I've left an empty file on each to mark them so I can ensure from REPL I'm using the correct board when it's important. I noticed on this particular CPX (running 4.0.0 beta 7) that there are loads of bogus 8.3 filenames composed purely of NUL characters. Is this minor file system corruption or a
os.listdirbug? Windows file explorer and old skool DOS emulated dir show everything normal.I then started experimenting. After the first misbehaviour of
listdir()seems less predictable and will sometimes throwMemoryError:For comparison,
diroutput:I did a Control-D reset from REPL and they persist.