Interesting. The header size seems big for low-resources embedded systems (e.g. with only 256 bytes of EEPROM). I'd rather use a file identifier (e.g. a 8-bit number) to identify what a file is doing instead of arbitrary names.
One of my pet peeves is people using the letter "u" to mean micro. Its a greek letter mu, "μ", and seeing as the entire thing is capitalised here, it could also be "Μ" (uppercase greek mu, not uppercase latin M)
The problem is that µ is usually hard to type (unless you have a Greek keyboard or a custom keyboard mapping). This said, although I tolerate stuff like "47 uF" in electronic schematics (also because legacy software didn't even allow the µ symbol), I definitely find horrible to see stuff like "us" instead of "µs" in an article.
It's one of those things that every embedded dev kind of cobbles together on their own as they discover the limit of struct arrays stored in EEPROM.
Except this one actually seems worse in some ways, because to find a file you have to keep following what is effectively a single linked list of file headers until you find the file you need.
The authors even acknowledge this is just a copy of tar's approach, and even acknowledge that that was in turn done this way due to a lack of random seeking on tape systems at the time. But a microcontroller's EEPROM/SPI/... data is nothing like this? You can just do arbitrary seeks. So I'm not sure what they were going for here.
Interesting. The header size seems big for low-resources embedded systems (e.g. with only 256 bytes of EEPROM). I'd rather use a file identifier (e.g. a 8-bit number) to identify what a file is doing instead of arbitrary names.
One of my pet peeves is people using the letter "u" to mean micro. Its a greek letter mu, "μ", and seeing as the entire thing is capitalised here, it could also be "Μ" (uppercase greek mu, not uppercase latin M)
The problem is that µ is usually hard to type (unless you have a Greek keyboard or a custom keyboard mapping). This said, although I tolerate stuff like "47 uF" in electronic schematics (also because legacy software didn't even allow the µ symbol), I definitely find horrible to see stuff like "us" instead of "µs" in an article.
I just googled it to type my comment. And if you're using it enough to need quick access, you can do alt + 0181 on your numpad on a windows system
And it's option-m on a Mac.
I don't think there's anything novel here?
It's one of those things that every embedded dev kind of cobbles together on their own as they discover the limit of struct arrays stored in EEPROM.
Except this one actually seems worse in some ways, because to find a file you have to keep following what is effectively a single linked list of file headers until you find the file you need.
The authors even acknowledge this is just a copy of tar's approach, and even acknowledge that that was in turn done this way due to a lack of random seeking on tape systems at the time. But a microcontroller's EEPROM/SPI/... data is nothing like this? You can just do arbitrary seeks. So I'm not sure what they were going for here.
The implementation is also full of obvious bugs that will cause crashes or hangs or worse when operating on an untrusted or simply just corrupted filesystem: https://github.com/clisystems/utfs/blob/5f1a6f049a0ca5435afb...