For anyone who is interested, I just uploaded a bugfix release to DOSFS, my free FAT12/16/32 filesystem.
These fixes address bugs reported by various users. It has only taken about seven months for me to update the readme.txt and strip the proprietary information out of the fixed sourcefiles, which isn't too bad for me :)
- DFS_Seek would not correctly rewind to start of file
- DFS_Seek would not correctly seek to a position not on a cluster boundary
- DFS_OpenFile fencepost error caused memory access at [start of string-1] with a local variable
- DFS_OpenFile could not open a file in the root directory*
(*) - While retesting this, I discovered that the applet I wrote for regression testing was itself buggy - that's how this one snuck into the 1.0 release in the first place :)
The next feature that will be added to the public version is "fast file" mode.
If you specify the FAST flag when opening a file for writing, the following happens:
- The file is created or truncated.
- All available contiguous space on the target media STARTING AT THE FIRST AVAILABLE CLUSTER is allocated to the file, in a single chain (This will not span fragmented areas).
- Writes to the file will NOT touch the FAT or directory entry; the file is assumed contiguous. Write performance can approach the theoretical sector- or block-write time of your media.
If you specify the FAST flag when opening a file for reading, the file operates normally EXCEPT that dosfs assumes that the file is contiguous on-disk starting at the first cluster, as pointed to in the containing directory; it does not check the allocation chain.
FAST write mode is intended for logging applications where latency is important. It is intended that you will use this on a freshly formatted medium. FAST read mode is intended for multimedia playback from an unfragmented medium.
I anticipate releasing this in October sometime. At the same time I will release the SD/MMC layer I'm using.