随着时间的推移跟踪文件

Posted 2023-03-07

【中文标题】随着时间的推移跟踪文件

【英文标题】：Tracking a file over time

【发布时间】：2013-03-27 03:58:28

【问题描述】：

我的想法是在两个时间点T1 和T2 之间跟踪文件系统上的特定文件。这里的重点在于将文件视为文件系统上的唯一实体。一种可以更改数据和属性但仍保持其唯一身份的数据。

最终目标是通过在T1 捕获和记录文件的数据哈希和创建/修改属性来确定文件的数据是否（不情愿地）在T1 和T2 之间发生变化并将它们与T2 的等价物进行比较。如果所有属性都未更改但哈希未验证，我们可以说存在问题。在所有其他情况下，我们可能愿意说更改的散列是修改的结果，而未更改的散列和未更改的修改归因于文件（数据）根本没有更改的结果。

现在，有几种引用文件的方法和相应的缺点：

文件的路径：但是，如果将文件移动到其他位置，此方法将失败。 文件数据的数据散列：允许找到文件，或者更确切地说（a）指向磁盘上文件数据的指针，即使指针已移动到不同的位置目录，但数据无法更改或此方法也失败。

我的想法是在T1 检索该特定文件的fileId 以跟踪T2 上的文件，即使它已更改其位置，因此不需要将其视为新的 文件。

我知道 pywin 提供了两种方法。 win32file.GetFileInformationByHandle() 和 win32file.GetFileInformationByHandleEx()，但它们显然仅限于特定的文件系统，破坏了跨平台兼容性并偏离了跟踪文件的通用方法。

我的问题很简单：是否有任何其他想法/理论来跟踪文件，最好是跨平台/FS？

欢迎任何集思广益的思考！

【问题讨论】：

如何获取文件内容的 MD5 哈希值。并检查不同时间实例的 md5 哈希？

在 linux 文件系统上（ext 我猜），你有 inode，如果我没记错的话，它们在文件移动时会保持不变。但是，在 Windows 上...我不确定。这是个好问题。您可能必须编写一些特定于平台的代码，然后覆盖所有基础。

@SidharthShah：他报道了这一点。如果文件移动 并且 在 T1 和 T2 之间被修改，那么你就完蛋了。哈希会有所不同；您将无法再次找到该文件。

你可能需要做一些内核级别的事情，挂钩到移动文件和修改它们的任何东西，并在某处保留日志

@Mark：太好了，这听起来相当于 NTFS/FAT 上的 fileIndices（？）：GetFileInformationByHandleEx 允许您检索 nFileIndexLow 和 nFileIndexHigh，它唯一地标识了一个文件在单个封闭系统上与VolumeSerialNumber 组合。跟踪功能非常适合消除手动验证位置 A 中的文件 T1 是否与位置 B 中的文件 T1 相同，这将是一种不切实际的方法，尤其是在较大的文件树上。

【参考方案1】：

一般来说这不太可行，因为文件身份的概念是一种幻觉（类似于物理身份的幻觉，但这不是哲学论坛）。

您无法使用文件内容跟踪身份，因为内容会发生变化。

您无法通过附加到文件的任何其他属性进行跟踪，因为许多文件编辑器会通过删除旧文件并创建新文件来保存更改。

版本控制系统以三种方式处理此问题：

(CVS) 不跟踪移动操作。

（Subversion）手动跟踪移动操作。

(Git) 使用启发式方法将操作标记为基于文件内容更改的“移动”操作（例如，如果新文件与现有文件的差异小于 50%，则将其标记为作为副本）。

inode 编号等内容不稳定稳定且不可信。在这里，您可以看到使用 Vim 编辑文件会更改 inode 编号，我们可以使用 stat -f %i 进行检查：

$ 触摸文件.txt $ stat -f %i 文件.txt 4828200 $ vim 文件.txt ...对 file.txt 进行更改... $ stat -f %i 文件.txt 4828218

【讨论】：

很棒的答案，谢谢。我没有考虑的一个很好且实际上非常明显的一点是，许多应用程序将文件的数据重新写入一个新文件，从而删除了前者。有趣的是看看其他版本控制系统如何处理这个问题，我将研究 Git 的启发式方法，看看它是否可以应用于任意数据、文本以及二进制文件。从一开始，信任和依赖文件 ID/inode 似乎就有风险。