作为两部分博客系列文章的第二部分，我们将继续探讨数据管理的概念。在第一篇文章中，我们已经确定了成功的数据管理有两个方面： “最重要的目标之一[……]是保持拍摄过程中记录和创建的所有数据的完整性和完全性”。因此，第一篇文章探讨了如何通过计算和比较哈希值来保持单个文件的完整性，现在我们继续讨论完全性方面的问题，包括清单文件。
数据的完全性
谈到 “完全性”，我们可以区分两个层面： 首先，我们需要确保每个单独的数据管理流程或活动（如备份一张摄影机数据卡）都是完全的[1]。但有时，此类活动会集中在一起，我们需要确保整批活动或流程的完全性（例如，确保拍摄当天所有摄影机数据卡备份的完全性）。我们将看到，这两个层面都有不同的挑战。因此，让我们从第一个层面开始。
单一活动的完全性
假设需要备份一批文件。我们将一个软件指向包含我们要复制文件的文件夹，从而开始这个过程。然后，开始将文件逐个复制到新的目的地。如果一切顺利，希望复制过程能保证完全性，即只有当所有文件都被成功写入目的地后，软件才会停止。
如果拷贝进程在没有通知的情况下中止或失败，只看一眼目标文件夹并不能确定其中一个子文件夹中，是否丢失了一个（或多个）文件。这就需要进行更彻底的检查，通常包括对目标和源文件进行比较。即使是在最不容易管理的工作流程中，也可以通过比较源文件夹和目标文件夹的整体大小，或比较文件夹中的文件数量来发现这些未被发现的不完整进程。
多个活动的完全性
现在，让我们来看看将多个活动组合在一起创建一个新文件 “包 “的情况。几乎每个拍摄日都会有一个典型的例子：
在一天的拍摄过程中，多张摄影机数据卡会被装载到一个移动硬盘中。音频数据卡、报告、布景照片、转码样片等其他文件也会添加到移动硬盘中。因此，即使单个装载或复制最终完成，如何确保旅行驱动器上不会丢失整个文件夹？即使每张卡都复制成功了，你也需要在某个地方记录这些数字。该移动硬盘上应该有 8 张还是 9 张数据卡？
“为什么会出问题” – 以及如何发现问题
第一层完全性（一个装载或备份流程的完全性）是最重要的。如果我们无法检查一个进程是否已成功完成，且所有复制的文件仍然存在，我们就谈不上将此类进程进行分组。
如果您确实发现了问题，流程不完整的原因可能是多方面的：
- 电源问题：不仅是计算机，需要单独供电的外部设备也可能会断电（如电缆跳闸、振动导致插头松动等）。这些设备可能是读卡器系统或外部目标磁盘驱动器。
- 源读取错误：当读取卡上的错误数据块时，可能会发生读取错误。这会导致文件系统挂起或超时。
- 其中一个拷贝目的地出现写入错误：与故障块问题相同，但有时也会因为 “卷上剩余空间不足 “等基本原因而出错。即使软件在进程开始时检查空间是否足够，其他系统也可能在进程运行时向同一目标写入内容（例如，在拷贝运行时，转码器正在向目标盘写入内容）。
- 一致性检查出错： 根据软件的运行或设置方式，如果出现哈希值错误，程序可能会停止运行。
- 其他资源问题：虽然拷贝进程不需要太多内存，但如果没有剩余内存，除了中止，也没有其他办法了。例如，如果其他占用内存的进程正在运行，我们的数据管理进程可能无法再将源文件中的数据加载到内存中。
为了检测此类问题，数据管理软件需要确保在稍后的时间里，可以很容易地发现进程是否暂停、中止，或者是否在中间某个地方失败了。依靠软件本身的结果状态并不总是足够的，因为在下面的某些情况下（如内存耗尽），软件无法再可靠地工作，可能会在无法将错误写入日志的情况下退出。
解决办法是在进程结束时创建一个 “收据”，其中包括进程试图处理的文件列表。如果收据丢失，我们就知道出错了。如果收据存在，我们就可以通过文件列表检查处理结果是否还存在。当数据包中缺少一个或多个单独数据管理活动的结果时，就会出现第二级的不完全性。
通常，这不是技术原因，而是组织管理的原因造成的：
- 设备混淆：摄影机数据卡的错误放置或标签错误会导致摄影机数据机卡无法拷贝。
- 处理进程未启动：有时，一切都已准备就绪，但进程却没有启动。这种情况可能发生在用户分心，忘记启动装载，离开后再回来，却以为拷贝已经完成。
- 目的地错误：拷贝需要到达正确的目的地；否则，虽然发生了一些事情，但结果却在你期望的地方不见了。这种情况可能发生在将文件夹拖放到 Finder 中的其他文件夹时，而释放鼠标按钮时目的地没有突出显示。
- 沟通错误：在有压力的情况下一起工作时，事情可能会被误解（”你启动了吗？- “是的！” ……但这句话对每个人的意义都不一样）。
这些问题超出了软件的范围，但良好的管理仍有助于发现这些情况（例如，将硬盘内容与其他信息源（如摄影机报告）进行比较，并在格式化硬盘前对摄影机数据卡进行两次或更多次的交叉检查）。
考虑到所有这些因素，仍有一个问题是需要避免的 – 尽管在拍摄日结束时将文件归类并不属于实际数据管理人员的工作范围：
在未来的数据管理流程中丢失文件夹：即使您确保离开片场的移动硬盘是完全的，但以后将移动硬盘的内容复制到公司的文件服务器的过程也可能失败。但在公司里，没有摄影机数据卡或其他源文件的提示贴纸可供比对。为了让同事们能够在将来发现不完整的内容，最初拷贝的内容清单可以再次解决这个问题，因为你提供了一些能够在需要时进行内容比对的信息。
总之，我们看到，确保完全性不是一蹴而就的任务，尤其是在电影制作的媒体工作流程中。文件和文件夹会被多次复制、移动、备份和存档，因此完全性涵盖的范围远远超出了电影拍摄现场的那一份拷贝。
为了确保所有这些后续活动的完全性，我们需要从期望相关内容存在的那一刻起就记录下应该存在的东西。这意味着完全性始终是从源头开始考虑的。让我们仔细看看这对我们的数据管理活动意味着什么。
使用清单来实现完全性
对于检测未完成的活动，提供一个简单的文件列表可能已经是一个很好的解决方案。我们列出了文件夹中应存在的所有文件，便于随时检查。
如果我们还考虑到完整性的问题，那么文件列表也将是存储每个文件哈希值的理想场所。你所选择的操作系统很有可能已经为这样的列表提供了工具。例如，md5 命令会输出文件名和文件的 MD5 哈希值。
类似示例如下所示：
% md5 A001C006_141024_R2EC.mov
MD5 (A001C006_141024_R2EC.mov) = 52d29e6b6fe711e08effb93588c2cee6对于多个文件，该命令的结果可能就是我们的 “带哈希值的文件列表”：
% md5 *
MD5 (A001C006_141024_R2EC.mov) = 52d29e6b6fe711e08effb93588c2cee6
MD5 (A001C019_141024_R2EC.mov) = 91684b6ccbd27ac14712dcb11b6095e6
MD5 (A001C024_141024_R2EC.mov) = 4900c8b11b22b328b21e396f3a95759c在早期的数字电影拍摄中，这样的列表实际上经常被用作文件夹中的文件列表，记录完全性（文件夹中的文件列表）和一致性（每个文件的文件哈希值）。听起来 md5 命令满足了我们的所有需求，对吗？让我们仔细看看，了解一下典型应用的限制和额外要求。首先，让我们将 md5 命令指向一个存有文件的文件夹：
% md5 A001R2EC/
md5: A001R2EC: Is a directory
真遗憾，这不能直接用于文件夹结构[2]。通常情况下，我们需要处理更复杂的文件夹结构，因此我们的清单应该明确涵盖这一点。
此外，使用这种方法，我们不知道应该有哪些文件： 如果在两个文件之后终止 md5 命令，进程就会停止，列表看起来就像只有两个文件。没有任何迹象表明源文件应该有十个文件。清单文件
因此，好的数据管理软件应该知道源文件的内容，并以此为基础列出文件清单。如果有什么进程终止或失败了，就可以很容易地发现丢失了什么内容。
在 Pomfort 的 Silverstack 和 Offload Manager 应用程序中，这是通过所谓的清单文件来实现的。这些文件与我们上面看到的简单文件类似，但语法更加结构化，并包含更多针对媒体工作流程的信息。这些清单文件通常采用经典的 “MHL”（”媒体哈希列表 “的缩写）格式，或使用 “ASC MHL “格式，这是一种由 ASC（美国电影摄影师协会）制定的改进型格式。
这两种格式同样包含以相对路径和文件哈希值形式出现的文件列表。软件在完成所有文件的拷贝后才会写入这些清单文件，因此在拷贝中止或失败时，不会保留清单的不完整中间状态，从而避免导致完全性的检查范围出现错误。
为上述文件制作的 ASC MHL 清单文件的部分内容摘录，看起来像下面这样：
...
<hashes>
<hash>
<path size="44900638" lastmodificationdate="2016-02-09T11:38:41+01:00">
A001C006_141024_R2EC.mov
</path>
<xxh128 action="original" hashdate="2023-01-23T09:18:40.616865+01:00">
c90b79d2e682e9f8dd2715add65e5913
</xxh128>
</hash>
<hash>
<path size="44394794" lastmodificationdate="2016-02-09T11:38:53+01:00">
A001C019_141024_R2EC.mov
</path>
<xxh128 action="original" hashdate="2023-01-23T09:18:40.632174+01:00">
e25ad55e74d8665142b58f7ee1f2de96
</xxh128>
</hash>
...除了文件路径和哈希值，我们还能看到每个文件的更多信息： 文件大小、文件的最后修改次数以及计算哈希值的日期。ASC MHL 清单本身也会被计算哈希值，因此也能可靠地检测到已更改或不完整的清单。
传统的 MHL 和全新的 ASC MHL 清单文件都包含有关进行装载的软件的附加信息（包括版本号），甚至包括备份过程负责人的联系信息。所有这些信息都能在文件可能出现问题或已经出现问题时简化搜索工作。
“嵌套或封存”
如上所示，清单文件已经很好地记录了一项数据管理活动的完全性。那么多重备份的完全性要如何考量呢？
事实上，当我们为每个复制的文件夹添加一个清单文件，并将所有这些文件夹收集到一个旅行驱动器中时，我们仍然会遇到一个问题。如果少了一个文件夹怎么办？举例来说，我们设想这样一种情况：将移动硬盘复制到设备中的文件服务器上，但有一个文件夹没有复制。您怎么能够知道这种情况？对其余文件夹进行完全性检查不会发现问题，因为它们各自文件夹的所有清单都会显示检查成功。
如果没有一个 “超级清单”，我们就无法知道是否应该存在一些还没有痕迹的东西。超级清单不一定是所有文件的另一份清单，但可以是一份包含应该存在并经过验证的文件的所有清单的列表。
在 Silverstack 中，有一个 “封存 “的概念，可以在目标驱动器上创建这样一个 “清单列表”。有了这个封印，以后就可以随时轻松检查旅行驱动器的所有方面是否仍然完整。
新的 ASC MHL 标准提供了类似的功能，允许对清单进行所谓的 “嵌套”。这意味着您不仅可以使用 ASC MHL 列出某些文件夹中的文件，还可以引用其他 ASC MHL 清单文件。这样，您就可以将清单分组，并为检查完整性提供一个起点。
最佳实践
遗憾的是，清单文件本身并不检查任何东西。因此，用户需要确定在工作流程中使用清单的合适时机，以检查可用数据的完全性。
因此，如果您是创建清单文件和文件副本的人员，请让接收数据的人员了解清单文件以及如何对其进行检查。针对 ASC MHL 及其清单，我们开发了 “Pomfort MediaVerify”（可在此处免费获取），用于验证任何使用该标准管理的数据。自 8.4 版起，所有 Silverstack 应用程序都支持创建、延续和检查历史记录。对于 Silverstack 带有封存功能和 MHL 文件的经典 MHL 工作流程，您可以使用 “Pomfort SealVerify”（可在此处免费获取）。
请鼓励数据包接收方使用给定的清单文件和上述工具检查完整性。越早发现问题，越有可能轻松解决。此外，您偶尔也要亲自测试和检查所移交的数据，以便熟悉工具并了解其工作原理。
总结
在这篇文章中，我们讨论了包含文件列表、哈希值和上下文信息的清单文件如何成为成为一个强大的工具，用于记录已处理的数据以及数据传输后应接收的数据。通过这些清单文件的内容，您可以检查每个文件的一致性（通过比较哈希值）和整个数据集的完全性（通过比较文件列表）。在关键时刻进行定期检查，并在出现问题时提供足够的备份以进行恢复，就能为成功的数据管理工作流程做好充分准备。
__________________________
[1] 您可能会想说，在这之前还有一个层次： 就是确保每个文件都是完整的，但这已经包含在上一篇文章中提到的，使用哈希值检查 “完整性 “的内容中了。
[2] 当然，还可以通过将 md5 与查找命令结合使用来实现更复杂的功能，例如，可以使用 find A001R2EC/ -type f -exec md5 {} \;. 这样的命令。不过，现在你已经迈出了成为数据管理软件开发者的第一步，而这已经超出了本文的讨论范围。
