For anyone who is interested, I just uploaded a bugfix release to
DOSFS, my free FAT12/16/32 filesystem.
<http://www.zws.com/products/dosfs/>

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.