fragmented files

[Gurkengewuerz]

hey @charlesbaynham,

first of all nice work but i would really love to see fragmented files support for a library that is so flexible! to my knowledge it would also be very unique. there is no library that support any storage (eeprom, fram, etc.), has such a small footprint and supports fragmented files.
in my opionion its a good time to give this library a update!

I hope you see it like me.

Best regards from Germany

[charlesbaynham]

Hey @Gurkengewuerz, sorry to have taken more than a year to reply to your comment... And thanks for the suggestion! Fragmented files are something that I would like to support.

In the past I've said that this would require a change to the file headers, but actually it could be done without that. The current headers are like so:

-----------------------
HEADER
	File ID and extension (8+3 bytes)
	Size of file (uint16_t = 2 bytes)
	Pointer to start of next file's header (uint16_t = 2 bytes)
	Flags (uint8_t = 1 bytes. MSB = 1 for deleted file, 0 for valid. Other bits reserved)
-----------------------
FILE CONTENTS
	Binary data with no restrictions (<Size of file> bytes)
-----------------------

I think a sensible extension for fragmented files would be to set the "size of file" field to a value larger than the size of the first block. This would signal to OSFS that it needs to continue searching for more blocks with the same filename, until it has managed to load all "size" bytes from memory.

I'm not currently using microcontrollers much in my professional life, though I might be doing so again soon and so might have a chance to revisit this. Otherwise, I might find some time to have a go at some point.

One problem that might occur is that if the user is constantly rewriting larger and larger files, the memory might become really fragmented which would be wasteful. So maybe fragmented files should be opt-in.