Port, board and/or hardware

ESP32-S3

MicroPython version

MicroPython v1.26.0-preview.226.g5676b45cb.dirty on 2025-06-17; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3

Reproduction

This is a build with ROMFS enabled setting MICROPY_VFS_ROM and with partitions-8MiB-romfs.csv. After generating and flashing the image, mpremote returns this:

mpremote romfs query
ROMFS0 partition has size 131072 bytes (32 blocks of 4096 bytes each)
  Raw contents: d2:cd:31:87:c8:58:05:9b:18:0b:62:61 ...
  ROMFS image size: 123992

Commands in REPL to return ilistdir():

>>> import os
>>> [x for x in os.ilistdir("/")]
[('rom', 16384, 0), ('data', 16384, 0, 0), ('lib', 16384, 0, 0), ('main_backup.py', 32768, 0, 2210), ('signals', 16384, 0, 0), ('software', 16384, 0, 0), ('tunelib', 16384, 0, 0)]
>>>

The entry for 'rom' (ROMFS) is 3 elements long, the other entries have 4 elements.

Expected behaviour

The expected behavior is that all entries of ilistdir should have the same length for a given port. I understand that in another port, all entries might have a different length.

Thus is the entry for 'rom' should be:

('rom', 16384, 0, 0)

instead of

('rom', 16384, 0)

The existing behaviour breaks code that relies on 4 elements of ilistdir output.

Observed behaviour

>>> [x for x in os.ilistdir("/")]
[('rom', 16384, 0),  
.... etc

Additional Information

The problem seems to be in ```vfs.c`` line 420:

            mp_obj_tuple_t *t = MP_OBJ_TO_PTR(mp_obj_new_tuple(3, NULL));

If I set this tuple to length 4 and add this after line 425:

  t->items[3] = MP_OBJ_NEW_SMALL_INT(0); // size 0

then the behavior is as expected. However, since I don't know which ports use different tuple length, I can't write a PR.

Although I only have reproduced this on a ESP32-S3, most probably this can be reproduced on other ports too.

Replaces #17484

Code of Conduct

Yes, I agree