Discussion
Once an SD card is "partitioned" into multiple files, SdFat needs logic for reading these files & directories. So how does this work?
There's method wrapping the volume's allocator in one of 2 ways per compiletime macros & a wrapper which increments a read pointer, validates its args, & reads in the allocated page for the sake of directories. There's several methods exposing tweaked variants of the data from the file's entry in its directory.
1/?
There's a method for reading in the page in which that file-metadata is stored. And there's a deinitializer which also flushes (via another method) data to the SD card.
There's a method which traverses the linkedlist of pages (as the Volume tracks within its File Allocation Table) to see if its contiguous or calculate the directory's size, and a few methods to preallocate contiguous runs.
There's methods to read/cache the directories entry's with or without flushing said cache.
2/?
There's a wrapper around a read() method for stopping after a newline, stripping any returns. With the underlying method traversing the linkedlist to read from the appropriate page(s).
There's wrappers around open() to create a folder with or without any of its absent parents, with the underlying open() methods reading the relevant directories to find where to read/write the file. And there's variants upon this.
There's accessors for the seek & start positions, or the volume's busy flag.
3/?
The directory-read methods is a wrapper around that read method with additional checks.
There's methods for overwriting a file's metadata (possibly flagging it as deleted), with wrappers to dereference the file to modify. And a wrapper to delete all descendents of a directory.
There's a method to free all pages past a certain file-offset. And a variant of the read method which memcpy()s data into the relevant page(s), with optimizations for contiguous pages.
4/5?
There's several more wrappers & accessors, some of which are inlined.
Other wrappers are split off into separate implementation files including ones which understand ASCII, or reformats directory listings into human-legible text.
Also the logic to carefully locate a named file within a folder is implemented in its own file, handling longer filenames & tombstones specially. And there's a few variants of this, helper to resolve relative paths, & a helper to set those tombstone flags.
5/5 Fin!
Install bonfire.cafe
Get the full app experience
