The fall of CP/M?

On 26 Aug 2012 at 10:47, Fred Cisin wrote: I took it as a strong nudge by the Boys in Redmond that one shouldn't store much in the root directory of any device. On the other hand, you can pollute subdirectories all you want--just look at the typical WINDOWS\SYSTEM32 directory content (on 32-bit versions of WIndows). Kildall doubtless designed CP/M for floppy-only systems. At the time, the price of a hard disk was likely to exceed the cost of the floppy system itself, though ISIS uses a linked-list-type of file allocation. Linked-list file allocation has been around almost as long as disk drives. However, as files fragment, it gets slower and slower, particularly on drives where seeking is slow and rotational latency is long, such as floppy drives. If the list of links is lost, recovery of files can be a nightmare if the files have been written and extended frequently (A prime example are some word processing packages that update the file being edited in place. I've had to recover these by manually examining each cluster and connecting them up when the text made sense.) On STAR-OS, I was surprised to see that linked-list allocation wasn't used, but contiguous (estimate your file size on creation) with up to 4 extensions. After that, you need to consolidate your file by copying it to another or using a special utility. Given that (a) all applications tended to be big number-crunchers and (b) almost all application file I/O was done by mapping a file into memory space, using the pager to do the I/O, it made some sense. RT-11 also makes use of contiguous allocation and RSX has the option for some files. There are other OS that place forward- and backward- links in the file data itself. Losing a single data block isn't a huge catastrophe--you simply find the blocks that point to it and fill in the gap. But random access is a pain. --Chuck