读取超级块
我知道在 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
既然您提到了 Mac OS X,我们假设您只想针对 HFS+ 执行此操作。 Wikipedia 页面 提供了一些有关可能的启动方式的信息,例如,它说的是关于- 磁盘布局:
之后事情变得更加复杂。 例如,阅读 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:
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?
查找已删除的文件会遇到相当大的麻烦,因为当您删除文件时,磁盘上没有多少剩余空间可供查找。
如果删除 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.