我昨天在做一些正式的测试。在他们的过程中,他们正在验证测试机器上的所有文件都是从版本中提取的。他们验证这些文件是否相同的方法是在 Windows 资源管理器中检查它们的大小和日期/时间戳窗口。这些碰巧因为另一个原因而关闭,我能够找出原因。
这是验证文件是否相同的有效方法吗?我不这么认为并开始争论,但我在这里更年轻,所以我认为我不应该把它推得太远。我想争辩说他们应该对文件进行二进制比较以验证其内容是否准确。根据我的经验,时间/日期戳和大小属性并不总是按预期运行。有什么想法吗???
确定两个文件是否相等的唯一 100% 方法是对两者进行二进制比较。
如果您可以忍受误报的风险(即两个文件不是 100% 相同,但您的代码说它们是相同的),那么可以使用摘要和校验和算法来减少工作量,特别是如果文件存在的话两台不同的机器的带宽低于最佳带宽,因此二进制比较是不可行的。
摘要和校验和算法都有误报的机会,但确切的机会因算法而异。一般规则是,加密越多,输出的比特越多,误报的可能性就越小。
甚至 CRC-32 算法也很好用,应该很容易在互联网上找到实现它的代码示例。
如果您只进行大小/时间戳比较,那么我很遗憾地说这很容易规避,并且实际上不会给您太多确定文件相同或不同的确定性。
但是,这取决于,如果您知道在您的世界中,时间戳被保留,并且仅在文件被修改时更改,那么您可以使用它,否则它无法保证。
哈希非常好。但另一个技术稍低的替代方法是运行 WinMerge 或 TextWrangler 之类的差异工具,并比较每个文件的两个版本。无聊,还有人为错误的余地。
最重要的是,使用版本控制来确保您正在测试的文件是您编辑的文件以及您将要启动的文件。我们将 repo 中的结帐文件夹作为暂存站点和实时站点,因此一旦您提交了工作副本中的更改,您就可以 100% 确定您测试、推送到暂存然后运行的文件是相同的,因为你只需在每个盒子上运行“svn update”并检查修订号。
哦,如果你需要快速回滚(它总是会发生在我们身上),你只需使用 -r 开关再次运行 svn update 并几乎立即返回到以前的版本。
我会对文件执行 md5sum 散列之类的操作,并将其与发行版中的已知散列进行比较。它们将比日期/时间比较更准确,并且应该能够更加自动化。