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.
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)
"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
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."
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.
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...
Afaik all operating systems read and write UDF formatted sticks and UDF is quite simple as well, and has none of the limitations FAT has. Also no patents.
Frustratingly, neither Windows nor Mac exposes the options to format a disk in this way in their GUIs, but it can be done via the CLI in both cases!
Is it? Wasn't single-dot entry pointer to current directory since DOS 1.40?
I'm struggling to interpret this, why would the code be changed to E5?
I assume a file starting with 05 isn't deleted.
#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.
This has a bit of info ftp://ftp.apple.asimov.net/pub/apple_II/documentation/misc/disk_encoding.doc.txt
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?
So it’s really just an internal representation detail. You might argue that padding with 0 would be better (if you go for fixed size at all), and nowadays that’s what you’d probably use, but it’s kind of arbitrary anyway, and since spaces were illegal in file names, they just used that. Today, 0 has the useful property of also acting as the terminator for zero terminated strings, which became popular through C. Back then, that mattered less.
Contrast this with modern file systems, where spaces in extensions are allowed (just like anywhere else in the file name, as the distinction usually does not exist on the fs level anymore).
I was mildly impressed at how they packed the datefield into a 16 bit value, losing only odd numbered seconds in the process.
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.)
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.
In theory FAT32 could have introduced a new on-disk data structure but I guess they wanted the minimum required changes to support larger disks.
As the names are fixed to 8.3 there is no such thing as length detection/indication for the string.
DOS couldn't have copied what lots of SQL databases did, since DOS was being written around the same time as the first SQL databases.
My guess would be that, like the three character extension itself, this came from CP/M, not SQL.
Even if it has to be 3 characters, shouldn't they at least be \0?
extension COM: just load the file into memory and start executing from the very beginning (I think the max size of these might have been 64KB or something).
extension EXE: this is a "full" executable with different segments - load it properly
extension BAT: this is a "shell" script, run it with the interpreter
The advantages of COM over EXE were slightly smaller file size on disk and slightly faster startup as you didn't have to set up segments and stuff first. Some versions of DOS even had a program called EXE2BIN that converted an EXE file into a COM file, if this was possible. The joys of the 16-bit "tiny" memory model ...
If you want to support <8-char names, <3-char extensions, or no extension at all, you need to decide on values that indicate this, because those bytes will still need filling with something.
(On 6502-based systems, 0 would be a reasonable choice for a padding value, because you get a free zero check every time you read a byte. The 8086 doesn't work like this... I don't think any particular value suggests itself. Perhaps they thought picking a printable character would be useful.)
EDIT: see https://en.wikipedia.org/wiki/Dir_(command)#/media/File:Spar... for an example.
Read a chunk of directory entries into a buffer.
Set ptr to start of the buffer.
Check the extension at ptr.
If extension matches, do a thing.
Set ptr to ptr + 32 and loop.
Note that this is for MS-DOS 2.0 which didn't handle "*.FOO" searches on the kernel side (the star expansion was done on the COMMAND.COM side via the MakeFcb  procedure). MS-DOS 3.0 introduced the star wildcard on the kernel side, so it might have taken advantage of that... but there isn't source code for MS-DOS 3.0.
Also note that DOS 2.0 incurred quite significant changes to fs code, as it was the first version to support directories. Before that, the namespace was flat.
MS-DOS 1.25 does pattern matching mostly the same way . The code is a bit simpler as it doesn't have the crazy macro stuff that MS-DOS 2.0 code has, but if you look a bit around the files, you'll see that it is mostly the same code just moved around and split in several files. The file scan works again in almost the same way, reading each directory entry one by one and doing the pattern matching after the fact.
Read "x" as *, because I could not for the life of me get the star work as a star within a word in this comment.
There was no space on a disk for metadata. You couldn't put metadata on a tape. There wasn't enough memory in the computer for the OS to determine a file type by reading a header, and even if there was, some operating systems had their DOS in ROM, so that would mean never adding any more file types (I'm looking at you, CBM PRG, USR, SEQ, REL files!).
Does anyone know if any of this is true?
(But it isn’t true. https://en.wikipedia.org/wiki/File_Allocation_Table#Original...)
All i needed to read :)