Assumptions on (fs::File).fullName() not being full

[tobozo]

hi,

thanks for maintaining this 👍

A library project I'm working on uses Arduino's fs::FS and fs::File as common grounds for RP2040, ESP32 and ESP8266, it implements a recursive directory parser to build a list of files and folders under a given path. That parser uses openNextFile() in a loop, and goes recursive when the returned item is a folder.

Cross device portability is done with a couple of C macros that will use either fs::File::path() (ESP32) or fs::File::fullName() (RP2040/ESP8266).

Assumptions (mostly based on experiences with esp32):

When rootdir = fs.open("/"), any fs::File returned by rootdir.openNextFile() should have its ::fullName() prefixed by /.
e.g. if fs::File blah exist and is in the root folder, then blah.fullName() should be /blah.txt, not blah.txt.

I can't store filename = file.fullName() and use it later with fs.open(filename) as it will produce a file not found error.

So I'm wondering if this is some legacy behaviour I should address by prefixing the / myself, or if this is a bug in LittleFS where / should be prefixed to ::fullName() when the directory is /.

[earlephilhower]

LittleFS should not care if you try and LittleFS.open("/path/to/file.txt", "r"); or LittleFS.open("path/to/file.txt", "r");. The initial / should always be implied with file names since there's not really any chdir in Arduino-land (nor does LittleFS even have a lfs_chdir that I can find).

I wouldn't mind a PR that prefixes a / in the fullName if it's not present, but I'm not seeing where it would make any difference. The fullname should be valid either way...

Could you give a small MCVE that shows the problem? That would help me track down what you're seeing and why...

[tobozo]

Thanks for your reply 👍

The context of my project is to compress LittleFS contents to a .tar.gz archive. That archive can eventually be decompressed on a chdir capable system, where the difference between relative and absolute paths may matter.

It tried to prefix the / at runtime to every collected path, but still got the errors.

I figured the file not found error I was getting was caused by a lock in LittleFS e.g. when opening a file from core0 while another file was waiting to be closed on core1.

So I was just misled by my habits with esp32 core. I thought the error was caused by the lack of leading slash, but it's not.

It's still a good reminder to not expect perfect consistency across arduino cores :)

Should I close this now that my assumptions are fixed?

[earlephilhower]

Thanks for the update. I'll close this one then.

FWIW, accessing the filesystem in parallel from both cores is not going to work very well without much care.

Like most libraries, the LittleFS lib doesn't explicitly support multicore parallel access. For example, one core could update the filesystem structures at the same time another is updating them, leading to corruption. If you protect all calls yourself (with a separate mutex so that only 1 core at a time calls anything which could update state), then it should work. But if you miss a mutex around a call it could cause corruption to the filesystem and a crash or data loss at some point later on.