通过$Bitmap元文件计算NTFS分区的使用空间大小

本文介绍了一种通过NTFS文件系统的$Bitmap元文件来计算分区自由空间的方法,并提供了具体的实现步骤及与XP系统显示结果的对比。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

       原创文章,转载请注明出处,谢谢!       
       作者:清林,博客名:飞空静渡

 

在我之前的一篇文章《如何获取NTFS卷的使用空间大小 》里说明了两张方式来获取NTFS文件系统下的分区的使用空间的大小的原理,这里,我将通过第一种方法即通过NTFS中的Bitmap元文件来计算整个分区使用空间的大小。

 

在《如何获取 NTFS卷的使用空间大小 》里说,在通过NTFS中的Bitmap元文件来计算整个分区使用空间的大小时,由于Bitmap不能完全表示到整个分区大小,因此有必要截取Bitmap文件,但我们可以通过Bitmap来计算自由空间大小就不需要截取Bitmap文件了,因为Bitmap中表示的超出分区的比特位都设置成1,这样分区就不会使用超出分区部分的空间,这样我们计算自由空间的大小就只计算0的部分就可以了。

 

下面,我通过一个程序来获取NTFS分区的自由空间大小,并把这个大小和XP系统下看到的分区的自由空间大小进行对比。

首先,我们读取分区的DBR,DBR位于分区的第一个扇区,这样我们就可以得到这个分区的信息,包括整个分区的大小。这个DBR结构是这样的(DBR结构来源于NTFS-3g代码并有修改):

 

这样我们就可以知道MFT的偏移位置了(mft_lcn变量)。

这样我们就可以读取第6个元文件(索引从0开始)也就是$Bitmap文件。我们获取$Bitmap文件的数据属性并获得其大小.

通过它的大小,我们可以读取整个$Bitmap文件的内容。

我们先初始化整个分区的自由空间大小为整个磁盘的大小,整个磁盘空间大小可以通过DRB来获得。

    long long nr_free = m_dwlTotalClusters;
然后我们检测我们的$Bitmap内容,如果为1,我们的nr_free就相应的减1,直到我们检测完$Bitmap的所有内容。

我通过ntfs_get_attribute_value(attr, buf)函数把$Bitmap的数据的非常驻属性的内容读取到buf中,然后通过一个for循环来计算整个分区的自由空间的大小。

下面是获取一个20G左右的NTFS分区的大小的情况,并和在XP下获得的大小进行对比。如下:


程序获得大小:

the partition total size is: 20974463488
the partition free size is: 20906041344

XP下:

 

下面是一个200M左右的NTFS分区大小的对比情况:

程序获得大小情况:

the partition total size is: 205599232
the partition free size is: 202801152

 

XP下获得大小情况:

 

我们看到,通过$Bitmap元文件获得的分区的自由空间大小和XP下获得的自由空间的大小是非常接近的,因此,我们在没有通过windows下的API的情况,通过计算NTFS文件系统中的$Bitmap就可以获得整个分区的自由空间的大小的了,这在Linux下,在不加载分区的情况下也可以通过这样的方式来获得分区的大小。

下次说明一下如何计算FAT32和FAT16分区的自由空间大小,这个的计算要比NTFS麻烦一些了。

 

 

<think>我们正在处理一个关于文件系统簇修复的问题。用户提到bitmap中标记为已使用但未被引用的簇(簇号36998893),询问如何修复。在文件系统中,bitmap用来跟踪哪些簇(或块)是已分配的(已使用),而文件系统的元数据(如FAT表、inode等)则记录了哪些文件使用了哪些簇。当一个簇被标记为已使用(在bitmap中),但没有被任何文件引用时,这就成为了一个“孤立的簇”,通常是由于不正确的操作(如程序崩溃、系统突然断电)导致文件系统元数据没有正确更新。修复方法:1.我们可以将这个簇标记为未使用(在bitmap中清除标记),这样文件系统就可以在将来重新使用它。但要注意,这个簇中可能包含有用的数据,如果直接清除,可能会导致数据丢失(如果这个簇原本属于某个文件,但文件系统元数据丢失了指向它的链接)。2.另一种方法是将这个簇中的数据保存为一个文件,这样用户就可以检查它是否包含有用的数据。这类似于文件系统检查工具(如Windows的chkdsk或Linux的fsck)所做的操作:将孤立的簇恢复为文件。具体步骤(以常见的FAT或NTFS文件系统为例,但具体操作取决于文件系统类型):由于我们不知道具体的文件系统类型,这里给出一般性建议:对于Windows系统:-使用内置工具:运行chkdsk命令,使用参数/f(修复错误)和/r(查找坏扇区并恢复可读信息)。chkdsk会扫描文件系统,将孤立的簇收集起来并转换为文件(扩展名为.chk),存放在根目录下。命令示例:`chkdsk C: /f`(假设该簇在C盘)-注意:运行chkdsk需要管理员权限,并且可能需要重启计算机。对于Linux系统(使用ext系列文件系统):-使用fsck工具。首先需要卸载文件系统(或者以只读方式挂载,或者使用live CD/USB),然后运行:`fsck -y /dev/sda1`#假设文件系统在/dev/sda1上fsck会将孤立的inode(对应于簇)放入lost+found目录(在文件系统根目录下)中。但是,用户可能希望直接操作这个特定的簇(簇号36998893)。直接操作文件系统数据结构通常需要专业的工具和深入的知识,因为错误的操作可能导致文件系统损坏。如果用户确实需要手动修复,可以考虑以下步骤(高级操作,风险高):1.备份整个分区或卷,以防止操作失败。2.使用十六进制编辑器或专门的文件系统操作工具(如Windows的WinHex,Linux的debugfs)来修改bitmap,将这个簇标记为未使用。例如,在ext文件系统中,可以使用`debugfs`:`debugfs-w/dev/sda1`#以读写模式打开在debugfs提示符下:`setb<block_number>`或`clrb <block_number>`来设置或清除位图中的位(注意簇号与块号的对应关系,通常簇号就是块号)。但是,对于簇号36998893,我们需要清除它在位图中的标记(标记为未使用)。命令可能是:`clrb36998893`3.注意:直接操作位图可能会忽略其他元数据(如FAT表或inode)的更新,因此仅清除位图可能不够(在FAT文件系统中,FAT表也需要更新)。所以,一般建议使用文件系统自带的修复工具。然而,更安全的方式是使用文件系统检查工具自动修复。因此,推荐用户使用chkdsk(Windows)或fsck(Linux)进行修复。如果用户想要恢复这个簇中的数据,那么使用chkdsk或fsck将孤立的簇恢复为文件是最佳选择。因此,针对簇36998893,我们可以这样操作:- Windows:运行chkdsk,它会将孤立的簇保存为文件(扩展名为.chk),用户可以在根目录下查找类似FILE0000.CHK的文件。-Linux:运行fsck后,在lost+found目录下会找到恢复的文件(文件名可能是数字)。注意:在执行任何修复操作前,强烈建议备份重要数据。最后,用户需要知道,直接指定修复某个簇(而不通过工具自动扫描)是不常见的。因为文件系统检查工具会扫描整个文件系统,修复所有错误。如果用户只想修复这一个簇,可能需要手动操作(但风险高,不推荐)。因此,我们推荐使用系统自带的文件系统检查工具。相关问题:1.如何运行chkdsk并修复磁盘错误?2.在Linux中如何使用fsck修复文件系统?3.什么是文件系统中的孤立簇?它们是如何产生的?4.手动修改文件系统位图有哪些风险?5.如何恢复由chkdsk生成的.chk文件中的数据?</think>### 修复文件系统中未引用的簇问题 当文件系统的位图(bitmap)标记某个簇(如簇号 36998893)为"已使用",但该簇未被任何文件引用时,这属于**孤立簇问题**。修复步骤如下: --- #### 1. **确认问题** - 使用文件系统检查工具扫描(如 Windows 的 `chkdsk` 或 Linux 的 `fsck`): ```bash chkdsk /f X: # Windows(X:为目标盘符) fsck /dev/sdX # Linux(/dev/sdX为目标分区) ``` - 工具会报告类似错误: > `36998893 clusters in orphaned chains` > `Orphaned cluster 36998893 will be saved as file FOUND.000/chk12345.chk` --- #### 2. **修复方法** - **自动修复(推荐)**: - 运行修复命令后,文件系统检查工具会: 1. 将孤立簇的数据保存为恢复文件(如 `FILEXXXX.CHK` 或 `found.XXXX`)[^1] 2. 在 bitmap 中将簇标记为**未使用**(释放空间) - 示例(Windows): ```bash chkdsk C: /f /r # /f 修复错误,/r 恢复数据 ``` - **手动修复(高级操作)**: - **步骤1**:定位簇的物理位置 簇号 → 物理扇区转换公式: $$ \text{物理扇区} = \text{簇号} \times \text{每簇扇区数} + \text{数据区起始扇区} $$ - **步骤2**:用磁盘编辑器(如 WinHex)检查簇内容 若数据无用,直接修改 bitmap 位: ```c // bitmap 伪代码(将第36998893位设为0) bitmap[36998893 / 8] &= ~(1 << (36998893 % 8)); ``` - **风险**:操作失误可能导致文件系统崩溃,需提前备份。 --- #### 3. **数据恢复** - 修复工具生成的恢复文件(如 `.CHK`)通常位于: - Windows:分区根目录的 `FOUND.XXX` 文件夹 - Linux:`/lost+found/` - 用十六进制编辑器或 `file` 命令检查文件类型: ```bash file FOUND.000/file1234.chk # Linux/Mac ``` --- #### 4. **预防措施** - **定期检查文件系统**: ```bash chkdsk /scan # Windows 后台扫描 fsck -n /dev/sdX # Linux 只读检查 ``` - **避免强制关机**:异常断电是孤立簇的主因 - **使用日志型文件系统**:如 NTFS/ext4 比 FAT32 更抗损坏 > ⚠️ **重要提醒**: > - 修复前**备份数据**(如用 `dd` 克隆磁盘) > - 勿在系统运行时修复系统分区(Windows 需重启,Linux 需卸载分区) --- ### 相关问题 1. 如何预防文件系统中出现孤立簇? 2. `chkdsk` 和 `fsck` 的工作原理有何区别? 3. 文件系统的 bitmap 管理机制是怎样的? 4. 数据恢复软件如何从 `.CHK` 文件中提取内容? 5. 簇大小设置如何影响文件系统性能? [^1]: Microsoft Docs, [CHKDSK 文档](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/chkdsk)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值