simple-fatfs

A simple-to-use filesystem driver for the File Allocation Table (FAT)

Motive

Apart from rafalh's rust-fatfs library, there aren't actually any other FAT filesystem drivers in crates.io. All the other libraries either support only FAT16/32, aren't being actively developed or are just bindings to some C library.

Another thing I found somewhat frustrating about rafalh's rust-fatfs (which ultimately led to my decision of creating this project) is the fact that his library isn't suitable for embedded Rust, since it requires implementing some weird kind of buffered Read/Write, while it is also worth mentioning that the crates.io version of his library is somewhat outdated (there have been 144 additional commits as of the time I'm writing this).

Intent

A fully-working FAT driver that covers the following criteria:

• An easy-to-use public API for developers
• Avoids unnecessary/overbloated dependencies (I am talking about leftpad-like dependencies)
• #[no_std] support
• Uses embedded-io for IO operations, making it suitable for embedded devices
• FAT12/16/32/ExFAT support
• VFAT/LFN (long filename) support

It also aims to be able to do the following in the future:

• Allow low-level manipulation of a FAT filesystem (e.g. for checking if a file is continuous)
• Features enabling/disabling perhaps unnecessary features for certain use cases, allowing for usage in devices with limited flash memory / RAM

TODO

• FAT12 support (just handle entries between 2 sectors)
• Distinguish between directories and files in paths (this must also be verified by the filesystem, just like in the std)
• Check whether system endianness matters (FAT is little-endian) PS: it does in fact matter. bincode, which we use for (de)serialization allows us to configure the default endianess
• Handle non-printable characters in names of files and directories
• ExFAT support
• replace custom io implementation with the embedded-io crate
• use from_utf16be for decoding LFNs (str_from_utf16_endian #116258)
• handle duplicate file open, either by blocking or more preferably, by not allowing such behavior.
• the majority of codepages will end up being dead code for most users, use features for enabling/disabling them.

Known issues

• While the library can support both little and big-endian systems, due to the str_from_utf16_endian feature being unstable, long filenames won't be properly decoded.

• Duplicate file opens or in general any write operation involving a file that is open either as R/W or RO could cause data corruption (see #14)

• Multi-byte codepages, such as the Japanese one (932) are currently unsupported.

Acknowledgments

I'd like to thank @alexkazik for his contributions, most importantly his short filename generation algorithm and his Block-based device traits.

This project adheres to Keep a Changelog and Conventional Commits (since commit 21c7d6b, that is excluding the first two commits which don't actually contain any code). It also uses git-cliff to parse commit messages into a CHANGELOG

License

MIT