直接从文件系统获取文件校验和，而不是显式计算它答案

【问题标题】：Getting a file checksum directly from the filesystem instead of calculating it explicitly直接从文件系统获取文件校验和，而不是显式计算它
【发布时间】：2011-10-18 19:00:25
【问题描述】：

我猜一个典型的文件系统倾向于保留它管理的每个文件的某种校验和/CRC/哈希，因此它可以检测文件损坏。

你猜对了吗？如果是，有没有办法访问它？

我主要对 Windows 和 NTFS 感兴趣，但其他平台上的 cmets 也会受到欢迎...语言在这一点上并不重要，但我想尽可能避免使用汇编程序。

【问题讨论】：

没有。 CRC 检查是磁盘驱动器的工作。
@HansPassant 在块级别，当然。但是文件级别呢？
取决于操作系统和文件系统，这可能是真的......例如对于 ZFS（适用于 Sun、Linux 和 OSX）......无论如何，如果由文件系统计算/存储它通常是无法通过记录的 API 访问...要获得它，您通常需要深入挖掘并使用几个未记录的东西，在某些情况下需要特定权限（管理员、root 甚至内核模块/驱动程序）...通常很多比计算自己的校验和更麻烦……你的目标到底是什么？
@Yahia 是的，这就是我的想法，但我需要确认。如果文件系统已经“访问”了该内容并计算了校验和，则目标是通过避免文件内容的 I/O 来提高性能。
@BrankoDimitrijevic，性能下降是文件系统不尝试对硬件进行第二次猜测的一个很好的原因。

标签： windows file filesystems checksum ntfs

【解决方案1】：

好吧，看来我要问的是不可能的。

顺便说一句，这也在这里讨论过：There is in Windows file systems a pre computed hash for each file?

【讨论】：

【解决方案2】：

在大多数文件系统和存储硬件中，它们会保留allocation units 的校验和，而不是完整的文件。

一般来说，硬件中的校验和可能根本无法访问，并且文件系统集群的校验和在大多数情况下不会很有用，因此如果可能的话，很难获得。

【讨论】：

很遗憾没有某种哈希值，因为微软可以优化不替换相同的文件（相同的时间戳和哈希值）。
有一些文件系统可以实现这一点，尽管不能完全按照您的描述工作。 ZFS 是我最了解的，但总的来说这个策略叫做copy-on-write