NTFS Alternate Data Streams (ADS)
To properly introduce the insertion of ADS support in NTFS, which started with Windows NT 3.1, we must first take a look in the Macintosh world. As some of you might know, Macintosh files do not generally have an extension. Yet, the OS is capable of recognizing who made the application and properly execute it (along with coloring the file based on your settings or other M ac features). T his is possible because M acintosh files have tw o “forks”. T he resource fork, which contains this information, and the data fork, which contains the executable code itself (as a side note, this has changed in Mac OS X).
When Windows NT 3.1 came out, it had compatibility support for AppleTalk, meaning that NT and MacOS users could easily exchange data. This caused a problem however, since there was no way to copy the resource fork and the data fork of a file directly onto the NT file system. Doing so would only copy the data fork, since the resource fork w asn’tphysically in the file, but in a separate stream. (In other words, the data and resource fork don’t occupy the sam e cluster on disk, or are part of the sam e contiguous file). Microsoft then had to implement NTFS ADS, which meant that NT would see the resource fork as another stream, and would be able to copy it along with the file onto a Macintosh computer. Extremely low-leveland inaccessible by m ost A PIs or program s, A D S didn’t becom e popular until much later.
Get pdf download NTFS Alternate Data Streams (ADS)
Related Tutorial
Tags: alternate data streams, asn, becom, compatibility, contiguous file, executable code, insertion, mac os x, macintosh, macintosh computer, macintosh files, macintosh world, macos users, microsoft, os x, pis, resource fork, tw
Comments
Leave a Reply