Removed the 'doc' directory from ntfsprogs.

It contains interesting information but this information is available elsewhere and we want to stay as close to ntfs-3g as possible. No unnecessary added files.
This commit is contained in:
Erik Larsson 2010-12-15 13:06:16 +01:00
parent 7fbfe73dda
commit d35be909a4
14 changed files with 1 additions and 611 deletions

View File

@ -24,7 +24,7 @@ MAINTAINERCLEANFILES=\
$(srcdir)/m4/lt~obsolete.m4 \
$(srcdir)/m4/ltoptions.m4
SUBDIRS = doc include libfuse-lite libntfs-3g ntfsprogs src
SUBDIRS = include libfuse-lite libntfs-3g ntfsprogs src
doc_DATA = README

View File

@ -459,7 +459,6 @@ fi
# generate files
AC_CONFIG_FILES([
Makefile
doc/Makefile
include/Makefile
include/fuse-lite/Makefile
include/ntfs/Makefile

View File

@ -1,2 +0,0 @@
Makefile
Makefile.in

View File

@ -1,24 +0,0 @@
The standard K&R coding style is used in this project and the guidelines
outlined in the Linux kernel CodingStyle document (found in the latest Linux
kernel main directory in Documentation/CodingStyle) should be adhered to as
strictly as possible.
Special notes:
Capitals are used when declaring NTFS on-disk structures which you
can't just go ahead modifying without getting killed (in a bug sense,
not literally...). In memory structures are named with lower case as
usual.
For styles that are not explicitly defined in the document or in the
kernel one, check/read the kernel and/or libntfs source. Some parts
of the kernel might use unwanted coding styles but usually, e.g.
linux/kernel/*
has what Linus prefers/writes and most developers follow.
The latest Linux kernel contains the script Lindent in the scripts/
directory which formats the source the most preferred way. Moreover,
the below patch will be applied to the official kernel tree as well:
http://lkml.org/lkml/2004/1/30/180
Check indent(1) for what the used/unused (default) parameters mean.

View File

@ -1,12 +0,0 @@
EXTRA_DIST = \
CodingStyle \
attribute_definitions \
attributes.txt \
compression.txt \
template.c \
template.h \
tunable_settings \
system_files.txt \
system_security_descriptors.txt
MAINTAINERCLEANFILES = Makefile.in

View File

@ -1,129 +0,0 @@
/* All values are as in Windows NT4 SP6a. */
__u16 name[64] = "$STANDARD_INFORMATION"
__u32 type = 0x10
__u32 unknown[2] = 0, 0
__u32 flags = 0x40
__u64 min_size = 0x30
__u64 max_size = 0x30, in Win2k: 0x48
__u16 name[64] = "$ATTRIBUTE_LIST"
__u32 type = 0x20
__u32 unknown[2] = 0, 0
__u32 flags = 0x80
__u64 min_size = 0
__u64 max_size = -1
__u16 name[64] = "$FILE_NAME"
__u32 type = 0x30
__u32 unknown[2] = 0, 0
__u32 flags = 0x42
__u64 min_size = 0x44
__u64 max_size = 0x242
/* The $volume_version attribute has never been observed in the field. It
* probably never was used and was hence replaced by the $object_id in
* Windows 2000. */
__u16 name[64] = "$VOLUME_VERSION" in Win2k: "$OBJECT_ID"
__u32 type = 0x40
__u32 unknown[2] = 0, 0
__u32 flags = 0x40
__u64 min_size = 0x8 in Win2k: 0
__u64 max_size = 0x8 in Win2k: 0x100
__u16 name[64] = "$SECURITY_DESCRIPTOR"
__u32 type = 0x50
__u32 unknown[2] = 0, 0
__u32 flags = 0x80
__u64 min_size = 0
__u64 max_size = -1
__u16 name[64] = "$VOLUME_NAME"
__u32 type = 0x60
__u32 unknown[2] = 0,0
__u32 flags = 0x40
__u64 min_size = 0x2
__u64 max_size = 0x100
__u16 name[64] = "$VOLUME_INFORMATION"
__u32 type = 0x70
__u32 unknown[2] = 0, 0
__u32 flags = 0x40
__u64 min_size = 0xc
__u64 max_size = 0xc
__u16 name[64] = "$DATA"
__u32 type = 0x80
__u32 unknown[2] = 0, 0
__u32 flags = 0
__u64 min_size = 0
__u64 max_size = -1
__u16 name[64] = "$INDEX_ROOT"
__u32 type = 0x90
__u32 unknown[2] = 0, 0
__u32 flags = 0x40
__u64 min_size = 0
__u64 max_size = -1
__u16 name[64] = "$INDEX_ALLOCATION"
__u32 type = 0xa0
__u32 unknown[2] = 0,0
__u32 flags = 0x80
__u64 min_size = 0
__u64 max_size = -1
__u16 name[64] = "$BITMAP"
__u32 type = 0xb0
__u32 unknown[2] = 0, 0
__u32 flags = 0x80
__u64 min_size = 0
__u64 max_size = -1
/* The $symbolic_link attribute has never been observed in the field. It
* probably never was used and was hence replaced by the $reparse_point in
* Windows 2000. */
__u16 name[64] = "$SYMBOLIC_LINK" in Win2k: "$REPARSE_POINT"
__u32 type = 0xc0
__u32 unknown[2] = 0, 0
__u32 flags = 0x80
__u64 min_size = 0
__u64 max_size = -1 in Win2k: 0x4000
__u16 name[64] = "$EA_INFORMATION"
__u32 type = 0xd0
__u32 unknown[2] = 0, 0
__u32 flags = 0x40
__u64 min_size = 0x8
__u64 max_size = 0x8
__u16 name[64] = "$EA"
__u32 type = 0xe0
__u32 unknown[2] = 0, 0
__u32 flags = 0
__u64 min_size = 0
__u64 max_size = 0x10000
/*
* Sequence terminates here with a record all of whose fields are zero, even
* though the size of the $AttrDef data attribute is much larger (36000 bytes,
* i.e. in theory 225 attribute definitions of 160 bytes each but in practice
* only until we reach an all zero record).
*
* The following only applies to Windows 2000 and replaces the above comment.
*/
__u16 name[64] = "$LOGGED_UTILITY_STREAM"
__u32 type = 0x100
__u32 unknown[2] = 0, 0
__u32 flags = 0x80
__u64 min_size = 0
__u64 max_size = 0x10000
/*
* This is terminated by a single record all of whose fields are zero. This
* also finishes the $AttrDef data attribute, i.e. the attribute size is the
* correct size of the sequence of attribute definitions (2560 bytes, i.e.
* 16 attribute definitions of 160 bytes each).
*/

View File

@ -1,111 +0,0 @@
Notes on the storage of attributes.
===================================
Resident attributes
===================
Resident attributes are small enough to be stored in the mft record itself.
When an attribute becomes too big to fit in the mft record or when the number
of attributes grows so large that there is no more space in the mft record, the
largest attribute(s) is(are) made non-resident. (Note, that some attributes
cannot be non-resident.)
Non-resident attributes
=======================
Non-resident attributes contain only their non-resident attribute header in the
mft record and the actual attribute value is stored anywhere on the volume
(but not in other mft records).
The value of the attribute is saved as a sequence of clusters, named virtual
clusters, beginning at virtual cluster number (vcn) zero. Each vcn corresponds
to a cluster on the volume, or a logical cluster number (lcn). The lcns on the
volume begin with lcn zero for the very first cluster on the volume.
The location of the attribute value is described by the mapping pairs array
present in the non-resident attribute header structure. The mapping pairs array
contains, in compressed form, the mapping between the attribute's vcns and the
corresponding lcns on the volume.
When the mapping pairs array of a non-resident attribute becomes too large to
fit in the mft record or when there are so many attributes in the mft record
that, even though all attributes that can be non-resident have been made
non-resident, they still do not fit in the mft record, the larger non-resident
attributes are moved away from the mft record to make space.
This is done by moving whole non-resident attribute header structures to other
mft records and/or by splitting the mapping pairs array of attributes into
several non-resident attribute headers, each containing a chunk of the
original mapping pairs array. These non-resident attribute headers each
describing the same attribute value (but different parts of it) are called
extents.
Attribute list attribute
========================
The attribute list attribute is then added to the base mft record to describe
the location of each attribute.
The attribute list attribute lists all attributes that belong to this mft
record (with the exception of itself). Each entry in the attribute list
describes the attribute listed and in which mft record its attribute header can
be found. For resident attributes this will be the same number as the base mft
record in which the attribute list attribute is located itself. For non-resident
attributes, this will be another mft record, called an extension mft record.
Naturally, all extension mft records point back to their base mft record.
Only one attribute is stored in an extension mft record, even if the attribute
is very small. At least this is the case with Windows NT4 SP6a driver.
Should the mapping pairs array of an attribute become so large as to not fit
into an extenstion mft record, even though its attribute is the only attribute
in this extension record, then the attribute is splitt into several extents.
The first extent starts at vcn 0 and has its lowest vcn value set to zero and
continues up to its highest vcn value. This is determined by splitting up the
mapping pairs array into chunks which just fit into an extension mft record
each. Thus the first mapping pairs array chunk will determine the value of
the highest vcn for the first extent. The attribute list will contain an entry
for this extent. Then, a second extent is created which has its lowest vcn
value set to the highest vcn of the previous extent + 1 and the next chunk of
the mapping pairs array is inserted into this extent. Again, an entry for this
extent is placed into the attribute list, and so on, until the whole
non-resident attribute's mapping pairs array has been accomodated.
Should the attribute list become too big to fit inside the base mft record it
is made non-resident. However, it's maximum value size is determined by the
Windows cache manager to be 256kb (the size of a VACB). Also, the mapping pairs
array of the attribute list has to fit inside the base mft record, as an
attribute list can't be described by itself and attribute lists are not allowed to be nested.
Compressed attributes
=====================
The attribute value of each $DATA attribute can be compressed to save space.
If this is the case, the ATTR_IS_COMPRESSED flag is set.
See the discussion on compression in include/attrib.h for more details.
FIXME: The discussion belongs here! (AIA)
Sparse attributes (NTFS 3.0+)
=============================
The attribute value of each $DATA attribute can be sparse to save space.
If this is the case, the ATTR_IS_SPARSE flag is set. Note, that compressed
attributes are by definition sparse, as well as compressed, without having the
ATTR_IS_SPARSE flag set.
See the discussion on compression in include/attrib.h for more details.
FIXME: The discussion belongs here! (AIA)
Encrypted attributes (NTFS 3.0+)
================================
Since NTFS 3.0, the attribute value of each $DATA attribute can be encrypted,
to protect the contents from spying eyes. If this is the case, the
ATTR_IS_ENCRYPTED flag is set.
FIXME: Write notes on attribute encryption. The discussions from the articles
"Inside the Encrypting File System" in Windows NT magazine (?) are very good
starting points. (AIA)

View File

@ -1,153 +0,0 @@
Description of the NTFS (de)compression algorithm (based on a modified LZ77
algorithm)
Copyright (c) 2001 Anton Altaparmakov
This document is published under the GNU General Public License.
Credits: This is based on notes taken from various places (most notably from
Regis Duchesne's NTFS documentation and from various LZ77 descriptions) and
further refined by looking at a few compressed streams to figure out some
uncertainties.
Note: You should also read the runlist description with regards to compression
in linux-ntfs/include/layout.h. Just search for "Attribute compression".
FIXME: Should merge the info from there into this document some time.
Compressed data is organized in logical "compression" blocks (cb). Each cb has
a size (cb_size) of 2^compression_unit clusters. In all versions of Windows,
NTFS (NT/2k/XP, NTFS 1.2-3.1), the only valid compression_unit is 4, IOW, each
cb is 2^4 = 16 clusters in size.
We detect and warn about a compression_unit != 4 but we try to decompress the
data anyway.
Compression is only supported for cluster sizes between 512 and 4096. Thus a
cb can be between 8 and 64kiB in size.
Each cb is independent of the other cbs and is thus the minimal unit we have
to parse even if we wanted to decompress only one byte.
Also, a cb can be totally uncompressed and this would be indicated as a sparse
cb in the runlist.
Thus, we need to look at the runlist of the compressed data stream, starting
at the beginning of the first cb overlapping @page. So we convert the page
offset into units of clusters (vcn), and round the vcn down to a mutliple of
cb_size clusters.
We then scan the runlist for the appropriate position. Based on what we find
there, we decide how to proceed.
If the cb is not compressed at all, and covers the whole of @page, we pretend
to be accessing an uncompressed file, so we fall back to what we do in
aops.c::ntfs_file_readpage(), i.e. we do:
return block_read_full_page(page, ntfs_file_get_block);
If the cb is completely sparse, and covers the whole of @page, we can just
zero out @page and complete the io (set @page up-to-date, unlock it, and
finally return 0).
In all other cases we initiate the decompression engine, but first some more
on the compression algorithm.
Before compression the data of each cb is further divided into 4kiB blocks, we
call them "sub compression" blocks (sb), each including a header specifying
its compressed length. So we could just scan the cb for the first sb
overlapping @page and skip the sbs before that, or we could decompress the
whole cb injecting the superfluous decompressed pages into the page cache as a
form of read ahead (this is what zisofs does for example).
In either case, we then need to read and decompress all sbs overlapping @page,
potentially having to decompress one or more other cbs, too.
As soon as @page is completed we could either stop or continue until we finish
the current cb, injecting pages as we go along (again following the zisofs
example).
Because the sbs follow each other directly, we need to actually read in the
whole cb in order to be able to scan through the cb to find the first sb
overlapping @page, so it does make sense to follow the zisofs approach of
decompressing the whole cb and injecting pages as we go along. So all
discussion from now on will assume that we are going to do that. Although it
might make sense not to decompress any sbs locate before @page because this
would be a kind of "read-behind" which is probably silly, unless someone is
reading the file backwards. Performing read-ahead by decompressing all sbs
following @page OTOH, is very likely to be a good idea.
So, we read the whole cb from disk and start at the first sb.
As mentioned above, each sb is started with a header. The header is 16 bits of
which the lower twelve bits (i.e. bits 0 to 11) are the length (L) - 3 of the
sb (including the two bytes for the header itself, or L - 1 not counting the
two bytes for the header). The higher four bits are set to 1011 (0xb) by the
compressor for a compressed block, or to 0000 for an uncompressed block, but
the decompressor only checks the most significant bit taking a 1 to signify a
compressed block, and a 0 an uncompressed block.
So from the header we know how many compressed bytes we need to decompress to
obtain the next 4kiB of uncompressed data and if we didn't want to decompress
this sb we could just seek to the next next one using the length read from the
header. We could then continue seeking until we reach the first sb overlapping
@page.
In either case, we will reach a sb which we want to decompress.
Having dealt with the 16-bit header of the sb, we now have length bytes of
compressed data to decompress. This compressed stream is further split into
tokens which are organized into groups of eight tokens. Each token group (tg)
starts with a tag byte, which is an eight bit bitmap, the bits specifying the
type of each of the following eight tokens. The least significant bit (LSB)
corresponds to the first token and the most significant bit (MSB) corresponds
to the last token.
The two types of tokens are symbol tokens, specified by a zero bit, and phrase
tokens, specified by a set bit.
A symbol token (st) is a single byte and is to be taken literally and copied
into the sliding window (the decompressed data).
A phrase token (pt) is a pointer back into the sliding window (in bytes),
together with a length (again in bytes), starting at the byte the back pointer
is pointing to. Thus a phrase token defines a sequence of bytes in the sliding
window which need to be copied at the current position into the sliding window
(the decompressed data stream).
Each pt consists of 2 bytes split into the back pointer (p) and the length (l),
each of variable bit width (but the sum of the widths of p and l is fixed at
16 bits). p is at least 4 bits and l is at most 12 bits.
The most significant bits contain the back pointer (p), while the least
significant bits contain the length (l).
l is actually stored as the number of bytes minus 3 (unsigned) as anything
shorter than that would be at least as long as the 2 bytes needed for the
actual pt, so no compression would be achieved.
p is stored as the positive number of bytes minus 1 (unsigned) as going zero
bytes back is meaningless.
Note that decompression has to occur byte by byte, as it is possible that some
of the bytes pointed to by the pt will only be generated in the sliding window
as the byte sequence pointed to by the pt is being copied into it!
To give a concrete example: a block full of the letter A would be compressed
by storing the byte A once as a symbol token, followed by a single phrase
token with back pointer -1 (p = 0, therefore go back by -(0 + 1) bytes) and
length 4095 (l=0xffc, therefore length 0xffc + 3 bytes).
The widths of p and l are determined from the current position within the
decompressed data (cur_pos). We don't actually care about the widths as such
however, but instead we want the mask (l_mask) with which to AND the pt to
obtain l, and the number of bits (p_shift) by which to right shift the pt to
obtain p. These are determined using the following algorithm:
for (i = cur_pos, l_mask = 0xfff, p_shift = 12; i >= 0x10; i >>= 1) {
l_mask >>= 1;
p_shift--;
}
Note, that as usual in NTFS, the sb header, as well as each pt, are stored in
little endian format.

View File

View File

@ -1,41 +0,0 @@
System files mft record numbers. All these files are always marked as used
in the bitmap attribute of the mft; presumably in order to avoid accidental
allocation for random other mft records. Also, the sequence number for each
of the system files is always equal to their mft record number and it is
never modified. (Only $MFT has a sequence number of 1, rather than 0.)
FILE_$MFT = 0, /* Master file table (mft). Data attribute
contains the entries and bitmap attribute
records which ones are in use (bit==1). */
FILE_$MFTMirr = 1, /* Mft mirror (copy of first four mft records)
in data attribute. */
FILE_$LogFile = 2, /* Journalling log in data attribute. */
FILE_$Volume = 3, /* Volume name attribute and volume information
attribute (flags and ntfs version). Windows
refers to this file as volume DASD (Direct
Access Storage Device). */
FILE_$AttrDef = 4, /* Array of attribute definitions in data
attribute. */
FILE_$root = 5, /* Root directory. */
FILE_$Bitmap = 6, /* Allocation bitmap of all clusters (lcns) in
data attribute. */
FILE_$Boot = 7, /* Boot sector (always at cluster 0) in data
attribute. */
FILE_$BadClus = 8, /* Contains all bad clusters in the non-resident
data attribute. */
FILE_$Secure = 9, /* Shared security descriptors in data attribute
and two indexes into the descriptors.
Appeared in Windows 2000. Before that, this
file was named $Quota but was unused. */
FILE_$UpCase = 10, /* Uppercase equivalents of all 65536 Unicode
characters in data attribute. */
FILE_$Extend = 11, /* Directory containing other system files (eg.
$ObjId, $Quota, $Reparse and $UsnJrnl). This
is new to NTFS3.0. */
FILE_reserved12 = 12, /* Reserved for future use (records 12-15). */
FILE_reserved13 = 13,
FILE_reserved14 = 14,
FILE_reserved15 = 15,
FILE_first_user = 16, /* First user file, used as test limit for
whether to allow opening a file or not. */

View File

@ -1,33 +0,0 @@
$SD attribute value for the system files on an NTFS 1.2 volume:
$MFT, $MFTMirr, $LogFile, $AttrDef, $Bitmap, $Boot, $BadClus, and $UpCase:
sd: 1, 0, 0x8004, 0x00000048, 0x00000058, 0x00000000, 0x00000014;
sd.dacl.acl: 2, 0, 0x0034, 0x0002, 0x0000;
sd.dacl.acl.ace1: 0, 0, 0x0014, 0x00120089;
sd.dacl.acl.ace1.sid: 1, 1, 0, 0, 0, 0, 0, 5, 0x00000012;
sd.dacl.acl.ace2: 0, 0, 0x0018, 0x00120089;
sd.dacl.acl.ace2.sid: 1, 2, 0, 0, 0, 0, 0, 5, 0x00000020, 0x00000220;
sd.owner.sid: 1, 2, 0, 0, 0, 0, 0, 5, 0x00000020, 0x00000220;
sd.group.sid: 1, 2, 0, 0, 0, 0, 0, 5, 0x00000020, 0x00000220;
$Volume, $Quota, and system files 0xb-0xf:
sd: 1, 0, 0x8004, 0x00000048, 0x00000058, 0x00000000, 0x00000014;
sd.dacl.acl: 2, 0, 0x0034, 0x0002, 0x0000;
sd.dacl.acl.ace1: 0, 0, 0x0014, 0x0012019f;
sd.dacl.acl.ace1.sid: 1, 1, 0, 0, 0, 0, 0, 5, 0x00000012;
sd.dacl.acl.ace2: 0, 0, 0x0018, 0x0012019f;
sd.dacl.acl.ace2.sid: 1, 2, 0, 0, 0, 0, 0, 5, 0x00000020, 0x00000220;
sd.owner.sid: 1, 2, 0, 0, 0, 0, 0, 5, 0x00000020, 0x00000220;
sd.group.sid: 1, 2, 0, 0, 0, 0, 0, 5, 0x00000020, 0x00000220;
. (root directory)
sd: 1, 0, 0x8004, 0x00000030, 0x00000040, 0x00000000, 0x00000014;
sd.dacl.acl: 2, 0, 0x001c, 0x0001, 0x0000;
sd.dacl.acl.ace1: 0, 3, 0x0014, 0x001f01ff;
sd.dacl.acl.ace1.sid: 1, 1, 0, 0, 0, 0, 0, 1, 0x00000000;
sd.owner.sid: 1, 2, 0, 0, 0, 0, 0, 5, 0x00000020, 0x00000220;
sd.group.sid: 1, 2, 0, 0, 0, 0, 0, 5, 0x00000020, 0x00000220;

View File

@ -1,47 +0,0 @@
const char *EXEC_NAME = "";
const char *EXEC_VERSION= "0.0.1";
/*
* EXEC_NAME - Part of the Linux-NTFS project.
*
* Copyright (c) 2000-2004 Anton Altaparmakov
*
* Short description here.
*
* Anton Altaparmakov <aia21@cantab.net>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program (in the main directory of the Linux-NTFS distribution
* in the file COPYING); if not, write to the Free Software Foundation,
* Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
/*
* WARNING: This program might not work on architectures which do not allow
* unaligned access. For those, the program would need to start using
* get/put_unaligned macros (#include <asm/unaligned.h>), but not doing it yet,
* since NTFS really mostly applies to ia32 only, which does allow unaligned
* accesses. We might not actually have a problem though, since the structs are
* defined as being packed so that might be enough for gcc to insert the
* correct code.
*
* If anyone using a non-little endian and/or an aligned access only CPU tries
* this program please let me know whether it works or not!
*
* Anton Altaparmakov <aia21@cantab.net>
*/
int main(int argc, char **argv)
{
return 0;
}

View File

@ -1,26 +0,0 @@
/*
* NAME.h - Description. Part of the Linux-NTFS project.
*
* Copyright (c) 2000-2004 Anton Altaparmakov
*
* This program/include file is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as published
* by the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program/include file is distributed in the hope that it will be
* useful, but WITHOUT ANY WARRANTY; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program (in the main directory of the Linux-NTFS
* distribution in the file COPYING); if not, write to the Free Software
* Foundation,Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#ifndef NTFS_NAME_H
#define NTFS_NAME_H
#endif /* defined NTFS_NAME_H */

View File

@ -1,31 +0,0 @@
The following settings can be tuned in Windows NT in the registry under the key
\Registry\Machine\System\CurrentControlSet\Control\FileSystem.
NtfsDisable8dot3NameCreation default is to enable 8.3 creation
NtfsAllowExtendedCharacterIn8dot3Name default is to disallow extended chars
NtfsDisableLastAccessUpdate default is enable the last acc. update
__u32 NtfsMftZoneReservation:
If not present set the variable _NtfsMftZoneMultiplier to 1.
If = 0 or > 4, again set the variable _NtfsMftZoneMultiplier to 1.
Otherwise, set the variable _NtfsMftZoneMultiplier to the value of
NtfsMftZoneReservation.
Value = Space % of volume reserved for MftZone
1 = 12.5%
2 = 25%
3 = 37.5%
4 = 50%
The zone multiplier is ONLY read accessed when mount_volume is called and
when deallocate_clusters is called.
The zone multiplier is ONLY write accessed when the driver initializes.
Win2k adds:
NtfsQuotaNotifyRate ?
NtfsEncryptionService ?