OSNews

Funny about the mention of the 65535 file limit on the Mac filesystem of the time: it was actually slightly less than that, of course, due to some overhead, but there were no (to my awareness, at least for machines with an OS sold in the US that weren't Unix mutations) consumer-level machines that had anything better than that limit, though perhaps at some point, OS/2 did, but OS/2 never caught on. Consider: until NTFS, Microsoft (other than perhaps their Xenix platform) with FAT, never had anything better than that same limit, but with more of a limitation than the Mac filesystem (still just HFS at the time) had: every time you wanted to use a larger hard drive that couldn't be mapped to < 65536 powers of 2 bytes allocation unit, you had to double the allocation unit to the next integral power of 2, providing for huge amounts of waste, as well as some number of files limitation that often more closely approached 32768 if a drive just barely went over that nice easy boundary. Mac HFS, by comparison, allowed you to divide into the maximum 65536 allocation units that were multiples of 512 byte sectors, which made things perhaps a little odd in some respects, but allowed more files on average than FAT16 did.

FAT32, of course, does away with that 65536-overhead number of files, but it also doesn't use extents (HFS does) and as such, has a horrible amount of overhead required to handle the number of files in the housekeeping department, because like FAT16 and FAT12, the File Allocation Table is a series of intersnarled singly-linked lists that snake through (possibly) the entire FAT. Oh, yes: HFS also supported long file names far before FAT ever did