New Page 1

Windows^® NT File System

In the early 1990s, Microsoft set out to create a high-quality, high-performance, reliable and secure operating system. The goal of this operating system was to allow Microsoft to get a foothold in the lucrative business and corporate market–at the time, Microsoft’s operating systems were MS-DOS and Windows 3.x, neither of which had the power or features needed for Microsoft to take on UNIX or other “serious” operating systems. One of the biggest weaknesses of MS-DOS and Windows 3.x was that they relied on the FAT file system. FAT provided few of the features needed for data storage and management in a high-end, networked, corporate environment. To avoid crippling Windows NT, Microsoft had to create for it a new file system that was not based on FAT. The result was the New Technology File System or NTFS.

It is often said (and sometimes by me, I must admit) that NTFS was “built from the ground up”. That’s not strictly an accurate statement, however. NTFS is definitely “new” from the standpoint that it is not based on the old FAT file system. Microsoft did design it based on an analysis of the needs of its new operating system, and not based on something else that they were attempting to maintain compatibility with, for example. However, NTFS is not entirely new, because some of its concepts were based on another file system that Microsoft was involved with creating: HPFS.

Before there was Windows NT, there was OS/2. OS/2 was a joint project of Microsoft and IBM in the early 1990s; the two companies were trying to create the next big success in the world of graphical operating systems. They succeeded, to some degree, depending on how you are measuring success. :^) OS/2 had some significant technical accomplishments, but suffered from marketing and support issues. Eventually, Microsoft and IBM began to quarrel, and Microsoft broke from the project and started to work on Windows NT. When they did this, they borrowed many key concepts from OS/2’s native file system, HPFS, in creating NTFS.

NTFS was designed to meet a number of specific goals. In no particular order, the most important of these are:

• Reliability: One important characteristic of a “serious” file system is that it must be able to recover from problems without data loss resulting. NTFS implements specific features to allow important transactions to be completed as an integral whole, to avoid data loss, and to improve fault tolerance.
• Security and Access Control: A major weakness of the FAT file system is that it includes no built-in facilities for controlling access to folders or files on a hard disk. Without this control, it is nearly impossible to implement applications and networks that require security and the ability to manage who can read or write various data.
• Breaking Size Barriers: In the early 1990s, FAT was limited to the FAT16 version of the file system, which only allowed partitions up to 4 GiB in size. NTFS was designed to allow very large partition sizes, in anticipation of growing hard disk capacities, as well as the use of RAID arrays.
• Storage Efficiency: Again, at the time that NTFS was developed, most PCs used FAT16, which results in significant disk space due to slack. NTFS avoids this problem by using a very different method of allocating space to files than FAT does.
• Long File Names: NTFS allows file names to be up to 255 characters, instead of the 8+3 character limitation of conventional FAT.
• Networking: While networking is commonplace today, it was still in its relatively early stages in the PC world when Windows NT was developed. At around that time, businesses were just beginning to understand the importance of networking, and Windows NT was given some facilities to enable networking on a larger scale. (Some of the NT features that allow networking are not strictly related to the file system, though some are.)

Of course, there are also other advantages associated with NTFS; these are just some of the main design goals of the file system. There are also some disadvantages associated with NTFS, compared to FAT and other file systems–life is full of tradeoffs. :^) In the other pages of this section we will fully explore the various attributes of the file system, to help you decide if NTFS is right for you.

For their part, Microsoft has not let NTFS lie stagnant. Over time, new features have been added to the file system. Most recently, NTFS 5.0 was introduced as part of Windows 2000. It is similar in most respects to the NTFS used in Windows NT, but adds several new features and capabilities. Microsoft has also corrected problems with NTFS over time, helping it to become more stable, and more respected as a “serious” file system. Today, NTFS is becoming the most popular file system for new high-end PC, workstation and server implementations. NTFS shares the stage with various UNIX file systems in the world of small to moderate-sized business systems, and is becoming more popular with individual “power” users as well.

NTFS Versions

Like most file systems, NTFS has gone through some evolutions. Over time, Microsoft has made changes to it, for many different reasons. These include correcting problems with the file system, adding support for newer hardware, and enabling new operating system features. The biggest change to NTFS came with the introduction to the market of Windows 2000. NTFS changes enable some of the most important features of that operating system.

In this section I describe the two versions of NTFS that are commonly used on PCs. I first talk about NTFS 1.1, which is also called NTFS 4.0 (since it is most commonly used with Windows NT version 4.0). I then discuss the newest NTFS version, NTFS 5.0, which is an integral part of Windows 2000. I conclude with a brief discussion of compatibility between NTFS versions.

Note: The NTFS versions discussed here are used by almost all Windows NT and Windows 2000 installations. Apparently, there was also an earlier version of NTFS, called NTFS 1.0 or NTFS 3.1 (or so I believe), which was used on the first version of Windows NT: Windows NT 3.1. I have been unable to find any information about this version and how it differs from NTFS 1.1 / 4.0. Since Windows NT 3.1 is not really widely used, I am limiting my coverage of that older NTFS version to this note. :^) Still, if you know anything about this first version of NTFS, and are willing to share that knowledge with me, I’d appreciate it!

NTFS 1.1 / 4.0

The most widely-implemented version of the NTFS file system has two different names. It is “officially” called NTFS version 1.1. However, it is also commonly called NTFS 4.0, in reference to its use by the most popular version of the operating system, Windows NT 4.0. NTFS 1.1 is also used natively by the prior version of Windows NT, Windows NT 3.51. It is also supported by several other operating systems, for compatibility purposes, though generally only in “read only” mode. (See this comparison table for more information.)

All of the fundametal characteristics and features explained in the other sections in our coverage of NTFS are supported by NTFS 1.1. When people talk about NTFS, they typically consider NTFS 1.1 to be the “default” version of the file system. Reflecting this, I have not specifically identified each NTFS feature as being supported by NTFS 1.1. Instead, I have labeled the few features particular to NTFS 5.0 appropriately, so you can watch for these notes if you want to be sure to identify where the differences in NTFS versions are. Of course, the following page on NTFS 5.0 also lists the main changes made in NTFS 5.0 as well.

Windows 2000 is designed specifically to use NTFS version 5.0. Because of this requirement, and because Windows 2000 (and its successors) will likely replace Windows NT over time, it seems likely that NTFS 1.1 will eventually be relegated to a “background” role. However, the vast popularity of Windows NT, and its millions of current installtions, mean that NTFS 1.1 partitions will be around for a long time to come.

NTFS 5.0

When Microsoft finally shipped its long-awaited new Windows NT operating system, they surprised a few people by naming it not Windows NT 5.0, as had been expected, but Windows 2000. However, the version of NTFS that shipped with Windows 2000 provided a hint at the original name of the operating system: NTFS 5.0. The fact that Microsoft created a new version of the file system to go along with its new operating system demonstrates just how important the NTFS file system is to Windows NT and Windows 2000. Several of the new features in Windows 2000 actually depend on features built into NTFS 5.0, such as the Active Directory service.

The following are the most important of the new features and capabilities that were added to NTFS with version 5.0. Each has been linked to the page where you can read about it in more detail:

• Reparse Points: Files and directories within the file system can have actions associated with them, so that when the file system object is accessed in a particular way, the action is carried out.
• Improved Security and Permissions: The mechanisms for managing file system security and assigning permissions were improved.
• Change Journals: Disk volumes can be set to keep track of all operations performed on the files and directories they contain.
• Encryption: NTFS 5.0 allows you to encrypt files and automatically decrypt them as they are read.
• Disk Quotas: Administrators can track how much disk space is being used by users or groups of users, and even limit disk space use if necessary.
• Sparse File Support: To save space on the disk, support was added for the more efficient storage of sparse files, which are large files that are mostly empty.
• Disk Defragmenter: Windows 2000 includes a disk defragmentation program, where Windows NT did not. (Arguably, this is an operating system feature of Windows 2000, and not a file system enhancement, but I thought I’d mention it anyway, since it is obviously file system related.)

Of course, this list isn’t comprehensive; there were also some other, minor improvements made in a variety of areas within the file system. This includes fixing some bugs that existed in the older version of the file system, though the new features undoubtedly mean that new ones were included as well. :^) Even the items above represent a rather substantial set of enhancements to what was already a very powerful file system. Of course, NTFS 5.0 also supports all of the features included in older versions of the file system.

As I mentioned above, NTFS 5.0 is required by Windows 2000. In fact, if you install Windows 2000 on top of Windows NT, Windows 2000 will convert any older NTFS partitions to NTFS 5.0. For more on compatibility issues between NTFS 5.0 and older versions of the file system, see the next page.

NTFS Version Compatibility

Microsoft’s decision to greatly enhance the NTFS file system under Windows 2000 resulted in a number of new features that most users consider advantageous. However, in creating the new 5.0 version of NTFS, compatibility issues became a concern under some circumstances. In particular, file system compatibility becomes an issue when mixing disk volumes between systems that have different versions of Windows installed. Multiple operating system PCs that have both Windows NT and Windows 2000 installed also may run into difficulties.

There are in fact several different compatibility issues here, which are related. In no particular order:

• Windows 2000 Automatic Conversion: Windows 2000 will automatically convert to NTFS 5.0 any NTFS 1.1 file systems it sees when it boots. Even well after the operating system has been installed, if you add an NTFS 1.1 partiton to a Windows 2000 system, it will be converted to NTFS 5.0. This can cause problems, as mentioned above, on systems that boot to both Windows NT and Windows 2000. In some circumstances it may be better to avoid using NTFS under Windows 2000 to avoid this situation.
• Automatic Conversion of Removable Disks: Apparently, the behavior above also applies to removable media that has been formatted using the older versions of NTFS! This means that those who move files between Windows NT and Windows 2000 machines may need to pay attention to how they use their media. :^)
• Windows NT Compatibility with NTFS 5.0: In order for Windows NT to be able to read or write NTFS 5.0 partitions, Service Pack #4 (SP4) or higher must be installed on the system. This patch contains a new version of the NTFS.SYS driver file. However, even though this gives Windows NT access to NTFS 5.0 partitions, the operating system components needed to enable the new features in NTFS 5.0 are not installed. This means that the new features described here do not function under Windows NT, even with SP4 installed.
• Non-Microsoft Operating System Compatibility: As shown on this cross-reference chart, certain non-Microsoft operating systems can access both NTFS 1.1 and NTFS 5.0 partitions, in read-only fashion. Being newer, NTFS 5.0 support generally requires a newer version or build number than NTFS 1.1 support.

The PC Guide is not a site that focuses specifically on operating systems, so I do not come even close to discussing all the nuances of Windows NT or Windows 2000 installations. If you are going to be working extensively with these operating systems, I would recommend that you consult more comprehensive documentation on the operating systems, and in particular, issues involved with file system installation and support. This applies even more to those who will be setting up complex systems, such as those that boot more than one operating system.

NTFS Architecture and Structures

In order to achieve the many goals that Microsoft had for its new file system, it was necessary to be very diligent in the way that NTFS was designed, starting with the fundamentals. The term architecture is often used to refer to the basic structures and concepts used to organize a complex system, be it a file system, operating system, microprocessor or what have you. To ensure that NTFS meets the needs of its many demanding users, it incorporates a very specific set of structures and techniques.

In this section, I provide a description of the architecture of NTFS volumes, and the key structures that make up an NTFS partition. This includes an overview of NTFS architecture and an explanation of how NTFS uses certain key file system structures to store information. I also discuss NTFS partition size and cluster size considerations, and contrast these to the way FAT partitions work.

NTFS Architecture Overview

Most of the weaknesses of the FAT file system result directly from the rather simplistic and outdated architecture it uses. No provisions were made in the internal structures of FAT partitions to allow for security and reliability features, making it very difficult to add such capabilities later on. In contrast, NTFS has a special architecture that not only allows for these advanced abilities, but also uses a simple conceptual scheme that makes it easier for more features to be added in the future with a minimum of changes. (In fact, this characteristic was employed when NTFS 5.0 came out with several new options.)

The elegance of the NTFS architecture can be seen in how information is stored in an NTFS partition. Virtually every structure in NTFS is a file, including the structures used to manage the partition and maintain statistics and control information about the partition itself. The control information is stored in a set of special files that are created when an NTFS partition is first created; these are called metadata files and include such items as lists of files on the partition, volume information, cluster allocations, and so forth. One exception to the “everything is a file” rule is the partition boot sector, which precedes the metadata files on an NTFS partition and controls the most basic of NTFS operations, such as loading the operating system.

The same simple conceptual model used for files and control structures is extended to the internal level of files as well. Every file in an NTFS partition is a collection of attributes; this even includes the data that the file contains, which is just considered one of many attributes. Other attributes include items such as the file’s name and size. This arrangement really a database-like setup–the operating system view files as being objects with various characteristics, and manages them accordingly. This makes it easy to manage files and add attributes if needed in the future.

Internally, NTFS stores all files (including metadata files) using a cluster system–each file is broken into clusters, each of which contain a binary number of 512-byte sectors. On the surface, this is somewhat similar to how FAT stores data, but the implementation of clusters in NTFS is somewhat different. You can read more about clusters under NTFS here.

NTFS Volume Boot Sector

When an NTFS partition is first created, the first block of information created on the partition is the volume boot sector. This fundamental structure, which is part of a very small block of NTFS management information that is not stored within the master file table on an NTFS volume, is very much the analog of the volume boot sector under the FAT file system. Like volume boot sectors in FAT, the NTFS volume boot sector is sometimes called the partition boot sector, volume boot record or other similar names.

Note: Despite the use of the word “sector” in the name of this structure, the volume boot sector can in fact be up to 16 sectors (8 kiB) in length.

The NTFS volume boot sector begins in the first sector of the partition, and consists of two different primary structures. Again, these are similar to the structures in a FAT volume boot sector:

• BIOS Parameter Block: This is a block of data that contains fundamental information about the volume itself. This block identifies the volume as an NTFS partition, and includes such information as the volume label and its size. In addition, NTFS provides for an extended BIOS parameter block, which contains additional information about the volume such as the location of the key metadata files.
• Volume Boot Code: This is a small block of program code that instructs the system on how to load the operating system. With an NTFS volume, this code will be specific to Windows NT or 2000, whichever is installed on the system. It will generally load NTLDR, the NT loader program, and then transfer control to it to load the rest of the operating system. Note that this code is also present in the partition as a system (metadata) file.

The volume boot code on a FAT file system partition is a favorite target of virus writers, as changing this code can allow a virus to automatically load whenever the system has started. The higher-security design of Windows NT and 2000, however, makes it more difficult for viruses in the boot sector code to spread, due to the fact that the operating system maintains tighter control over disk access routines once it has loaded. (Viruses are still possible on Windows NT/2000 systems, of course.)

NTFS System (Metadata) Files

As I mentioned in the architectural overview, the NTFS file system stores virtually all data, both user data and internal management data, in the form of files. The most important of these are a set of special system files, which are also called metadata files. The prefix “meta-” generally refers to something “transcendent” or “beyond”–or merely self-referring. So “metadata files” are files that contain data about data. And that’s exactly what these files do. They contain internal information (data) about the “real” data stored on the NTFS volume.

These metadata files are created automatically by the system when an NTFS volume is formatted, and are placed at the beginning of the partition. Now, explaining how these files work is a bit complicated. :^) Understanding their location in an NTFS volume requires that I mention another key structure, the NTFS Master File Table (MFT). The MFT is actually one of these metadata files, but it also contains descriptions of the other metadata files, and in some cases entire other metadata files. Yes, it’s a bit confusing. :^) Reading the page on the MFT will help you understand how it works, but in a nutshell, here’s what happens: the MFT contains a record describing every file and directory in an NTFS volume, and if the file is small enough, its actual contents may be stored in the MFT itself. Since the metadata files are just “files” to NTFS (albeit special ones), they too have records in the MFT. In fact, the first 16 records of the MFT are reserved for metadata files.

Phew, sorry about that, but hey, I didn’t design this thing. :^) Actually, the system is hard to explain, but it is logically consistent, and does work well. The table below provides the important information about the metadata files, including their English names, file names, MFT record numbers and a brief description of what each does:

Metadata File Name	File Name	MFT Record #	Description
Master File Table (MFT)	$MFT	0	This is the MFT itself. This seems to be a bit of a chicken-and-egg problem–how can a record in the MFT contain the MFT? :^) It doesn’t. This first MFT record contains descriptive information about the MFT. This is consistent with how NTFS works–since the MFT itself is just “a file”, so it also needs a record in the MFT!
Master File Table 2 (MFT2) or Master File Table Mirror	$MFTMirr	1	This is a mirror of the first 16 records of the real Master File Table. It is stored either in the middle of the partition (for Windows NT 3.5 and earlier) or the end of the partition (for Windows NT 4.0 and later). The mirror is a “backup” that is used to ensure that the first few records of the MFT, which of course describe the metadata files themselves, can be accessed in case of a disk error on the original MFT.
Log File	$LogFile	2	The transaction logging file for the volume. This is part of NTFS’s file system recoverability feature.
Volume Descriptor	$Volume	3	Contains key information about the volume (partition) itself, such as its name, NTFS version, creation time, and so on. See the complete list of NTFS file attributes for more information.
Attribute Definition Table	$AttrDef	4	This table contains the names and descriptions of the various types of NTFS file attributes used on the volume. (It doesn’t contain the attributes themselves, but rather descriptions of what the attributes mean. Remember–metadata.)
Root Directory / Folder	“.” (single period)	5	This is a pointer to the root directory or folder of the volume.
Cluster Allocation Bitmap	$Bitmap	6	Contains a “map” showing which clusters on the volume are used and which are available for use.
Volume Boot Code	$Boot	7	This record contains a copy of the volume boot code (or a pointer to it). The volume boot code is also found in the volume boot sector.
Bad Cluster File	$BadClus	8	A list of all clusters on the volume that have been marked as “bad” (meaning, an error was detected on the volume somewhere in those clusters, so the file system wants to be sure not to use them again.)
Quota Table	$Quota	9	Table containing quota information, if disk quotas are being used on the volume. Only used for NTFS 5.0 or later.
Upper Case Table	$UpCase	10	Table containing information for converting file names to the Unicode (16-bit) file naming system for international compatibility.

Note: Records 11 through 15 in the MFT (the 12th through 16th records, since MFT records are numbered starting from zero) are reserved for future metadata files.

The elegance of the metadata system is that by storing internal information in files, it is possible to expand on the capabilities of the file system–changing “dedicated” internal structures is more complicated. Also, these files do not need to be stored in a specific location on the hard disk, so if a specific area of the hard disk is damaged, they can be moved.

Master File Table (MFT)

Probably the most important of the key system (metadata) files that define an NTFS volume, the Master File Table or MFT is the place where information about every file and directory on an NTFS volume is stored. The MFT is in essence a relational database table, containing various attributes about different files. It acts as the “starting point” and central management feature of an NTFS volume–sort of a “table of contents” for the volume, if you will. It is somewhat analog to the file allocation table in a FAT partition, but is much more than just a list of used and available clusters.

When any file or directory is created on the NTFS volume, a record is created for it within the MFT. The size of each record in the MFT seems to be a matter of some controversy; the best that I can tell is that each record is equal to the cluster size of the volume, but with a minimum of 1,024 bytes and a maximum of 4,096. (Meaning that even if 512 byte clusters are used, each MFT record is still 1,024 bytes, and even if clusters greater than 4,096 bytes are used, each MFT record is limited to 4,096 bytes.) However, some sources say that the size of each MFT record is fixed at either 1,024 or 2,048 bytes. (If you know what the deal is with this for certain, please let me know!)

The system uses these MFT records to store information about the file or directory; this information takes the form of attributes. Since the size of each MFT record is limited, there are different ways that NTFS can store a file’s attributes: as either resident attributes that are stored within the MFT record, or non-resident attributes, stored either in additional MFT records or in extents that lie outside the MFT. See the discussion of file attributes for more details.

Remember that under NTFS, there is no special distinction between the data in a file and the attributes that describe the file–the data itself is just the contents of the “data attribute”. This has an interesting implication for small files. If the amount of space required for all of the attributes of a file, including the data it contains, is smaller than the size of the MFT record, the data attribute will be stored resident–within the MFT record itself. Thus, such files require no additional storage space on the volume, and also do not require separate accesses to the disk to check the MFT and then read the file, which improves performance.

Larger files get more complicated. As additional attributes are added to a file–either standard attributes defined by the system or new ones created by the user–and as the existing attributes are expanded in size, they may no longer fit into the MFT record for the file. If this occurs, the attributes will be moved out of the MFT and be made non-resident by the file system. Large files will have their data stored as external attributes, and very large files may even get so large that the attributes containing pointers to the file data become external attributes themselves! I discuss this nested structuring of files on the page describing NTFS files and data storage.

As more files and directories are added to the file system, it becomes necessary for NTFS to add more records to the MFT. Since keeping the MFT contiguous on the disk improves performance, when an NTFS volume is first set up, the operating system reserves about 12.5% of the disk space immediately following the MFT; this is sometimes called the “MFT Zone”. This is a substantial chunk of real estate to reserve, but bear in mind that it is still usable. Regular files and directories will not use this space until and unless the rest of the disk volume space is consumed, but if that occurs, the “MFT Zone” will be used. Eventually, if there are enough entries placed in the MFT, as it expands it will use up the “MFT Zone”. When this happens, the operating system will automatically allocate more space elsewhere on the disk for the MFT. This allows the MFT to grow to a size limited only by the size of the volume, but this fragmentation of the MFT may reduce performance by increasing the number of reads required for some files, and the MFT cannot generally be defragmented.

Note: The first sixteen records in the MFT are always reserved for the volume’s metadata files.

NTFS Partitions and Partition Sizes

NTFS partitions are very different from FAT file system partitions on the inside–in terms of their structures and how they function. However, externally, they conform to the general rules that apply to all partitions. This is necessary to ensure that the PC boot process can handle an NTFS partition in pretty much the same way that it does a FAT partition. Therefore, like FAT partitions, you can have primary or logical NTFS partitions, and logical NTFS partitions fit within an extended partition. You can find more information about these terms and the rules for partitions on this page.

Since NTFS was designed from the start to be a file system suitable for use in corporate and business environments, it is no surprise that the file system allows very large partitions to be created. Recall that at the time Windows NT was released, the only versions of FAT that existed were FAT12 and FAT16–FAT32 had not yet been created. The maximum partition size of FAT16 under Windows NT is 2 GiB using 32 kiB clusters, or 4 GiB using the non-standard 64 kiB clusters that other versions of Windows do not support. Considering the large storage needs of businesses, and also considering that many businesses servers use RAID to create even larger volumes, such small size limits would have been completely unacceptable in NTFS, even a decade ago when NTFS was being developed.

Under NTFS, the maximum size of a partition (volume) is in fact 2 to the 64th power. This is equal to 16 binary exabytes, or 18,446,744,073,709,551,616 bytes. Does that seem large enough for your needs? :^) Well, many problems with PC hard disks occurred when unintentional size limits were imposed by engineers who figured that, for example, “2 gigabytes ought to be enough”. However, with 18 billion gigabytes it would seem that you should be safe for a while in NTFS. :^)

Then again, it always pays to be careful when looking at such huge numbers. For example, I pointed out elsewhere that FAT32 claims to be able to support up to 2 TiB partitions, but does so at the cost of tremendous slack waste and an enormous file allocation table. NTFS is a completely different file system, but since it was designed at a time when hard disk sizes were measured in single gigabytes, there’s no real way to know how well it will scale to disk volumes that are thousands or even millions of gigabytes in size. I suppose we will get there in due time, but as the paragraph below explains, there are already provisos on these large volume limits.

Under Windows NT there are significant restrictions imposed on the size of the boot partition–the first partition on the drive. During installation, Windows NT always first creates a FAT16 partition. Even if you tell NT that you want to install to an NTFS partition, it first creates a FAT16 partition and then converts it to NTFS. Since the maximum size of a Windows NT FAT16 partition is 4 GiB, this limits the size of your boot partition as well. Even if you use a third-party tool to increase the size of the partition, you run into another limitation: Windows NT can’t boot from a partition larger than 7.88 GiB period, regardless of how you create it (this is associated with Windows NT’s older design, which predates the implementation of the Int 13h Extensions required for large hard disk access).

Due to these limitations, many NT setups use at least two partitions–a smaller one for the operating system and a larger one for applications and data. Many people find this a good way to set up the disk anyway, as it keeps operating system files separate from others. These boot size limit problems have been eliminated in Windows 2000. You can format and use an entire large hard disk in a single partition under Windows 2000.

Tip: I have a full page on partitioning strategies under NTFS in the section on implementation.

Note: BIOS issues associated with IDE/ATA hard disks can impose partition size limits irrespective of the operating system or file system. In particular, support for IDE/ATA hard disks over 7.88 GiB requires a BIOS with support for Int 13h Extensions.

NTFS Clusters and Cluster Sizes

One of the ways that NTFS is similar to the FAT file system is that it does not manage individual 512-byte sectors on the hard disk volume independently. Instead, it groups them into blocks that are called clusters, or sometimes, allocation units. The main reason for doing this is performance: if individual sectors were used for data storage on a very large disk, many resources would be required to keep track of what was in each one, and fragmentation of the disk would be much more of a problem. For a more thorough discussion of clusters and how they work, see this discussion of clusters in the FAT file system section.

While both FAT and NTFS use clusters, they use them in a very different way, of course. This is due to the differences in the internal structures of the two file systems. Some of the performance issues associated with very large FAT file system partitions are due to the fact that the file allocation tables grow to a very large size, and FAT was never created with extremely large volumes in mind. In contrast, NTFS is designed to be able to better handle the large internal structures (such as the MFT) that occur with large partitions.

Like FAT, NTFS chooses a default cluster size based on the size of the partition. However, it uses a different method for selecting the cluster size for a partition than the default cluster assignment system for FAT16 and the one for FAT32. The table below shows the default cluster sizes that NTFS chooses for various partition sizes:

Partition Size Range (GiB)	Default Number of Sectors Per Cluster	Default Cluster Size (kiB)
0.5 to 1.0	2	1
> 1.0 to 2.0	4	2
> 2.0 to 4.0	8	4
> 4.0 to 8.0	16	8
> 8.0 to 16.0	32	16
> 16.0 to 32.0	64	32
> 32.0	128	64

Now, I am sure you noticed rather quickly that there are some colors in this chart that you normally don’t see on the pages of this site. :^) This was done to distinguish the two halves of the chart, because NTFS uses two different assignment systems, depending on the version of the operating system:

• Windows NT 3.5 and Earlier: The first versions of the file system use the entire table above. So if you are running Windows NT 3.5 and create a single 6 GB partition, it will use 16 sectors per cluster (8 kiB).
• Windows NT 3.51 and Later (Including Windows 2000): Only the first four entries in the table are used. The maximum cluster size is 4 kiB for all partitions over 2.0 GiB, regardless of their size.

The reason for the difference between operating systems is perhaps a bit surprising: it has to do with NTFS’s built-in file-based compression. Compression is not supported on file systems with cluster sizes over 4 kiB. Since most people like this feature, the setup and formatting programs in newer Windows operating systems will not choose a cluster size over 4 kiB in size. Windows NT 3.5 and earlier do not support file-based compression, so they don’t have to worry about this, and they use the full table. (In practice, it’s atypical to find a hard disk much bigger than 4 GB running such an old version of Windows NT anyway…)

The size of the clusters in a partition has an important impact on the performance of the system. While the table above shows the default cluster size for NTFS partitions, the default can be overridden by using the “/A” parameter of the FORMAT command. For example, “FORMAT D: /A:8192” will format the D: drive with 8,192-byte clusters. However, you should be careful before overriding the defaults and choosing a larger cluster size for a partition. You will lose the ability to use NTFS file compression, and the amount of slack will increase as well. Slack refers to wasted space due to files of variable size being placed into clusters of fixed size. The bigger the clusters, the more space that is wasted; while typically considered a FAT file system issue, this becomes relevant to NTFS as well if you use larger clusters. See this FAT file system page for a full explanation of slack. I also have written a more comprehensive discussion of NTFS partition size and cluster size selection issues. The default of 4 kiB for modern hard disk volumes is generally considered a decent overall compromise.

Note: One final issue has an impact on the cluster size of NTFS partitions, if you are using Windows NT (any version, including 4.0.) Windows NT only uses the cluster table above if you are creating a new NTFS partition. If you are converting a partition from FAT to NTFS, Windows NT will always make the NTFS volume use the smallest clusters: 512 bytes. In fact, this even applies if you initially install Windows NT to an NTFS partition, because during installation NT always first creates a FAT partition and then converts it to NTFS! See here for more on NTFS conversion. Windows 2000 does not have this limitation.

NTFS Directories and Files

Yes, NTFS volumes have directories and files. Isn’t that good to know? :^) Well, you probably want to learn a bit more about them than that, I am sure, and in this part of the NTFS guide I will endeavor to do just that. If you are experienced with the FAT file system used in other versions of Windows, then as a user of NTFS partitions, you will find much that is familiar in the way directories and files are used. However, internally, NTFS stores and manages directories and files in a rather different way than FAT does.

In this section I will explore the fundamentals of NTFS directories and files. I will begin with a look at directories and how they are stored on NTFS volumes. I will then discuss user data files in some detail, including a look at how files are stored and named, and what their maximum size can be. I will then describe some of the more common standard attributes associated with files. Finally, I will discuss reparse points, a special enhanced feature present in NTFS 5.0 under Windows 2000.

NTFS Directories (Folders)

From an external, structural perspective, NTFS generally employs the same methods for organizing files and directories as the FAT file system (and most other modern file systems as well). This is usually called the hierarchical or directory tree model. The “base” of the directory structure is the root directory, which is actually one of the key system metadata files on an NTFS volume. Within this root directory, references are stored to files, or to other directories. Each directory can in turn store any combination of files or more sub-directories, allowing you to create an arbitrary tree structure. I describe these general concepts in more detail on this page discussing the FAT file system.

Note: Directories are also often called folders.

While NTFS is similar to FAT in its hierarchical structuring of directories, it is very different in how they are managed internally. One of the key differences is that in FAT volumes, directories are responsible for storing most of the key information about files; the files themselves contain only data. In NTFS, files are collections of attributes, so they contain their own descriptive information, as well as their own data. An NTFS directory pretty much stores only information about the directory itself, not about the files within the directory.

Everything within NTFS is considered a file, and that applies to directories as well. Each directory has an entry in the Master File Table, which serves as the main repository of information for the directory. The MFT record for the directory contains the following information and NTFS attributes:

• Header (H): This is a set of low-level management data used by NTFS to manage the directory. It includes sequence numbers used internally by NTFS and pointers to the directory’s attributes and free space within the record. (Note that the header is part of the MFT record but not an attribute.)
• Standard Information Attribute (SI): This attribute contains “standard” information stored for all files and directories. This includes fundamental properties such as date/time-stamps for when the directory was created, modified and accessed. It also contains the “standard” attributes usually associated with a file (such as whether the file is read-only, hidden, and so on.)
• File Name Attribute (FN): This attribute stores the name associated with the directory. Note that a directory can have multiple file name attributes, to allow the storage of the “regular” name of the file, along with an MS-DOS short filename alias and also POSIX-like hard links from multiple directories. See here for more on NTFS file naming.
• Index Root Attribute: This attribute contains the actual index of files contained within the directory, or part of the index if it is large. If the directory is small, the entire index will fit within this attribute in the MFT; if it is too large, some of the information is here and the rest is stored in external index buffer attributes, as described below.
• Index Allocation Attribute: If a directory index is too large to fit in the index root attribute, the MFT record for the directory will contain an index allocation attribute, which contains pointers to index buffer entries containing the rest of the directory’s index information.
• Security Descriptor (SD) Attribute: This attribute contains security information that controls access to the directory and its contents. The directory’s Access Control Lists (ACLs) and related data are stored here.

So in a nutshell, small directories are stored entirely within their MFT entries, just like small files are. Larger ones have their information broken into multiple data records that are referenced from the root entry for the directory in the MFT. NTFS uses a special way of storing these index entries however, compared to traditional PC file systems. The FAT file system uses a simple linked-list arrangement for storing large directories: the first few files are listed in the first cluster of the directory, and then the next files go into the next cluster, which is linked to the first, and so on. This is simple to implement, but means that every time you look at the directory you must scan it from start to end and then sort it for presentation to the user. It also makes it time-consuming to locate individual files in the index, especially with very large directories.

To improve performance, NTFS directories use a special data management structure called a B-tree. This is a concept taken from relational database design. In brief terms, a B-tree is a balanced storage structure that takes the form of trees, where data is balanced between branches of the tree. It’s kind of hard to explain what B-trees are without getting far afield, so if you want to learn more about them, try this page. (Note that the “B-tree” concept here refers to a tree of storage units that hold the contents of an individual directory; it is a different concept entirely from that of the “directory tree”, a logical tree of directories themselves.)

From a practical standpoint, the use of B-trees means that the directories are essentially “self-sorting”. There is a bit more overhead involved when adding files to an NTFS directory, because they must be placed in this special structure. However, the payoff occurs when the directories are used. The time required to find a particular file under NTFS is dramatically reduced compared to an unsorted linked-list structure–especially for very large directories.

NTFS Files and Data Storage

As with most file systems, the fundamental unit of storage in NTFS from the user’s perspective is the file. A file is just a collection of any sort of data, and can contain anything: programs, text files, audio clips, database records–and thousands of other kinds of information. The operating system doesn’t distinguish between types of files. The use of a particular file depends on how it is interpreted by applications that use it.

Within NTFS, all files are stored in pretty much the same way: as a collection of attributes. This includes the data in the file itself, which is just another attribute: the “data attribute”, technically. Note that to understand how NTFS stores files, one must first understand the basics of NTFS architecture, and in particular, it’s good to comprehend what the Master File Table is and how it works. You may also wish to review the discussion of NTFS attributes, because understanding the difference between resident and non-resident attributes is important to making any sense at all of the rest of this page. ;^)

The way that data is stored in files in NTFS depends on the size of the file. The core structure of each file is based on the following information and attributes that are stored for each file:

• Header (H): The header in the MFT is a set of low-level management data used by NTFS to manage the directory. It includes sequence numbers used internally by NTFS and pointers to the file’s other attributes and free space within the record. (Note that the header is part of the MFT record but not an attribute.)
• Standard Information Attribute (SI): This attribute contains “standard” information stored for all files and directories. This includes fundamental properties such as date/time-stamps for when the file was created, modified and accessed. It also contains the “standard” FAT-like attributes usually associated with a file (such as whether the file is read-only, hidden, and so on.)
• File Name Attribute (FN): This attribute stores the name associated with the file. Note that a file can have multiple file name attributes, to allow the storage of the “regular” name of the file, along with an MS-DOS short filename alias and also POSIX-like hard links from multiple directories. See here for more on NTFS file naming.
• Data (Data) Attribute: This attribute stores the actual contents of the file.
• Security Descriptor (SD) Attribute: This attribute contains security information that controls access to the file. The file’s Access Control Lists (ACLs) and related data are stored here.

These are the basic attributes; others may also be associated with a file (see this full discussion of attributes for details). If a file is small enough that all of its attributes can fit within the MFT record for the file, it is stored entirely within the MFT. Whether this happens or not depends largely on the size of the MFT records used on the volume. If the file is too large for all of the attributes to fit in the MFT, NTFS begins a series of “expansions” that move attributes out of the MFT and and make them non-resident. The sequence of steps taken is something like this:

1. First, NTFS will attempt to store the entire file in the MFT entry, if possible. This will generally happen only for rather small files.
2. If the file is too large to fit in the MFT record, the data attribute is made non-resident. The entry for the data attribute in the MFT contains pointers to data runs (also called extents) which are blocks of data stored in contiguous sections of the volume, outside the MFT.
3. The file may become so large that there isn’t even room in the MFT record for the list of pointers in the data attribute. If this happens, the list of data attribute pointers is itself made non-resident. Such a file will have no data attribute in its main MFT record; instead, a pointer is placed in the main MFT record to a second MFT record that contains the data attribute’s list of pointers to data runs.
4. NTFS will continue to extend this flexible structure if very large files are created. It can create multiple non-resident MFT records if needed to store a great number of pointers to different data runs. Obviously, the larger the file, the more complex the file storage structure becomes.

The data runs (extents) are where most file data in an NTFS volume is stored. These runs consist of blocks of contiguous clusters on the disk. The pointers in the data attribute(s) for the file contain a reference to the start of the run, and also the number of clusters in the run. The start of each run is identified using a virtual cluster number or VCN. The use of a “pointer+length” scheme means that under NTFS, it is not necessary to read each cluster of the file in order to determine where the next one in the file is located. This method also reduces fragmentation of files compared to the FAT setup.

NTFS File Size

One of the most important limiting issues for using serious business applications–especially databases–under consumer Windows operating systems and the FAT file system, is the relatively small maximum file size. In some situations the maximum file size is 4 GiB, and for others it is 2 GiB. While this seems at first glance to be fairly large, in fact, neither is even close to being adequate for the needs of today’s business environment computing. Even on my own home PC I occasionally run up against this limit when doing backups to hard disk files.

In the page describing how data is stored in NTFS files, I explained the way that NTFS first attempts to store files entirely within the MFT record for the file. If the file is too big, it extends the file’s data using structures such as external attributes and data runs. This flexible system allows files to be extended in size virtually indefinitely. In fact, under NTFS, there is no maximum file size. A single file can be made to take up the entire contents of a volume (less the space used for the MFT itself and other internal structures and overhead.)

NTFS also includes some features that can be used to more efficiently store very large files. One is file-based compression, which can be used to let large files take up significantly less space. Another is support for sparse files, which is especially well-suited for certain applications that use large files that have non-zero data in only a few locations.

NTFS File Naming

Microsoft’s early operating systems were very inflexible when it came to naming files. The DOS convention of eight characters for the file name and three characters for the file extension–the so-called “8.3 standard”–was very restrictive. Compared to the naming abilities of competitors such as UNIX and the Apple Macintosh, 8.3 naming was simply unacceptable. To solve this problem, when NTFS was created, Microsoft gave it greatly expanded the file naming capabilities.

The following are the characteristics of regular file names (and directory names as well) in the NTFS file system:

• Length: Regular file names can be up to 255 characters in NTFS.
• Case: Mixed case is allowed in NTFS file names, and NTFS will preserve the mixed case, but references to file names are case-insensitive. An example will make this much more clear. :^) Suppose you name a file “4Q Results.doc” on an NTFS volume. When you list the directory containing this file, you will see “4Q Results.doc”. However, you can refer to that file by both the name you gave, as well as “4q results.doc”, “4q ReSulTS.dOc”, and so on.
• Characters: Names can contain any characters, including spaces, except the following (which are reserved because they are generally used as file name or operating system delimiters or operators): ? ” / \ < > * | :
• Unicode Storage: All NTFS file names are stored in a format called Unicode. Recall that conventional storage for characters in computers is based on the ASCII character set, which uses one byte (actually, 7 bits) to represent the hundred or so “regular” characters used in Western languages. However, a single byte can only hold a couple of hundred different values, which is insufficient for the needs of many languages, especially Asian ones. Unicode is an international, 16-bit character representation format that allow for thousands of different characters to be stored. Unicode is supported throughout NTFS.

Tip: For more information about Unicode, see this web site.

You may recall that when Windows 95’s  VFAT file system introduced long file names to Microsoft’s consumer operating systems, it provided for an aliasing feature. The file system automatically creates a short file name (“8.3”) alias of all long file names, for use by older software written before long file names were introduced. NTFS does something very similar. It also creates a short file name alias for all long file names, for compatibility with older software. (If the file name given to the file or directory is short enough to fit within the “8.3”, no alias is created, since it is not needed). It’s important to realize, however, that the similarities between VFAT and NTFS long file names are mostly superficial. Unlike the VFAT file system’s implementation of long file names, NTFS’s implementation is not a kludge added after the fact. NTFS was designed from the ground up to allow for long file names.

File names are stored in the file name attribute for every file (or directory), in the Master File Table. (No big surprise there!) In fact, NTFS supports the existence of multiple file name attributes within each file’s MFT record. One of these is used for the regular name of the file, and if a short MS-DOS alias file name is created, it goes in a second file name attribute. Further, NTFS supports the creation of hard links as part of its POSIX compliance. Hard links represent multiple names for a single file, in different directories. These links are each stored in separate file name attributes. (This is a limited implementation of the very flexible naming system used in UNIX file systems.)

NTFS File Attributes

As I mention in many places in this discussion of NTFS, almost everything in NTFS is a file, and files are implemented as collections of attributes. Attributes are just chunks of information of various sorts–the meaning of the information in an attribute depends on how software interprets and uses the bits it contains. Directories are stored in the same general way as files; they just have different attributes that are used in a different manner by the file system.

All file (and directory) attributes are stored in one of two different ways, depending on the characteristics of the attribute–especially, its size. The following are the methods that NTFS will use to store attributes:

• Resident Attributes: Attributes that require a relatively small amount of storage space are stored directly within the file’s primary MFT record itself. These are called resident attributes. Many of the simplest and most common file attributes are stored resident in the MFT file. In fact, some are required by NTFS to be resident in the MFT record for proper operation. For example, the name of the file, and its creation, modification and access date/time-stamps are resident for every file.
• Non-Resident Attributes: If an attribute requires more space than is available within the MFT record, it is not stored in that record, obviously. Instead, the attribute is placed in a separate location. A pointer is placed within the MFT that leads to the location of the attribute. This is called non-resident attribute storage.

In practice, only the smallest attributes can fit into MFT records, since the records are rather small. Many other attributes will be stored non-resident, especially the data of the file, which is also an attribute. Non-resident storage can itself take two forms. If the attribute doesn’t fit in the MFT but pointers to the data do fit, then the data is placed in a data run, also called an extent, outside the MFT, and a pointer to the run is placed in the file’s MFT record. In fact, an attribute can be stored in many different runs, each with a separate pointer. If the file has so many extents that even the pointers to them won’t fit, the entire data attribute may be moved to an external attribute in a separate MFT record entry, or even multiple external attributes. See the discussion of file storage for more details on this expansion mechanism.

NTFS comes with a number of predefined attributes, sometimes called system defined attributes. Some are associated with only one type of structure, while others are associated with more than one. Here’s a list, in alphabetical order, of the most common NTFS system defined attributes:

• Attribute List: This is a “meta-attribute”: an attribute that describes other attributes. If it is necessary for an attribute to be made non-resident, this attribute is placed in the original MFT record to act as a pointer to the non-resident attribute.
• Bitmap: Contains the cluster allocation bitmap. Used by the $Bitmap metadata file.
• Data: Contains file data. By default, all the data in a file is stored in a single data attribute–even if that attribute is broken into many pieces due to size, it is still one attribute–but there can be multiple data attributes for special applications.
• Extended Attribute (EA) and Extended Attribute Information: These are special attributes that are implemented for compatibility with OS/2 use of NTFS partitions. They are not used by Windows NT/2000 to my knowledge.
• File Name (FN): This attribute stores a name associated with a file or directory. Note that a file or directory can have multiple file name attributes, to allow the storage of the “regular” name of the file, along with an MS-DOS short filename alias and also POSIX-like hard links from multiple directories. See here for more on NTFS file naming.
• Index Root Attribute: This attribute contains the actual index of files contained within a directory, or part of the index if it is large. If the directory is small, the entire index will fit within this attribute in the MFT; if it is too large, some of the information is here and the rest is stored in external index buffer attributes.
• Index Allocation Attribute: If a directory index is too large to fit in the index root attribute, the MFT record for the directory will contain an index allocation attribute, which contains pointers to index buffer entries containing the rest of the directory’s index information.
• Security Descriptor (SD): This attribute contains security information that controls access to a file or directory. Access Control Lists (ACLs) and related data are stored in this attribute. File ownership and auditing information is also stored here.
• Standard Information (SI): Contains “standard information” for all files and directories. This includes fundamental properties such as date/time-stamps for when the file was created, modified and accessed. It also contains the “standard” FAT-like attributes usually associated with a file (such as whether the file is read-only, hidden, and so on.)
• Volume Name, Volume Information, and Volume Version: These three attributes store key name, version and other information about the NTFS volume. Used by the $Volume metadata file.

Note: For more detail on how the attributes associated with files work, see the page on file storage; for directories, the page on directories.

In addition to these system defined attributes, NTFS also supports the creation of “user-defined” attributes. This name is a bit misleading, however, since the term “user” is really given from Microsoft’s perspective! A “user” in this context means an application developer–programs can create their own file attributes, but actual NTFS users generally cannot.

NTFS Reparse Points

One of the most interesting new capabilities added to NTFS version 5 with the release of Windows 2000 was the ability to create special file system functions and associate them with files or directories. This enables the functionality of the NTFS file system to be enhanced and extended dynamically. The feature is implemented using objects that are called reparse points.

The use of reparse points begins with applications. An application that wants to use the feature stores data specific to the application–which can be any sort of data at all–into a reparse point. The reparse point is tagged with an identifier specific to the application and stored with the file or directory. A special application-specific filter (a driver of sorts) is also associated with the reparse point tag type and made known to the file system. More than one application can store a reparse point with the same file or directory, each using a different tag. Microsoft themselves reserved several different tags for their own use.

Now, let’s suppose that the user decides to access a file that has been tagged with a reparse point. When the file system goes to open the file, it notices the reparse point associated with the file. It then “reparses” the original request for the file, by finding the appropriate filter associated with the application that stored the reparse point, and passing the reparse point data to that filter. The filter can then use the data in the reparse point to do whatever is appropriate based on the reparse point functionality intended by the application. It is a very flexible system; how exactly the reparse point works is left up to the application. The really nice thing about reparse points is that they operate transparently to the user. You simply access the reparse point and the instructions are carried out automatically. This creates seamless extensions to file system functionality.

In addition to allowing reparse points to implement many types of custom capabilities, Microsoft itself uses them to implement several features within Windows 2000 itself, including the following:

• Symbolic Links: Symbolic linking allows you to create a pointer from one area of the directory structure to the actual location of the file elsewhere in the structure. NTFS does not implement “true” symbolic file linking as exists within UNIX file systems, but the functionality can be simulated by using reparse points. In essence, a symbolic link is a reparse point that redirect access from one file to another file.
• Junction Points: A junction point is similar to a symbolic link, but instead of redirecting access from one file to another, it redirects access from one directory to another.
• Volume Mount Points: A volume mount point is like a symbolic link or junction point, but taken to the next level: it is used to create dynamic access to entire disk volumes. For example, you can create volume mount points for removable hard disks or other storage media, or even use this feature to allow several different partitions (C:, D:, E: and so on) to appear to the user as if they were all in one logical volume. Windows 2000 can use this capability to break the traditional limit of 26 drive letters–using volume mount points, you can access volumes without the need for a drive letter for the volume. This is useful for large CD-ROM servers that would otherwise require a separate letter for each disk (and would also require the user to keep track of all these drive letters!)
• Remote Storage Server (RSS): This feature of Windows 2000 uses a set of rules to determine when to move infrequently used files on an NTFS volume to archive storage (such as CD-RW or tape). When it moves a file to “offline” or “near offline” storage in this manner, RSS leaves behind reparse points that contain the instructions necessary to access the archived files, if they are needed in the future.

These are just a few examples of how reparse points can be used. As you can see, the functionality is very flexible. Reparse points are a nice addition to NTFS: they allow the capabilities of the file system to be enhanced without requiring any changes to the file system itself.

NTFS Security and Permissions

One of the most important advantages that you gain when choosing the NTFS file system over older file systems such as FAT, is much greater control over who can perform what sorts of operations on various data within the file system. FAT was designed in the era of single-user PCs, and contains virtually no built-in security or access management features. This makes it quite poorly-suited to multi-user business environments–can you imagine running a business where any user in the company was free to roam through the file system and open any documents he or she found? This is not a wise way to run a server! In contrast to FAT, NTFS offers a secure environment and flexible control over what can be accessed by which users, to allow for many different users and groups of users to be networked together, with each able to access only the appropriate data.

In this section I take a detailed look at NTFS’s security features and how they operate. I begin with a general discussion of NTFS security concepts. I then describe the various NTFS permissions and permission groups that can be assigned to various file system objects. I talk about ownership and how permissions are assigned, and also explain how the inheritance of permissions works, and how NTFS handles resolving multiple permission settings for the same object. Since Windows NT and Windows 2000 handle permissions differently I distinguish between their security models where appropriate.

Note: NTFS security and permission issues are to some degree inextricably linked to features and aspects of the operating system, and also touches upon issues related to Windows NT/2000 networking. A full discussion of Windows NT or Windows 2000 domains, directory services, groups, login procedures and so on is far beyond the scope of our coverage of NTFS. Therefore, I am attempting to limit myself to a description of how security works within NTFS itself–even in this attempt I have probably gone far too much into operating system details. I will not describe Windows NT/2000 security in general; you may wish to consult a broader NT/2000 reference if you need more detail on the operating system’s security, account management and access control features than I provide here. In fact, even NTFS permissions themselves can get very complicated, especially under Windows 2000 with its greater and more complex security settings. If you want to know all the ins and outs of controlling permissions you will want to consult a Windows NT or Windows 2000 operating system reference.

General NTFS Security Concepts

NTFS security is really only one part of a much bigger picture: security under Windows NT and 2000 in general. It’s no exaggeration to say that security is one of the most important aspects of these operating systems–period. Security, including controlling access to the system and its various resources, is a subject that gets a lot of attention in any NT or 2000 system. Managing security issues such as user accounts and groups is a big part of the job of any Windows NT or 2000 system administrator.

Security in NTFS, like security in the Windows NT or 2000 operating systems themselves, is oriented around the key concept of assigning rights to specific users or groups of users. Consider a network consisting of a Windows NT or Windows 2000 server, to which are connected various client machines in a network. Any user who sits down at one of these client machines can connect to the server computer, but he or she must log in to the server in order to access any of its resources, including NTFS volumes it contains. In fact, the same applies to someone who uses the server machine directly, again, assuming it has been correctly configured.

The manager of the server sets up user accounts for everyone who will use the network. He or she also sets up group accounts, to which are added lists of individual users. These groups are used to allow rights to be given to multiple users who share something in common; for example, they may all be in the same department or logical sub-unit in the organization. Someone who does not have a user account on the network may be allowed to use a guest account, but the rights assigned to such an account are generally quite minimal, for obvious reasons. If someone does not have even the guest account password, that person will quickly discover that they can do nothing on the server!

The access rights for files and directories on NTFS volumes are assigned based on these same user or group accounts. When a user logs in to a Windows NT or 2000 network, the account that is used becomes the key to what that person can access, including NTFS objects. By looking at the name of the account used to log in to the network, the system determines who the person is and also what groups the person is a member of, and assigns rights accordingly. A user can be a member of a number of different groups simultaneously (just like in “real life”). Several predefined groups are also set up in the system by default, which have specific access rights. One of these is the Administrators group, members of which have access to pretty much everything. Other groups that are set up depend on the specific role played by the computer: whether it is a domain controller for example. (Here we start to drift away from NTFS into NT/2000 generalities and networking, so I am going to stop. ;^) )

For example, consider a small company of 20 people, with a server that contains a variety of data. There may be a folder on the D: drive on this server called “D:\Budget”, which contains budgeting information for the company. This is sensitive data, which is only supposed to be accessible to the President and Vice-President of the company, and their Administrative Assistant. Under NTFS, this is easy to set up by assigning specific permissions to that folder for only those persons’ accounts. In fact, it is also easy to arrange the folder’s permissions so that, say, the President and Vice-President can read or modify files in the folder, but the Assistant can only read the files. All others in the company can be easily blocked from the folder entirely. A full discussion of how permissions work is provided on the pages describing NTFS permissions and standard permission groups.

There are three other important overall concepts in NTFS security: object ownership, permission inheritance and auditing. Ownership is a special property right for NTFS objects that gives file owners the capability of granting permissions to others. NTFS is also designed to propagate permissions down the hierarchy of the directory structure, under the control of the user. This permission inheritance feature allows permissions to be assigned to groups of objects automatically. It also allows permissions to be automatically applied to new files that are created within an existing directory structure. NTFS 5.0 extended the control that administrators and users have in dealing with permission inheritance. Finally, auditing allows administrators to monitor changes to files or directories.

Access Control Lists (ACLs) and Access Control Entries (ACEs)

Management of security and access to NTFS objects begins in the same place where everything else begins in NTFS: in the Master File Table (MFT). The MFT record for every file and directory on an NTFS volume contains a security descriptor (SD) attribute. The name of this attribute makes rather clear what it contains: information related to security and permissions for the corresponding object.

One of the most important elements within the security descriptor for any object is the set of lists within it, which dictate which users may access the object, and in what manner. These are called access control lists or ACLs. Every object in an NTFS partition has two different types of access control lists:

• System Access Control List (SACL): This ACL is managed by the system (thus the name) and is used to control auditing of attempts to access the object.
• Discretionary Access Control List (DACL): This is the “real” ACL. :^) Well, it is the one that most people are primarily concerned with, because it is where permissions are stored that control what users and groups of users are allowed what type of access to the object. If you hear someone refer to an object’s ACL in the singular, this is the one they mean.

Each entry in an ACL is called an access control entry or ACE. Each ACE contains an ID code that identifies the user or group to which the ACE applies, and then information about the specific permission settings that are to be applied to that user or group. Many different ACEs can be placed into a list, allowing the access of various types to be granted or denied for a variety of different users and groups. Some groups have special meaning, such as the self-evidently named group “Everyone”.

The ACL for every object is a combination of various access control settings contained in different ACEs. A typical object may have different sets of permissions assigned for various users or groups of users. In fact, some sets of permissions may conflict with each other, since users can be members of more than one group, and groups may have differing permissions. When an object is accessed, a process of permission resolution takes place, which determines which permissions take precedence and therefore, whether any given attempted access should be allowed or disallowed.

ACLs are also greatly affected by the particular inheritance model being used by the operating system. Windows NT uses a static inheritance model, which defaults the ACL for a new object from the ACL of its parent folder. Windows 2000 uses a more advanced dynamic inheritance scheme that provides better control over how the ACLs for an object work, lets subfolders and files have their ACLs change automatically when their parent folder’s ACL changes, and allows finer control over inheritance in general. This more advanced functionality can also be applied to Windows NT 4.0 installs using Service Pack 4 and the Security Configuration Manager (SCM).

NTFS Permissions

Access control lists (ACLs) are used to manage which users and groups of users are allowed to access different files and folders (objects) within NTFS volumes. These ACLs contains entries that specify what rights each user or group has for the object in question. These access rights are called permissions.

When Windows NT was built, six different permission types were created for NTFS objects. The NT user interface was designed to allow these permissions to be associated with objects. Each permission type controls a different kind of access to an object, and each has an abbreviation letter. These permission types are sometimes called special permissions, to differentiate them from standard permission groups that are applied at a higher level.

In some cases, the meaning of a permission is the same for both files and directories (folders); in others, the meaning is different, depending on if the permission is applied to a folder or a file. This table shows the different NT permissions and how they apply to folders and files:

Permission Type	Abbreviation Letter	Permission Granted For Files	Permission Granted For Folders
Read	R	Read file contents	Read folder contents
Write	W	Change file contents	Change folder contents (create new files or subfolders)
Execute	X	Execute (run) a program file	Traverse subfolder structures of folder
Delete	D	Delete file	Delete directory
Change Permissions	P	Change file’s permission settings	Change folder’s permission settings
Take Ownership	O	Take file ownership	Take folder ownership

Note: There is also one other fundamental permission type: Delete Subfolders and Files. This permission, when applied to a parent folder, allows a user to delete files and subfolders within it, even if they do not have delete permission on those files and subfolders. Under Windows NT this permission type cannot be individually applied to folders. It is only available as part of the “Full Control” standard permission group.

Until Windows 2000 was released, these six basic permissions were the lowest level that an NTFS user could access. When Windows 2000 was introduced, the six permission types above were “broken down” into 13 different permission components, to allow for more “fine-tuned” control over different kinds of access. While some people believe this “breaking down” was part of Windows 2000, in fact, these 13 components have always been present in NTFS! Under Windows NT, they were just hidden under the six permission types above. The table below lists the different permission components and shows how they correlate to the six Windows NT permission types:

Permission Components (Windows 2000 and Windows NT 4.0 SCM)	Permission Types (Windows NT)
Read (R)	Write (W)	Execute (X)	Delete (D)	Change Permissions (P)	Take Ownership (O)
Traverse Folder / Execute File
List Folder / Read Data
Read Attributes
Read Extended Attributes
Create Files / Write Data
Create Folders / Append Data
Write Attributes
Write Extended Attributes
Delete Subfolders and Files
Delete
Read Permissions
Change Permissions
Take Ownership

A few notes about this table:

• Some of the permission components are “combination” permissions; they are illustrated by having two different names, such as “Create Files / Write Data”. For these, the first term explains how the permission works when it is applied to a folder, and the second describes its application to a file. As the first table on this page shows, this sort of “double meaning” has been present since the start, but the new names just make it more explicit.
• Delete Subfolders and Files can now be applied as an individual permission to folders.
• There is actually a 14th permission component, called Synchronize. This permission is used to control synchronization of access to file or folder handles for multithreaded applications. It is sort of a “different bird” from the other permissions, which is why I mostly ignore it. :^)

As you can see, Windows 2000 gives you much more “granularity” of control over individual permissions. The Read, Write and Execute permissions have been broken down into several components. Of course, it’s pretty unusual for someone to really need control this fine over most objects. (For example, how often do you think you would want to give permission to someone to write data but not append data to a file? Not frequently.) In fact, even the six Windows NT “special permissions” are often more detail than is really necessary. For convenience, Windows provides several pre-defined standard permission groups to allow commonly-desired sets of permissions to be applied to files and folders quickly.

Tip: The finer permissions granularity introduced with Windows 2000 are also available to Windows NT 4.0 users who have installed Service Pack 4 or later, through the Security Configuration Manager (SCM).

Standard Permission Groups

Windows NT provides a set of six individual permissions for controlling access to files and folders. Windows 2000 refines these individual permissions even further, into a set of over a dozen different permission components. These NTFS permissions allow for fine control of the access rights of users and groups to NTFS objects, but in many cases they are “overkill”. To force administrators to always deal with these fine-grained permissions would be a time-consuming chore.

To avoid the necessity of always setting low-level permissions, Windows defines standard permission groups. These are simply collections of the low-level permissions that are given names and can be applied to objects. When you use a permission group, all the components contained in the group are applied to the object automatically.

First, let’s look at the standard permission groups for Windows NT:

Standard Permission Group	Object Types Affected	Permission Types Granted (Applies Only To Appropriate Object Types)	Description
Read (R)	Write (W)	Execute (X)	Delete (D)	Change Permissions (P)	Take Ownership (O)
No Access	Folders or Files							Denies all access to the file or folder. The user can see the name of the object, but cannot do anything with it.
List	Folders Only							Users can see the list of files in the folder and traverse subfolders, but cannot view or execute files.
Read	Folders or Files							Users can read files and folders, execute files and traverse folders, but cannot change anything.
Add	Folders Only							Users can add files or subfolders to the folder, and can traverse subfolders, but cannot read or execute files.
Add & Read	Folders Only							Users can add files or subfolders to the folder, and can read and execute files in the folder as well.
Change	Folders or Files							The user can read, write, execute or delete the file, or if applied to a folder, the files and subfolders within the folder. Note that this does not grant access to delete the folder itself. The user also cannot change permissions on the file or folder, or take ownership of it.
Full Control	Folders or Files							All permissions are granted. This also includes the special permission “Delete Subfolders and Files”, which can only be given through the “Full Control” group under Windows NT.

Well, that table is probably a bit overwhelming at first glance, but it’s not all that confusing if you consider it carefully. Under Windows NT, applying the permission group gives the users the permission types indicated by the checkmarks. Note that the checkmarks apply only to the object type specified. Of particular note, “Add & Read” grants the write permission to the folder, but not to the files contained within the folder. Also, the “No Access” group is a “trump card” of sorts; it will override other permission settings. See the discussions of permission settings and inheritance for more on how permission conflicts are addressed.

Under the more advanced Windows 2000 scheme, there are 13 different permission components, which are collected into six different standard groups, as the table below illustrates:

Permission Components (Windows 2000 and Windows NT 4.0 SCM)	Standard Permission Groups (Windows 2000 and Windows NT 4.0 SCM)
Read	Write	List Folder Contents	Read and Execute	Modify	Full Control
Traverse Folder / Execute File
List Folder / Read Data
Read Attributes
Read Extended Attributes
Create Files / Write Data
Create Folders / Append Data
Write Attributes
Write Extended Attributes
Delete Subfolders and Files
Delete
Read Permissions
Change Permissions
Take Ownership

Notes: “List Folder Contents” and “Read and Execute” have the same permission components, which is a bit confusing. The differences between them have to do with how NTFS handles inheritance of these permissions. “List Folder Contents” is only used for folders and is not inherited by files within the folder. “Read and Execute” applies to folders and files and is inherited by both. Also, the oddball, 14th permission component, “Synchronize”, is a member of all of the groups above.

You may notice, in looking at this table, that the “No Access” group is missing under the Windows 2000 scheme. In Windows NT, all permission groups except “No Access” provide “positive access”–saying, in effect, “you are allowed” to do something. “No Access” is the only one that says “you are not allowed” to do something. Unfortunately, it is very broad; it really says “you cannot do anything“. This inflexibility was corrected under Windows 2000 by giving users the ability to allow or disallow any permission group or individual permission. Under this setup, “No Access” simply isn’t required. See the discussion of permission assignment for more information on this.

Ownership and Permission Assignment

Permissions and permission groups control access to files and folders on NTFS volumes, but what controls who can assign permissions? Would you really be surprised if I told you that it was, in fact, other permissions? :^) Yes, that is indeed the case. These special permissions work in combination with another key NTFS security concept: ownership.

Every object within the NTFS volume has an owner, which is a user identified by the object as being the one who controls it. By default, the user who creates a file or folder becomes its owner. The significance of ownership is that the owner of a file or folder always has the ability to assign permissions for that object. The owner can decide what permissions should be applied to the object, controlling others’ access to the file or folder.

The two special permissions that are associated with ownership and permission assignment are “Change Permissions” (P) and “Take Ownership” (O). If a user is granted the “Change Permissions” permission, the user can change the permission settings for the object even if he or she does not own it. If a user has “Take Ownership” permission, the user has the ability to take over ownership of the resource, and of course, once it is owned the user can do anything he or she wants with the permissions. Both of these special permissions are most commonly granted through the standard permission group “Full Control”. Note that ownership of an object cannot be assigned or given away. The owner of the object can only give the right to others to take ownership. There’s an important but subtle distinction there. :^)

Deciding how to assign permissions to various files and folders is an important system administration task. Very careful thought needs to go into how user groups are created and permissions assigned to various objects. One common mistake that many administrators make is misusing the “No Access” permission group under Windows NT. If used incorrectly, this can lock everyone out of large areas of an NTFS volume. Problems can also occur if different users take ownership of files or change permissions when they should not–this is in fact the reason for the distinction between the “Full Control” permission group, and the slightly more restricted groups “Change” or “Modify”. One should be very careful when granting “Full Control” permission. Note that by default, members of the “Administrators” user group can always take ownership of, or change permissions on, any file or folder. This allows administrators to fix permission problems if they occur.

The mechanics of assigning permission are rather straight-forward. The most common method is to right-click an object in the Windows Explorer, select Properties, and then click the “Security” tab to access the permissions settings for the object. The exact way that permissions are assigned depends on whether you are using Windows NT or Windows 2000. Since I have already probably gone into far too much detail on permissions, I am not going to delve into the details on exactly how permissions are set. However, I do think it’s important to highlight that the NT and 2000 permissions models work differently in one fundamental respect.

Under Windows NT, there is really only one kind of permission assignment possible. Generally speaking, you can only “allow” users to do things. For example, you can allow someone read permission on a folder. By not granting the write permission as well, the system infers that the person may not write the folder. However, there is no way to explicit say “no write permission on this folder for this user”. The difference is important, because it has implications in multiple-level hierarchies of folders. The only way to disallow access to something in the Windows NT NTFS security model is to use the “No Access” permission group. This group will over-ride any “allow” permissions also defined for the object, and cut off access to the item for the user or group who is tagged with “No Access”. Unfortunately, this is a sledgehammer: it takes away all permissions. There is no way to explicitly select a folder and say “regardless of other permission settings and groups that User X may be in, X may not write any files in this folder”.

Windows 2000 greatly improved the control you have in assigning NTFS permissions by creating two explicit settings for each permission and permission group: allow and deny. Using these setting types, it is easy to specifically allow read access and deny write access to a file or folder, enabling the example I just mentioned above to be implemented. This improved control is also the reason why the “No Access” group does not exist in Windows 2000: it isn’t needed. Windows 2000 has specific rules for dealing with the various access and deny permission settings that may be set on objects or inherited by them, especially when they may conflict. See the discussion of advanced inheritance for more information on this.

Tip: Windows NT 4.0 users can gain the advantages of the Windows 2000 permission assignment method by installing Service Pack 4 or later and using the Security Configuration Manager (SCM).

Static Permission Inheritance

A typical NTFS volume will have thousands of folders and files on it–if not tens of thousands or hundreds of thousands. Can you imagine using such a volume, and being forced to assign permissions to all of those objects? Worse, can you imagine being the administrator of such a system? Well, I can, and it’s not a pretty sight. :^) Fortunately, the folks at Microsoft made NTFS so that you don’t have to worry about this sort of nightmare.

When you are using Windows NT and create a new subfolder or file within a folder, the new object is given a default set of permissions by copying the current set of permissions associated with the object’s parent folder. This is called permission inheritance, or sometimes, propagation. Under NT’s inheritance model, this only happens once, at the time the object is created. For this reason, conventional inheritance under NT is also called static permission inheritance, to distinguish it from the dynamic inheritance used by Windows 2000.

While static inheritance is certainly much better than no inheritance, it creates serious difficulties for administrators who need to manage large directory structures. Imagine a large tree structure of folders. Under static inheritance, after any subfolder is created, its permissions are no longer linked to those of the parent object. This makes it easy for any grouping or “branch” of the tree to have its permissions changed after the face. The administrators have no easy way to keep track of these changes or, in some cases, to even tell that they have occurred. Problems are particularly likely to occur if the “Full Control” permission group has been used, as this means users are free to play around with the permissions on parts of the directory structure. Also, the static inheritance makes it very difficult to add new permissions to an existing structure. Suppose you create a new user group and want to give everyone in that group access to an existing set of directories: how do you do it?

To address these concerns, Windows NT provides a special feature when permissions are being assigned. If you select the “Replace Permissions on Subdirectories” and “Replace Permissions on Existing Files” options when changing the permissions of a folder, NT will reset the permissions of all child objects to match those of the parent. So if you add a new user group and want to give it access to the existing structure, you can use these options to force NT to propagate the new permissions down the directory tree, giving the new user group access to every folder and file.

However, this solution has one very big problem with it: whenever you propagate permissions in this manner, you wipe out any custom permissions that may have been set on child objects. This makes it a very inelegant tool–a “permissions sledgehammer”, if you will. Now, if your aim is to address the deeds of adventurous users who have been playing with permissions, erasing permissions from subfolders and files may be exactly what you want. However, in many instances, resetting permissions in this way can lead to a disaster. You could have a document storage directory called “C:\Documents” on a server, with a tree containing dozens of subfolders belonging to different people, and permissions set to ensure only the appropriate users and groups can access the files they need. If you need to add a new user group and use the “Replace…” feature just once on “C:\Documents”, you will destroy all the customization on these child subfolders and files, an reduce them all to homogeneity.

Unfortunately, there’s no real way around this with Windows NT’s conventional inheritance scheme. In practice, it means that changes to the directory structure that require using the “Replace…” features must be done many more times, deeper within the directory structure, to avoid unwanted changes. The limitations of this system led to Microsoft’s creating the more advanced dynamic inheritance system in Windows 2000 (which is also available to Windows NT 4.0 users who install Service Pack 4.)

Dynamic Permission Inheritance and Advanced Inheritance Control

The static permission inheritance method used by Windows NT on NTFS volumes addresses some of the concerns involved in managing large directory structures, but also has some very serious weaknesses. It does not allow an administrator to easily customize the permissions of branches of a directory tree while also allowing the administrator to assign new permissions to an entire existing structure. To correct some of the problems with the static permission inheritance system, Microsoft replaced it with a dynamic permission inheritance system in Windows 2000.

The word “dynamic” in the name of this feature tells you much of what you need to know about it. When you create a subfolder or file in a Windows 2000 folder, the child object inherits the parent’s permissions, but remains linked to the parent. Furthermore, the parent’s permissions are stored separately from any permissions that are manually set on the child object. This dynamic linking method solves the two biggest problems with the static inheritance model. First, any changes to the parent folder are automatically inherited by the child objects. Second, any changes that were made to the child object are not destroyed by this automatic propagation. You get the best of both worlds.

Under dynamic inheritance, an administrator or user is able to manage a hierarchical tree of permissions that matches the hierarchical tree of directories. Since each child inherits permissions from its parent, when you set up a hierarchy of three or more levels of folders, the objects deep within the structure will inherit permissions from their parent, “grandparent”, “great grand-parent” and so on. This is called recursion.

As an example, consider the document folder “C:\Documents”. Generic permissions can be applied to this folder that will be automatically inherited by subfolders. At the next level down, say a sensitive folder for executive-level documents called “C:\Documents\Exec”, more specific permissions can be applied. And below that one, say in “C:\Documents\Exec\Payroll-Projections”, an even more restrictive set of permissions. The lowest level will have explicit permissions that were applied directly to the “Payroll-Projections” folder, plus some permissions that were inherited from “Exec” and some from “Documents”. If changes are later made to the highest-level folder, they will be passed down to “C:\Documents\Exec” automatically, and to “C:\Documents\Exec\Payroll-Projections” as well. However, the explicitly-set lower-level permissions will be retained.

In addition to this powerful dynamic inheritance feature, Windows 2000 offers several advanced inheritance control features that give the administrator more power over how inheritance works:

• Child Protection: The main security properties dialog box for each object contains a check box labeled “Allow inheritable permissions from parent to propagate to this object”. If the check in this box is cleared, this breaks the normal inheritance link between this child and its parent (and higher-level ancestors as well). When this is done, the child will no longer dynamically inherit permissions from higher up in the directory tree. Such a child object is said to be protected from inheritance changes.
• Object Selection Control: When changing permissions on a folder, you can choose if the permissions will be applied to any combination of the folder itself, files within it, or subfolders within it.
• Recursion Control: An option exists in the dialog box where individual permissions are assigned called “Apply these permissions to objects and/or containers within this container only”. The name of this option is horribly confusing. What it means is that, if selected, permissions you choose are applied only to the folder’s immediate children, but not lower-level objects. So if this were chosen as we selected a permission for the “C:\Documents” folder in the example above, changes would propagate to “C:\Documents\Exec” but not “C:\Documents\Exec\Payroll-Projections”, the item two levels down.
• Forced Propagation: An option called “Reset permissions on all child objects and enable propagation of inheritable permissions” is provided. This works the same way as the “Replace Permissions on Subdirectories” and “Replace Permissions on Existing Files” options from the older Windows NT static permission model. When selected, NTFS will force propagation down to all child objects and remove any permissions that were directly assigned to those child objects. This allows administrators to easily “fix” permission problems in large directory structures.

The downsides to dynamic inheritance and these advanced inheritance control features are few. One is increased complexity: the static permission model is much simpler to understand and apply conceptually, while the added functionality I have described above is more complicated. Another disadvantage of the new system is performance: dynamic inheritance requires more processing resources to deal with changes to files and folders, and to determine which permissions take precedence each time access to an object is attempted.. In fact, this extra overhead is likely one of the reasons that Microsoft chose static inheritance for Windows NT in the first place.

The complexity of the dynamic inheritance system also has an impact on how the system determines whether a given user is allowed a particular type of access to an object. Since child objects can have both explicitly-set and inherited permissions that may conflict, special rules had to be developed to resolve these permissions and determine which have priority.

Permission Resolution

Every time a user attempts a particular type of access to an object on NTFS, the system must determine if the access should be allowed. In theory, this is a simple matter of looking at the access control lists for the object, seeing what the permission settings are for the user, and determining if the desired access is allowed. Unfortunately, in reality, it’s not this simple. :^) Since every object can have many different permission settings, it is possible that several different permission settings might apply to a particular object and access method. Furthermore, it is possible that these permission settings might conflict. When this occurs, the system must engage in a process of resolving the various permissions to determine which ones should govern the access.

Under the Windows NT permissions scheme, inheritance is static, so there is no issue with multiple inherited permission settings. Conflicts can still occur, however, because a particular user can have a permission associated with his user account and also a group of which he or she is a member–or, he or she could be a member of more than one user group. For example, user John may have permissions allowing him read permission on a particular file called “Struct01.acd”. However, he may also be a member of the “Engineering” group, and that group may have both read and write access to that same file. There are two rules that are used for resolving permissions in the Windows NT scheme:

1. With the exception of the “No Access” permission group, Windows NT permissions are all “positive”–meaning, they grant permissions, rather than taking them away. Therefore, the more “inclusive” of the permission settings takes precedence. In the example above, John would be allowed read and write access on “Struct01.acd” because the permission he gains as a member of the “Engineering” group is more inclusive than the one he was granted personally.
2. The “No Access” permission group is the only one that has “negative” permissions–it denies access instead of giving it. As such, it is given special status: it trumps rule #1. If someone has “No Access” permission to an object, they are denied all access to the object regardless of any other permissions. So in the example above, if John was also a member of the “Accounting” group, and that group had “No Access” permissions for the file “Struct01.acd”, John would be totally out of luck, regardless of his other rights settings. This is the reason why “No Access” must be used very carefully!

Windows 2000 offers much better control over how permissions are assigned, as well as the benefits of dynamic inheritance and advanced inheritance control. However, these extra features make permission resolution much more complicated. In addition to the potential conflicts caused by users being in more than one user group, as above, you can have conflicts between permissions that were set for the object directly and those that were inherited from any of the object’s predecessors: its parent, grandparent and so on. Furthermore, the existence of both “allow” and “deny” permissions complicates matters further. To deal with these complexities, Windows 2000 uses an algorithm that follows these general rules:

1. “Deny” permissions take precedence over “allow” permissions.
2. Permissions applied directly to an object take precedence over permissions inherited from a parent object.
3. Permissions inherited from near relatives take precedence over permissions inherited from distant predecessors. So permissions inherited from the object’s parent folder take precedence over permissions inherited from the object’s “grandparent” folder, and so on.
4. Permissions from different user groups that are at the same level (in terms of being directly-set or inherited, and in terms of being “deny” or “allow”) are cumulative. So if a user is a member of two groups, one of which has an “allow” permission of “Read” and the other has an “allow” of “Write”, the user will have both read and write permission–depending on the other rules above, of course. :^)

The system combines these rules into a process that it uses to resolve various permission settings. Since directly-applied permissions take precedence over inherited ones, and “deny” permissions take precedence over “allow” permissions, it first looks for directly-set “deny” permissions, combining them all together for all groups the user is a member off. If it finds sufficient deny permission to refuse access, it is done–the access is refused. Otherwise, it looks at directly-set “allow” permissions. If it finds sufficient permission to allow access, the access is allowed. If not, it continues on; the sequence is as follows:

1. All directly-set “deny” permissions.
2. All directly-set “allow” permissions.
3. All “deny” permissions inherited from the parent.
4. All “allow” permissions inherited from the parent.
5. All “deny” permissions inherited from the grandparent.
6. All “allow” permissions inherited from the grandparent.
7. etc…

Well, this is certainly quite a bit more involved to explain than the NT permission resolution process–but that’s the price you pay for the much more capable system implemented in Windows 2000. It’s also not that difficult to understand once you get used to it. ;^) Here’s an example that may help you to understand what’s going on. Note that I am going to use only non-overlapping user groups to try to keep things somewhat manageable and not confuse you further. :^) Let’s suppose we have the following permissions set on a structure:

• For folder “C:\Documents”, group “Everyone” has an “allow” permission of “Read”.
• For folder “C:\Documents\Exec”, group “Employees” has a “deny” permission of “Modify”, groups “Exec” and “Top Exec” have “allow” permission of “Modify” and group “Assistants” has “allow” permission of “Write”.
• For folder “C:\Documents\Exec\Payroll-Projections”, group “Assistants” has “deny” permission of “Modify” and group “Exec” has “deny” permission of “Write”.

Every member of the company is a member of “Everyone”. All department managers and higher executives are members of group “Exec”, and their assistants are members of “Assistants”. All lower-level managers and workers are members of “Employees”. The president and vice-president are members of groups “Exec” and “Top Exec”. Now, consider the following access attempts:

• Randy, who is a member of “Employees”, tries to read a document in the “C:\Documents\Exec\Payroll-Projections” folder. There are no directly-set permissions that apply to him, but that folder inherits a “deny” on “Employees” from its parent. Randy will fail in his attempt.
• Jane, who is the director of Marketing and a member of “Exec”, tries to write a document in the “C:\Documents\Exec” folder. She will succeed because “Exec” has an “allow” permission of “Modify”.
• Jane tries to modify a payroll projection in the “C:\Documents\Exec\Payroll-Projections” folder. She will fail because “Exec” is denied permission to write in that folder. The directly-set deny takes precedence over the “allow” at the parent level.
• Lisa, who is the vice-president, attempts to modify a payroll projection in the “C:\Documents\Exec\Payroll-Projections” folder. She will succeed because “Top Exec” has not been denied at that folder level; it will inherit the “Top Exec” “allow” permission of “Modify” from the parent.

That probably isn’t the best of examples, but this page has already taken way too long to write, so it will have to do. :^) At any rate, it gives you an idea of the power you have with the Windows 2000 NTFS permissions system–and how much extra work the system has to do when it needs to figure out whether someone is allowed to do something with a particular file or folder.

Auditing

The biggest part of NTFS file system security revolves around controlling access to different types of objects. Obviously, it is quite important to deal with security in the present: managing what users are doing and ensuring that access is correct for various files and folders. However, there’s another important aspect to security that also deserves attention: keeping records of the past. There are many situations where it is essential for system administrators to be able to not only manage what security happenings are occurring immediately, but what they have been in recent days as well. To allow administrators and managers this capability, NTFS includes a feature called auditing.

When auditing is enabled, the system can be set to keep track of certain events. When any of these events occur, the system will make an entry in a special auditing log file that can be read by administrators or others with the appropriate permission level. Each entry will indicate the type of event, the date and time that it occurred, which user triggered the event, and other relevant information.

Auditing within NTFS is really just a small part of the various auditing features offered by the Windows NT and Windows 2000 operating systems. These tools allow administrators to keep track of everything from logins, to the use of printers, to system errors. Within NTFS, auditable events are generally accesses of various types, roughly corresponding to the different types of permissions. Auditing can be selected for files and for folders, and can be selected for individual objects or hierarchies of folders, just like permissions can.

NTFS Reliability Features and System Management

One of the biggest problems with the FAT file system is that it includes virtually no built-in reliability features. Anyone who has used FAT has likely experienced file system problems that have occurred as a result of the system crashing, or even operating system or application errors. While these problems can be corrected, they often result in a loss of data. In a business or high-performance computing environment, having the file system become corrupted on a regular basis is simply not acceptable. One of the most important design goals of NTFS was to make the file system more reliable. While reliability features may not be very exciting, they are of paramount importance to many NTFS users.

In this section I take a fairly comprehensive look at NTFS’s key reliability and system management characteristics. I begin with a discussion of NTFS’s recoverable file system features, including how its transaction-based system operates, and how it uses transaction logging to recover the file system if that becomes necessary. I then describe the change journal feature of NTFS. From there, I move on to talk about error correction and fault tolerance features, and finally, I talk a bit about fragmentation and defragmentation under NTFS.