Littlefs: Using None ASCII values for file name could it work?

[umanayana]

Questions
Can I saves files which uses values that are not part of the printable ASCII table? For example consider a 3 byte array foo[0] = 0x01, foo[1] = 0x01, foo[2] = 0x00. Thus this is a null terminated array that fits "String" standard since you can use strlen() on it just fine due to the last byte being 0x00.
So can I use this name for a file? Or does little FS depend on printable ASCII characters?

Background
I am in the process of evaluating LittleFS in comparison to a proprietary file system I built a while.

The file system I used would identify 65536 different files with 2 bytes. Each file is enumerated, thus saving space in both on PFLASH and DFLASH.

Thus I would like to keep this logic for portability reason and to reduce code size wherever I can.

[lsilvaalmeida]

I'm not sure, but I think that you can have some problem with "special characters" since littlefs parse the file's path. I mean, if you have bytes like 0x2E ('.') or 0x2F ('/') in the file name, the FS can see this as a directory separator and shows an expected behavior.

[geky]

Yeah, '.' and '/' have special meaning and could cause problems.

I've previously used a quick base64ish encoding for this:

// quick conversion from nibbles -> "printable" characters:
// 0x00: 0123456789:;<=>?
// 0x10: @ABCDEFGHIJKLMNO
// 0x20: PQRSTUVWXYZ[\]^_
// 0x30: `abcdefghijklmno
void idtopath(char path[4], uint16_t id) {
    path[0] = ((id >>  0) & 0x3f) + '0';
    path[1] = ((id >>  6) & 0x3f) + '0';
    path[2] = ((id >> 12) & 0x3f) + '0';
    path[3] = '\0';
}

It has more overhead than storing integer ids, but in the grand scheme of things this overhead is very small.

Integers are just tiny fixed sized strings anyways.

[geky]

I should have clarified in the grand scheme of _storage_, this overhead is very small. Device side RAM is at a different scale.

[umanayana]

Thanks for the help.

[geky]

Also another correction, I used the wrong bitmasks. I edited the above and it should be correct now. Just in case you were using it.