Hacker News new | past | comments | ask | show | jobs | submit login
The early history of Windows file attributes (microsoft.com)
72 points by zdw on Aug 31, 2018 | hide | past | favorite | 9 comments



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.).


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


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.


> ... 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.


> 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-...


> and they did a pretty good job of it over the years.

It's impressive how many traditional desktop programs continue to work in Windows 10. Sadly, a lot of games no longer work, and are dependent on having a solid community to re-port the game. One example is Starsiege:Tribes, whose community is still active: http://www.playt1.com/


Small nit: a service is a product.


> 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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: