10 ms·
The structure of the special type of DOS files called directories (1998)
- stevecat 8y agoI did not expect tripod.com to still exist.
- blondin 8y agoi wanted to comment on that lol
- marsrover 8y agoSeeing a post hosted on tripod.com brings back so many memories. It's my favorite thing about this submission.
- foobarian 8y agoMakes me remember creating files by hand using Norton Utilities' diskedit directly on the raw bytes. Those were the days :)
- dana321 8y ago"Welcome to hell." All i needed to read :)
- dana321 8y agoWell 3 people dislike this i find that funny
- code_duck 8y ago“Note that filename cannot consist solely of spaces, but extension can.” This is the sort of thing hat makes me wonder what on earth went wrong or even could have been right about Microsoft. Why would spaces be permittable in a file extension at all, ever?
- nradov 8y agoI don't know about that specific issue, but some of the weirdness in MS-DOS is based on precedents set by CP/M. It's not really compatible but recycled many of the same concepts.
- jandrese 8y agoCan't blame the horrible way they implemented long filename support on CP/M. I was mildly impressed at how they packed the datefield into a 16 bit value, losing only odd numbered seconds in the process.
- anyfoo 8y agoIt’s horrible, but compatibility often leads to horrible things. Remember that they wanted disks with long file names to work on old systems, and have them be able to manipulate files with long file names as usual (through their short names), in all kinds of manners. I’m not saying it’s good, but MS at the time had compatibility as one of their highest priority, so that’s what they were going for. (But the parent’s comment is about the initial implementation, not long file names.)
- jandrese 8y agoI'm saying that even taking reverse compatibility into mind (which they didn't even have, FAT32 couldn't be read by a FAT16 driver) the way the filenames are encoded is a mess with the name being split up by attribute and checksum bytes. One has the impression that it looks like it does because they didn't want to touch most of the FAT16 driver code and instead tried to make touchups around the edges.
- anyfoo 8y agoNot sure what you mean. They did it precisely for compatibility. It worked for FAT16 (and probably FAT12, for that matter) as well, and in fact long file names came before FAT32. Anything that would trip up older DOS versions or any other FAT consumers was a no-go.
- dmitrybrant 8y agoFor all the quirks and facepalms to be found in the FAT logic, I have to give credit to the staying power of FAT, and its universal compatibility. Its relative simplicity makes it perfectly adequate as the default filesystem for short-term storage (e.g. USB flash drives) where things like resilience and journaling are not an absolute necessity.
- aboutruby 8y agoIts 4GB max file size was a pretty big problem near its end of life.
- kikoreis 8y agoApart from media files, where does that limit really hurt?
- devnonymous 8y agoBackups ..or generically tarballs/zips/..etc. There have been way too many times I've had to split zips/tarballs etc just to copy over stuff over a fat formatted usb disk. Of course I no longer do that but there was a brief period when this was a problem.
- reaperducer 8y agoI remember back in Commodore days, ARC or LHARC, or one of the archiving programs had the ability to span 1541 disks. But I can't remember why that was necessary. Under what circumstances was I moving files around that were 3x the size of the computer's memory?
- anyfoo 8y agoGood question. Even for programs and games that spanned multiple disk, you’d explicitly arrange the data so that it makes sense (sometimes even duplicating some of it), and not just uniformly spread it across all the disks. I can’t remember a single instance where there was the concept of a file that spanned multiple disks on the C64. In theory, the hard drive add ons might have lead to the use of such files (they don’t have to fit into memory at once, you can just seek within the file), but given their relatively low popularity, that was probably very rare, if there was any support for such files in software at all...
- magnat 8y ago> The entry with the name consisting of exactly one dot is the pointer to the root directory Is it? Wasn't single-dot entry pointer to current directory since DOS 1.40?
- ben509 8y agoThe most complex operation due to some klugey MS stuff is 7 pseudocode steps... if that's hellish, then engineering is not a good career choice. "What can go wrong with long filenames? Give some space to your imagination..." They can get out of sync, and then they're going to float around until a long-filename aware system clears them out. Shockingly, systems that aren't aware of a new standard aren't aware of the new standard. ¯\_(ツ)_/¯ I've been working on a language for handling data structures much like this, and have some preliminary notes on a strategy for handling this scenario: https://tenet-lang.org/versioning.html https://tenet-lang.org/versioning.html
- anyfoo 8y agoYeah. You can give Microsoft a lot of crap, but what never ceases to amaze me is how inventive they were in keeping everything as compatible as possible, which they usually (successfully, mostly) pursued at all cost. Of course, that came with a high price, in terms of complexity and kludginess.
- ben509 8y agoIt's pretty interesting because in many cases the software evolved faster than anyone could keep up with, and there are large portions of backwards compatibility that I suspect were mostly accomplished through trial and error, especially when it comes to their layout algorithms. When they opened up the Office file formats, they wrote an XML spec that corresponds to the fields in the various binary formats. And there are sections of it where the specification is simply, "this should be formatted the way MS Word 5.1 does it."
- plussed_reader 8y agoAnd then they released WindowsME, with broken memory management.
- geophile 8y agoThis is not hell. I have had mercifully little exposure to this world, but I once had to implement ACLs for a storage system my company bult. We stored ACLs, and needed to make them available through Linux and Windows interfaces. Linux was easy. Windows (ca. 2006) was a fucking nightmare that puts this document to shame. From what I could tell, there was no concept of an API. There were data structures, and the interpretation of them depended on many things, including minor OS version.
- amaccuish 8y agoIf only exfat wasn't patent-encumbered :( extfat-fuse works ok, but I'd love there to be a universal filesystem for external devices.
- benj111 8y ago"If the first character has the code 05, then actually the first character has the code E5 and it is not a special character. If the first character has the code E5, then the file was deleted" I'm struggling to interpret this, why would the code be changed to E5? I assume a file starting with 05 isn't deleted.
- spelunker 8y agoE5 is an extended ascii code, so I think 05 is acting as an escape character so that the filename won't be interpreted as deleted in the case the filename actually starts with å.
- ratboy666 8y agoChoice of E5 for a deleted entry: #1 E5 is a "sync byte" it cannot be rotated and mis-interpreted: E5 E5 E5 ... can be used to synchronize a bitstream. Note that floppy discs are read bit-wise. #2 Empty 8" floppy discs came pre-formatted with E5 written everywhere. #3 05 is a "control-e" in "extended 8 bit ASCII (IBM encoding)". E5 was a usable character. With CP/M, the disc bitmap was produced when the disc was "loaded". All directory entries were scanned, and the allocation bitmap was produced. A freshly formatted disc would have E5 fill, and thus would have no files. MS-DOS had a separate allocation table, which was also the file linkage table. So, the strategy of a fresh E5 filled disc being taken as empty no longer works. But, the key of a deleted entry having E5 as the initial character was still used. Hope this helps.
- benj111 8y agoThanks for that. I hadn't come across the idea of a sync byte. For anyone else, the binary representation of E5 is 11100101. No matter where you start reading you're always going to know whether you are reading from the start of the byte or not. Contrast with null (00000000) its impossible to know where you've started from. This has a bit of info ftp://ftp.apple.asimov.net/pub/apple_II/documentation/misc/disk_encoding.doc.txt
- tambourine_man 8y agoI’ve heard once that the design of FAT was so straightforward that one would be hard pressed to enforce any patents on it. And that Gates designed it on an airplane trip. Does anyone know if any of this is true?
- 13of40 8y agoDon't forget that DOS 1.0 didn't have subdirectories or long file names, so most of the complexity in the article comes from years of shoehorning new functionality into it.
- Someone 8y agoWrote, not designed (https://blogs.msdn.microsoft.com/oldnewthing/20131008-00/?p=3003 https://blogs.msdn.microsoft.com/oldnewthing/20131008-00/?p=...) (But it isn’t true. https://en.wikipedia.org/wiki/File_Allocation_Table#Original_8-bit_FAT https://en.wikipedia.org/wiki/File_Allocation_Table#Original...)
- red_admiral 8y ago> Archive bit is somewhat symbolic. It should be set if the file was not archived by the backup utility. Never in my life I have seen the use of this bit. I have - back in the days of DOS' BACKUP.COM and RESTORE.COM utilities. I believe the way it worked was that when you created or edited a file, DOS set this bit, and when BACKUP.COM archived it, that cleared the bit again (or was it the other way round?) That allowed you to do a very early form of incremental/differential backup, and had a whole section explaining it in the DOS 3.somethingorother manual I first learnt very basic system administration from. Back in those days our school PC came like many others with two floppy drives called A: and B: - which is why hard disk names traditionally start at C: - and you backed stuff up with a complicated schedule of put system disk in A:, boot, put data disk in B:, load program then it tells you to swap disks so you take out the system disk and put the backup disk in A: and when you're done you put the system disk back in again. You could set and clear the archive bit manually with ATTRIB +/-A FILENAME.
- jmalicki 8y agoLinux/UNIX has this too, through mtime (a time not a bit)! Plus it's idempotent, unlike the archive bit! (e.g. if you lost your last backup, you have a time, not a cleared bit, so you can redo it)