close
硬碟資料救援,RAID快速急救
網址:www.fubjj.com
NTFS是一個比[wiki]FAT[/wiki]複雜的多的檔案系統，我們一起努力來把它完整的解讀出來。
NTFS的引導[wiki]磁區[/wiki]也是完成引導和定義分區參數，和FAT分區不同，FAT分區的BOOT記錄正常，就顯示分區沒有錯誤，即使檔不正確，而NTFS分區的BOOT不是分區的充分條件，它要求必須MFT中的系統記錄如$MFT等正常該分區才能正常訪問。其BPB參數如下表所示。
[wiki]位元組[/wiki]偏移
長度
常用值
意義
0x0B
字
0x0002
每扇区字节数
0x0D
字节
0x08
每[wiki]簇[/wiki]扇区数
0x0E
字
0x0000
保留扇区
0x10
3字节
0x000000
总为0
0x13
字
0x0000
NTFS未使用，为0
0x15
字节
0xF8
介质描述
0x16
字
0x0000
总为0
0x18
字
0x3F00
每磁盘扇区数
0x1A
字
0xFF00
[wiki]磁头[/wiki]数
0x1C
双字
0x3F000000
隐含扇区
0x20
双字
0x00000000
NTFS未使用，为0
0x28
8字节
0x4AF57F0000000000
扇区总数
0x30
8字节
0x0400000000000000
$MFT的逻辑簇号
0x38
8字节
0x54FF070000000000
$MFTMirr的逻辑簇号
0x40
双字
0xF6000000
每MFT记录簇数
0x44
双字
0x01000000
每索引簇数
0x48
8字节
0x14A51B74C91B741C
卷标
0x50
双字
0x00000000
检验和
这些元数据文件是系统驱动程序管理卷所必需的，Windows
2000/XP给每个分区赋予一个盘符并不表示该分区包含有Windows
2000/XP可以识别的文件系统格式。如果主文件表损坏，那么该分区在Windows
2000/XP下是无法读取的。为了使该分区能够在Windows
2000/XP下能被识别，就必须首先建立Windows
2000/XP可以识别的文件系统格式即主文件表，这个过程可通过高级[wiki]格式化[/wiki]该分区来完成。Windows以簇号来定位文件在磁盘上的存储位置，在FAT格式的文件系统中，有关簇号的指针包含在FAT表中，在NTFS中，有关簇号的指针则包含在$MFT及$MFTMirr文件中。
NTFS使用逻辑簇号（Logical
Cluster
Number，LCN）和虚拟簇号（Virtual
Cluster
Number，VCN）来对簇进行定位。LCN是对整个卷中所有的簇从头到尾所进行的简单编号。用卷因子乘以LCN，NTFS就能够得到卷上的物理字节偏移量，从而得到物理磁盘地址。VCN则是对属于特定文件的簇从头到尾进行编号，以便于引用文件中的数据。VCN可以映射成LCN，而不必要求在物理上连续。
在NTFS卷上，跟随在BPB后的数据字段形成一个扩展BPB。这些字段中的数据使得
Ntldr能够在启动过程中找到主文件表MFT（Master
File
Tabl
）。在NTFS卷上，MFT并不象在FAT
16卷和FAT
32卷上一样，被放在一个预定义的扇区中。由于这个原因，如果在MTF的正常位置中有坏扇区的话，就可以把MFT移到别的位置。但是，如果该数据被破坏，就找不到MFT的位置，Windows
2000假设该卷没有被格式化。
因此，如果一个ntfs的卷提示未格式化，可能并未破坏MFT,依据BPB的各字段的意思是可以重建BPB的。
NTFS的缺省簇的大小
卷大小
每簇的扇区
缺省的簇大小
小于等于512MB
1
512字节
513MB~1024MB(1GB)
2
1024字节(1KB)
1025MB~2048MB(2GB)
4
2048字节(2KB)
大于等于2049MB
8
4KB
从上面可以看出，也就是说不管驱动器多大
NTFS
簇的大小不会超过
4KB
NTFS文档：文档属性定义
每个文档属性都由以下部分组成：
一个由该属性的实际值组成的被称为“流”的重要的字节序列，元数据可访问该流。
文件中的每个文件属性都可能会有一个名字：在这种情况下，在命令行方式下可以通过语法“文件名：属性名”来访问该流（这也是文件名中不能使用“：”的原因）。Windows
NT®
使用以下在元数据文件$AttrDef中预定义的文件属性列表（一般会有一个未命名流，为缺省流，未命名流只能有一个，而命名流可以有多个，NTFS支持多流文件）：
10
$STANDARD_INFORMATION
（标准信息）
20
$ATTRIBUTE_LIST
（属性列表）
30
$FILE_NAME
（文件名）
40
$VOLUME_VERSION
（卷版本）
50
$SECURITY_DEscriptOR
（安全描述符）
60
$VOLUME_NAME
（卷名）
70
$VOLUME_INFORMATION
（卷信息）
80
$DATA
（数据）
90
$INDEX_ROOT
（索引根）
A0
$INDEX_ALLOCATION
（索引分配）
B0
$BITMAP
（位图）
C0
$SYMBOLIC_LINK（符号链接）
D0
$EA_INFORMATION
（？信息）
E0
$EA
属性流结构
每个文件属性都分为两部分：尽管这两部分属性在文件记录的属性列表中以倒序方式进行记录,但是为了更好的理解它，让我们按下面的顺序进行介绍：
内容部分：
它的结构总是以属性名开始（N字节长），在属性名之后定义该属性是否为常驻属性。当文件属性的数据流就存储在其属性名后时，它就是常驻属性，这样，对于那些流较小且不会增长的文件属性就可以提供更佳的访问次数。如果一个文件属性是非常驻的，那么其流就存储在一个或多个扩展或称为运行中。运行是一个在逻辑簇号上连续的区域。为访问这些运行，NTFS紧跟在文件属性名后存储有一个称为运行列表的表。
头部：
从头部开始的偏移长度描述：
0
4
Type
（类型）
4
4
Length
（长度）
8
1
Non-resident
flag
（非常驻标志）
9
1
N=Name
length
（文件名长度）
A
2
Offset
to
the
content
part
（相对内容部分的偏移值）
C
2
Compressed
flag
（压缩标志）
E
2
Identificator
（标识）
文件名长度：
00
表示文件属性没有命名。
压缩标志:在NTFS中,数据压缩是在文件属性级别上实现的，这就意味着，如果出现意外，你也不会释放出很多的数据。这样，尽管只是对文件进行压缩，但压缩文件同时就意味着其属性数据也一样被压缩。从现在开始，
其头部的安排依赖文件的常驻属性：
对一个常驻属性来说，从头部开始的偏移描述如下：
10
4
Length
of
the
stream
（流长度）
14
2
Offset
to
the
stream
（流偏移）
16
2
Indexed
flag
（索引标志）
索引标志：
文件属性通过一个索引入口进行索引。
对于一个非常驻的文件属性，从头部开始的偏移描述如下：
10
8
Starting
VCN
（起始VCN）
18
8
Last
VCN
（结束VCN）
20
2
Offset
to
the
runlist
（运行列表偏移）
22
2?
Number
of
compression
engine
?
（压缩引擎号）
28
8
Allocated
size
of
the
stream
（为流分配的单元大小）
30
8
Real
size
of
the
stream
（实际的流大小）
38
8
Initialized
data
size
of
the
stream
（流已初始化大小）
VCN
：Virtual
Cluster
Number（虚拟簇号）的缩略词。VCN是一个与非常驻属性相关联的概念。VCN从文件属性流的第一个运行的第一个簇（VCN
0）到最后一个运行的最后一个簇进行编号。
当某个运行列表非常大，文件属性不能放在一个文件记录中时，描述文件的文件属性就会存储在几个文件记录中，运行列表也分成几个小片。起始VCN域和结束VCN域都用于定位其文件记录指示—即运行列表—运行所指定的VCN
。
注：如果属性可以放在一个文件记录内，则结束VCN域（这种情况下没有使用）可能是“00
00
00
00
00
00
00
00”。
压缩引擎的数量：
为达到最好的压缩比率，NTFS可以根据不同类型的数据使用不同的压缩引擎。当前的压缩引擎使用值04。
为流分配的单元大小：它几倍于卷上用来存储文件属性流所描述的分配空间。
如果流没有压缩，它就是数倍于簇空间大小的实际大小，相反，则比较小。
流的实际大小：
文件属性流在压缩前的大小。
流的初始化大小：
这是文件属性流的压缩后的大小（总是低于分配大小）。如果此流未被压缩，就是它的实际大小
。
注意:
常驻文件属性从不被压缩（也没有压缩引擎号域），因为它的流太小。
信息是足够的：名字长+内容部分的偏移值
=到流的偏移值(常驻属性)或者到运行列表的偏移值(非常驻悔改)。基隆市,台北市,台北縣,桃園縣,新竹縣,新竹市,苗栗縣,台中縣,台中市,彰化縣,南投縣,雲林縣,嘉義縣,嘉義市,台南縣,台南市,高雄縣,高雄市,屏東縣,澎湖,金門,馬祖,中國大陸,From InToHard
網址:www.fubjj.com
NTFS是一個比[wiki]FAT[/wiki]複雜的多的檔案系統，我們一起努力來把它完整的解讀出來。
NTFS的引導[wiki]磁區[/wiki]也是完成引導和定義分區參數，和FAT分區不同，FAT分區的BOOT記錄正常，就顯示分區沒有錯誤，即使檔不正確，而NTFS分區的BOOT不是分區的充分條件，它要求必須MFT中的系統記錄如$MFT等正常該分區才能正常訪問。其BPB參數如下表所示。
[wiki]位元組[/wiki]偏移
長度
常用值
意義
0x0B
字
0x0002
每扇区字节数
0x0D
字节
0x08
每[wiki]簇[/wiki]扇区数
0x0E
字
0x0000
保留扇区
0x10
3字节
0x000000
总为0
0x13
字
0x0000
NTFS未使用，为0
0x15
字节
0xF8
介质描述
0x16
字
0x0000
总为0
0x18
字
0x3F00
每磁盘扇区数
0x1A
字
0xFF00
[wiki]磁头[/wiki]数
0x1C
双字
0x3F000000
隐含扇区
0x20
双字
0x00000000
NTFS未使用，为0
0x28
8字节
0x4AF57F0000000000
扇区总数
0x30
8字节
0x0400000000000000
$MFT的逻辑簇号
0x38
8字节
0x54FF070000000000
$MFTMirr的逻辑簇号
0x40
双字
0xF6000000
每MFT记录簇数
0x44
双字
0x01000000
每索引簇数
0x48
8字节
0x14A51B74C91B741C
卷标
0x50
双字
0x00000000
检验和
这些元数据文件是系统驱动程序管理卷所必需的，Windows
2000/XP给每个分区赋予一个盘符并不表示该分区包含有Windows
2000/XP可以识别的文件系统格式。如果主文件表损坏，那么该分区在Windows
2000/XP下是无法读取的。为了使该分区能够在Windows
2000/XP下能被识别，就必须首先建立Windows
2000/XP可以识别的文件系统格式即主文件表，这个过程可通过高级[wiki]格式化[/wiki]该分区来完成。Windows以簇号来定位文件在磁盘上的存储位置，在FAT格式的文件系统中，有关簇号的指针包含在FAT表中，在NTFS中，有关簇号的指针则包含在$MFT及$MFTMirr文件中。
NTFS使用逻辑簇号（Logical
Cluster
Number，LCN）和虚拟簇号（Virtual
Cluster
Number，VCN）来对簇进行定位。LCN是对整个卷中所有的簇从头到尾所进行的简单编号。用卷因子乘以LCN，NTFS就能够得到卷上的物理字节偏移量，从而得到物理磁盘地址。VCN则是对属于特定文件的簇从头到尾进行编号，以便于引用文件中的数据。VCN可以映射成LCN，而不必要求在物理上连续。
在NTFS卷上，跟随在BPB后的数据字段形成一个扩展BPB。这些字段中的数据使得
Ntldr能够在启动过程中找到主文件表MFT（Master
File
Tabl
）。在NTFS卷上，MFT并不象在FAT
16卷和FAT
32卷上一样，被放在一个预定义的扇区中。由于这个原因，如果在MTF的正常位置中有坏扇区的话，就可以把MFT移到别的位置。但是，如果该数据被破坏，就找不到MFT的位置，Windows
2000假设该卷没有被格式化。
因此，如果一个ntfs的卷提示未格式化，可能并未破坏MFT,依据BPB的各字段的意思是可以重建BPB的。
NTFS的缺省簇的大小
卷大小
每簇的扇区
缺省的簇大小
小于等于512MB
1
512字节
513MB~1024MB(1GB)
2
1024字节(1KB)
1025MB~2048MB(2GB)
4
2048字节(2KB)
大于等于2049MB
8
4KB
从上面可以看出，也就是说不管驱动器多大
NTFS
簇的大小不会超过
4KB
NTFS文档：文档属性定义
每个文档属性都由以下部分组成：
一个由该属性的实际值组成的被称为“流”的重要的字节序列，元数据可访问该流。
文件中的每个文件属性都可能会有一个名字：在这种情况下，在命令行方式下可以通过语法“文件名：属性名”来访问该流（这也是文件名中不能使用“：”的原因）。Windows
NT®
使用以下在元数据文件$AttrDef中预定义的文件属性列表（一般会有一个未命名流，为缺省流，未命名流只能有一个，而命名流可以有多个，NTFS支持多流文件）：
10
$STANDARD_INFORMATION
（标准信息）
20
$ATTRIBUTE_LIST
（属性列表）
30
$FILE_NAME
（文件名）
40
$VOLUME_VERSION
（卷版本）
50
$SECURITY_DEscriptOR
（安全描述符）
60
$VOLUME_NAME
（卷名）
70
$VOLUME_INFORMATION
（卷信息）
80
$DATA
（数据）
90
$INDEX_ROOT
（索引根）
A0
$INDEX_ALLOCATION
（索引分配）
B0
$BITMAP
（位图）
C0
$SYMBOLIC_LINK（符号链接）
D0
$EA_INFORMATION
（？信息）
E0
$EA
属性流结构
每个文件属性都分为两部分：尽管这两部分属性在文件记录的属性列表中以倒序方式进行记录,但是为了更好的理解它，让我们按下面的顺序进行介绍：
内容部分：
它的结构总是以属性名开始（N字节长），在属性名之后定义该属性是否为常驻属性。当文件属性的数据流就存储在其属性名后时，它就是常驻属性，这样，对于那些流较小且不会增长的文件属性就可以提供更佳的访问次数。如果一个文件属性是非常驻的，那么其流就存储在一个或多个扩展或称为运行中。运行是一个在逻辑簇号上连续的区域。为访问这些运行，NTFS紧跟在文件属性名后存储有一个称为运行列表的表。
头部：
从头部开始的偏移长度描述：
0
4
Type
（类型）
4
4
Length
（长度）
8
1
Non-resident
flag
（非常驻标志）
9
1
N=Name
length
（文件名长度）
A
2
Offset
to
the
content
part
（相对内容部分的偏移值）
C
2
Compressed
flag
（压缩标志）
E
2
Identificator
（标识）
文件名长度：
00
表示文件属性没有命名。
压缩标志:在NTFS中,数据压缩是在文件属性级别上实现的，这就意味着，如果出现意外，你也不会释放出很多的数据。这样，尽管只是对文件进行压缩，但压缩文件同时就意味着其属性数据也一样被压缩。从现在开始，
其头部的安排依赖文件的常驻属性：
对一个常驻属性来说，从头部开始的偏移描述如下：
10
4
Length
of
the
stream
（流长度）
14
2
Offset
to
the
stream
（流偏移）
16
2
Indexed
flag
（索引标志）
索引标志：
文件属性通过一个索引入口进行索引。
对于一个非常驻的文件属性，从头部开始的偏移描述如下：
10
8
Starting
VCN
（起始VCN）
18
8
Last
VCN
（结束VCN）
20
2
Offset
to
the
runlist
（运行列表偏移）
22
2?
Number
of
compression
engine
?
（压缩引擎号）
28
8
Allocated
size
of
the
stream
（为流分配的单元大小）
30
8
Real
size
of
the
stream
（实际的流大小）
38
8
Initialized
data
size
of
the
stream
（流已初始化大小）
VCN
：Virtual
Cluster
Number（虚拟簇号）的缩略词。VCN是一个与非常驻属性相关联的概念。VCN从文件属性流的第一个运行的第一个簇（VCN
0）到最后一个运行的最后一个簇进行编号。
当某个运行列表非常大，文件属性不能放在一个文件记录中时，描述文件的文件属性就会存储在几个文件记录中，运行列表也分成几个小片。起始VCN域和结束VCN域都用于定位其文件记录指示—即运行列表—运行所指定的VCN
。
注：如果属性可以放在一个文件记录内，则结束VCN域（这种情况下没有使用）可能是“00
00
00
00
00
00
00
00”。
压缩引擎的数量：
为达到最好的压缩比率，NTFS可以根据不同类型的数据使用不同的压缩引擎。当前的压缩引擎使用值04。
为流分配的单元大小：它几倍于卷上用来存储文件属性流所描述的分配空间。
如果流没有压缩，它就是数倍于簇空间大小的实际大小，相反，则比较小。
流的实际大小：
文件属性流在压缩前的大小。
流的初始化大小：
这是文件属性流的压缩后的大小（总是低于分配大小）。如果此流未被压缩，就是它的实际大小
。
注意:
常驻文件属性从不被压缩（也没有压缩引擎号域），因为它的流太小。
信息是足够的：名字长+内容部分的偏移值
=到流的偏移值(常驻属性)或者到运行列表的偏移值(非常驻悔改)。基隆市,台北市,台北縣,桃園縣,新竹縣,新竹市,苗栗縣,台中縣,台中市,彰化縣,南投縣,雲林縣,嘉義縣,嘉義市,台南縣,台南市,高雄縣,高雄市,屏東縣,澎湖,金門,馬祖,中國大陸,From InToHard
全站熱搜
留言列表
