Somebody wrote (sorry--I lost the original digest:)
Many will disagree with me, but I feel that a floppy
based OS that can't
handle non-contiguous files is the worst product ever marked as being an
OS.
They're more common than you'd think, particularly in OS for
industrial machinery, such as CAD equipment and embroidery machines.
Typically, the diskette is written only once for a particular job
(usually as a paper tape substitute) and read over and over again. In
those cases, it makes perfect sense.
Non-contiguous floppy files can be a real drag on the older floppy-
based systems that used drives with very slow positioners (now, why
does "Micropolis" immediately come to mind?). A scheme that involves
contiguous allocation with a fixed number of shots at extending (in
case you mis-estimated the size) works well on slow floppy systems.
For many single-user applications, it's possible to employ an
"allocate the remainder of the disk and truncate on close" scheme.
It's also a piece of soup/duck cake to recover files from a floppy
using contiguous allocation where the directory and allocation
information has been destroyed. (Even better to incorporate recovery
information throughout the diskette instead of one track that gets
hit over and over again, but that's another story). (Have you ever
had to recover a "work" floppy full of Lotus 1-2-3 spreadsheet data
without a directory or FAT?)
More related to the topic is that DEC VMS FILES11 had an incredibly
complicated floppy file system. Maybe BTOS was worse...
Cheers,
Chuck