More on the update.
There is a new version of the FastFileSystem in the update as well. Actually, this is only a very minor update as there was nothing to fix, just a couple of things to improve. So, your data is not in danger.
If the FFS initialized a volume for long file names (DOS/6 or DOS/7), it also wrote administration information for directory caches. This data was actually never used, as the dircache remained disabled, so it did nothing bad. As the data is not needed, the new FFS no longer writes this useless data.
Then, when mounting multiple partitions, the 3.1.4. FFS mounted all partitions in parallel. This might have caused a lot of head movements on mechanical disks, so 3.1.4.1 reverts this to serial mounts.
There is a tiny improvement for users of the omniscsi.device, and probably some other devices in combination of removable media. In case you mounted such devices on a drive with a medium inserted, nothing would happen. The corresponding device does not return a proper result for TD_GETCHANGESTATE, such that the FFS would assume that no medium is inserted. The new FFS performs now a "dummy read" to "wake up" the affected device - this will avoid this problem.
The same issue also existed in CrossDos and the CDFileSystem where it was fixed (or rather, worked around) as well.
The FFS "bitmap" records which blocks of a volume are allocated and which are free. For large volumes, there can be many bitmap blocks, and these are recorded in "bitmap list blocks". Previous versions of FFS wrote the bitmap list blocks and the actual bitmap blocks "interleaved", which makes them slow to read. The new FFS writes them in a contiguous list of blocks. This would allow the FFS in a future release to read them in one single access, improving the startup time. The code for that is not yet there, but there is some preparation for it.
Last but not least, the "disk validator" in the FFS was also improved. The previous version would read blocks in a rather simple-minded fashion: Allocate a block buffer, read the block, validate the block, release the block, then continue. Thus, a lot of rather useless memory allocation operation were performed, one after another - this made disk validation unnecessarily slow. The new FFS will allocate the block first, then use throughout the validation process, and release it when its done.
Oh, and one final change: The FFS creates (since 3.1.4) its own entries in the "FileSystemResource". In order to avoid problems with "HDToolBox" type programs that do not inidicate a proper stack size (due to a mix up of the unit), the FFS now creates the proper "PatchFlags" to indicate a stack size of 2048.
The next (major) release will include just another mechanism for file handlers to indicate their stack size that is a bit more "fool proof" than the current way... Live and learn....