
The early history of Windows file attributes - zdw
https://blogs.msdn.microsoft.com/oldnewthing/20180830-00/?p=99615
======
blattimwind
Little-known fact: Windows/NTFS supports two completely different ways of
what's usually called extended attributes in Unix parlance. You've got the
fairly well known ADS (alternate data streams), which are essentially
unlimited in size, and then the more obscure EAs (extended attributes), which
are much more like xattrs; they're stored in the MFT itself (MFT entries ~
inodes) and are limited, in total, to 64k. From usermode you can only access
EA via the native API (NtQueryEaFile, NtSetEaFile), which are actually
undocumented and read/write all EAs in one go (which presumably is because EAs
are stored in a single file attribute, hence the 64k limit as well).

NTFS _also_ has various special attributes of files, like object IDs (which is
basically a volume-unique ID for a file, much like an inode number, just that
you can actually assign it as an application, and applications can open files
by their object ID via OpenFileById. This is how some kinds of links in
Windows continue to work even if you move their target.).

~~~
yuhong
I found out that they got rid of the support for the "EA DATA. SF" file for
FAT12/FAT16 in Vista.

------
messe
I haven't used a Windows machine regularly in over a decade (the most recent
time was a summer job three years ago, and most of that was spent in PuTTY
session), but I _still_ find the Old New Thing fascinating.

Windows has such a rich history behind it, and it's frankly amazing sometimes
that it works as well as it does given all the backwards compatibility
kludges.

~~~
rogerbinns
> ... that it works as well as it does given all the backwards compatibility
> kludges

I like to joke that Microsoft put the "backwards" in backwards compatibility,
but they really do. Remember that historically software was sold as a product,
and not a service, including operating systems. If you had a bunch of software
that worked, and upgraded from Windows N to Windows N+1 and some of the
software no longer worked, you would naturally blame Windows and not upgrade.
Consequently Microsoft had to maintain good backwards compatibility, and they
did a pretty good job of it over the years. Remember that in some cases people
don't have the source code for programs, or the tools that could build it.
Microsoft preserves that.

~~~
therein
> Remember that in some cases people don't have the source code for programs,
> or the tools that could build it. Microsoft preserves that.

And even if they failed to preserve the source code or the toolchain for
whatever reason, they go to extreme lengths to get fixes in:

[https://blog.0patch.com/2017/11/did-microsoft-just-
manually-...](https://blog.0patch.com/2017/11/did-microsoft-just-manually-
patch-their.html)

------
forgotmypw
> These attributes were retrofitted onto the existing directory structure by
> taking over the high bits of the eleven filename characters! That's why they
> are named F1 through F8 (high bits of the eight-character file base name)
> and T1 through T3 (high bits of the three-character extension, also known as
> the file type).

> You can infer from this that CP/M file names were limited to 7-bit ASCII.

Programmers really took the time to put every available bit to use back then.

------
linuxlizard
My first paid independent gig while back in university was writing a DOS
backup program. I actually used the archive bit for its intended purpose.

