读取超级块

发布于 2024-07-09 22:32:32 字数 144 浏览 13 评论 0原文

我知道在 Unix(特别是 Mac OS X)中,超级块存储有关磁盘上数据布局的信息,包括 inode 开始和结束的磁盘地址。 我想扫描程序中的索引节点列表以查找已删除的文件。 如何找到 inode 开始的磁盘地址? 我查看了 statfs 命令,但它没有提供此信息。

I know that in Unix (specifically, Mac OS X) the superblock stores information about the layout of data on the disk, including the disk addresses at which the inodes begin and end. I want to scan the list of inodes in my program to look for deleted files. How can I find the disk address at which the inodes begin? I have looked at the statfs command but it does not provide this information.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

紧拥背影 2024-07-16 22:32:32

既然您提到了 Mac OS X,我们假设您只想针对 HFS+ 执行此操作。 Wikipedia 页面 提供了一些有关可能的启动方式的信息,例如,它说的是关于- 磁盘布局:

卷的扇区 0 和 1 是 HFS 引导块。 它们与 HFS 卷中的引导块相同。 它们是 HFS 包装器的一部分。

扇区 2 包含相当于 HFS 卷中主目录块的卷标头。 卷标头存储有关卷本身的各种数据,例如分配块的大小、指示卷创建时间的时间戳或其他卷结构(例如目录文件或范围溢出文件)的位置。 卷标头始终位于同一位置。

分配文件跟踪哪些分配块是空闲的以及哪些分配块正在使用。 它类似于HFS中的Volume Bitmap,每个分配块由一位表示。 零表示该块空闲,一表示该块正在使用。 与 HFS 卷位图的主要区别在于,分配文件作为常规文件存储,它不占用卷开头附近的特殊保留空间。 分配文件还可以更改大小,并且不必连续存储在卷中。

之后事情变得更加复杂。 例如,阅读 B* 树

我不是 Mac OS 用户,但如果还没有编写用于扫描已删除文件的工具,我会感到惊讶,也许有些工具是开源的,可以提供更具体的起点?

Since you mention Mac OS X, let's assume you mean to do this for HFS+ only. The Wikipedia page provides some information about possible ways to start, for instance it says this about the on-disk layout:

Sectors 0 and 1 of the volume are HFS boot blocks. These are identical to the boot blocks in an HFS volume. They are part of the HFS wrapper.

Sector 2 contains the Volume Header equivalent to the Master Directory Block in an HFS volume. The Volume Header stores a wide variety of data about the volume itself, for example the size of allocation blocks, a timestamp that indicates when the volume was created or the location of other volume structures such as the Catalog File or Extent Overflow File. The Volume Header is always located in the same place.

The Allocation File which keeps track of which allocation blocks are free and which are in use. It is similar to the Volume Bitmap in HFS, each allocation block is represented by one bit. A zero means the block is free and a one means the block is in use. The main difference with the HFS Volume Bitmap, is that the Allocation File is stored as a regular file, it does not occupy a special reserved space near the beginning of the volume. The Allocation File can also change size and does not have to be stored contiguously within a volume.

It becomes more complicated, after that. Read up on B* trees, for instance.

I'm no Mac OS user, but it would surprise me if there weren't already tools written to scan for deleted files, perhaps some are open source and could provide a more concrete starting point?

静若繁花 2024-07-16 22:32:32

查找已删除的文件会遇到相当大的麻烦,因为当您删除文件时,磁盘上没有多少剩余空间可供查找。

如果删除 FAT(或 UDF)文件系统上的文件,其目录条目只会被标记为“已删除”,而大部分目录条目仍然完好无损。

在 HFS 卷上,由于使用 B 树,删除的编辑必须从目录中删除,否则搜索项目将无法更有效地工作(好吧,这个论点可能有点弱,但事实是已删除的条目会被删除并被覆盖)。

因此,除非删除是通过意外写入目录扇区或通过重新初始化卷来进行的,否则您不会发现太多内容。

You'll have quite some trouble to find deleted files because there's not much left on the disk to find when you delete a file.

If you delete a file on a FAT (or UDF) file system, its directory entry simply gets marked as "deleted", with most of the dir entry still intact.

On HFS volumes, due to their use of B-Trees, deleted edits must be removed from the directory or else searching for items wouldn't work any more efficiently (well, this argument may be a bit weak, but fact is that deleted entries get removed and overwritten).

So, unless the deletion took place by writing over a directory sector by accident, or by re-initializing the volume, you'll not find much.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文