继《数据管理之校验和+哈希值检验数据完整性》系列文章后，本文继续探索数据管理的概念。在前个系列的文章中，我们已经确定了要成功进行数据管理需要做到两个方面：“最重要的目标之一……是维护拍摄过程中记录和创建的所有数据的完整性（integrity）和完全性（completeness）。”前个系列的文章主要研究如何通过计算和比较哈希值来维护单个文件的完整性，而在本文中，我们则会讨论完全性这个方面，包括清单文件。

数据的完全性

谈到“完全性”，我们可以分出两个层次：首先，我们需要确保每个单独的数据管理过程或活动（例如一张摄影机卡的备份）是完整的[注1]。但有时，这些活动会合到一起，而我们需注意整批活动或过程的完全性（例如确保单个拍摄日内所有摄影机卡备份的完全性）。我们会看到，这两个层面都面临着不同的挑战。我们先来讲讲第一个。

单一活动完全性

假设你需要备份一批文件。我们通过将某个软件定向到包含我们要复制文件的文件夹来开始这一过程。随后，进程开始，文件被逐个复制到新的目的地。如果一切顺利，这个复制过程就能保证完全性，也就是说，只有当所有文件都成功写入目的地时，软件才会停止进程。

如果进程中止或者在没有通知的情况下失败了，单纯浏览目的地没法查出某个子文件夹中是否缺少一个（或多个）文件。这里就需要更彻底的检查了，通常包括目的地和源的比较。即使在最疏于管理的工作流中，你也可以比较源文件夹和目标文件夹的总体大小，或者比较文件夹中的文件数以查找这种未检测到的不完全进程。

多活动完全性

现在我们来看一个场景，此时多个活动被分成组，以创建一个新的文件“包”。这种典型例子几乎在每个拍摄日里都能遇到：

在一整天的拍摄中，多张摄影机卡被装载到一块更替硬盘上。其他文件，如音频卡、报告、片场照片、已转码的样片等等，也加到了这块更替硬盘上。因此，即使单次装载或复制行为最终完成，你又如何确保这块硬盘上没有丢失整个文件夹呢？即使每张卡都被成功复制，你也需要在某个地方记录这些数字。还有，那块更替硬盘上该有八张还是九张卡？

“为什么会出问题”——以及如何发现问题

第一级的完全性（一次装载或备份过程的完全性）是最重要的。如果我们无法检查出一次进程是否已经成功完成以及所有复制的文件是否完好存在，那我们就讨论不了把这些进程分成组的问题了。

如果你确实发现了问题，导致流程不完全的原因可能是多方面的：

• 电源问题：不仅是计算机，也可能是其它需要独立电源供应的外部设备失去了电源（想想跳闸的线缆，因振动而松掉的插头，等等）。这些设备可能是读卡器系统或外部复制目的地硬盘；

• 源读取错误：当硬盘内读取到错误块时就可能发生读取错误。这会使文件系统挂起或超时；

• 复制目的地之一存在写入错误：也是同样由错误块导致的问题，但有时也是由“卷上没有足够的剩余空间”这样的基础原因导致的。即使软件在进程开始时检查了是否有足够空间，其他系统也可能在进程运行时写入到相同的目的地（比方说，一次复制正在运行时，一个代码转换器则正在写入同个目的地）；

• 一致性检查中的错误：根据软件的运作方式或安装方式，如果出现哈希函数错误，流程可能会停止；

• 其他资源问题：虽然复制进程不需要太多内存，但是如果没有内存余量，那就只能中止进程了。比方说，如果正在运行其他占用内存的进程，我们的数据管理进程可能无法再将源文件中的数据加载到内存中。

为了检测到这些问题，数据管理软件需要确保之后能轻松发现某次进程是否已暂停、中止，或在中间某一时刻失败。只依靠软件本身的任务结果状态（检查这一点）并不总是足够，在下面的一些情况（比如内存不足）中，软件就无法继续可靠运行，且可能在无法写入错误日志的情况下退出。

这一问题的解决方案是在进程结束时创建一个“收据”，其中包含进程试图处理的文件列表。如果这个“收据”缺失，我们就知道出了问题。如果它没有缺失，那我们可以靠检查文件列表来核对进程的处理结果是否都依然完好存在。当包中缺少一个或多个单独数据管理活动的结果时，就会出现第二级不完全性。

通常情况下，这种情况较少出于技术原因，更多出于组织管理原因：

• 设备混乱：位置或标签错误的摄影机卡可能导致卡根本未进行复制。
• 进程未开始：有时，一切就绪，但进程根本就没有开始。在用户分了心、忘记开始装载任务、离开再回来误以为任务已经完成时，就会发生这种情况。
• 错误的目的地：拷贝需要写入正确的目的地；否则就会出现虽然任务完成了，但是得到的结果不在你以为会在的地方。这可能发生在将文件夹拖放到访达中的其他文件夹，且放开鼠标时目的地未突出显示的时候。
• 沟通错误：在紧张环境下协同工作时，沟通可能会被误解（比如：“是你开始那个的吗？”“是的!”……但其实这里的那个对双方各自意味着不同的东西）。

这些问题超出了软件的范围，但是良好的管理仍然可以帮助发现这些情况（比方说，通过比较更替硬盘内容与其他信息源，如摄影机报告和在格式化前两次或更多次交叉比对卡）。

考虑到所有这些因素，还有一个问题是可以避免的——尽管对在拍摄日结束时负责将文件合到一起的实际数据管理人员来说，这超出了工作范围：

·在后续数据管理过程中丢失文件夹：即使你确保了离开电影片场的更替硬盘的完全性没问题，将更替硬盘的内容复制到各种后期公司的文件服务器的后续过程也可能失败。但在后期公司，没有摄影机卡上的贴纸或其他源文件可以比较。为了让同事们在未来可以察觉不完全性，一份最初复制时的内容清单可以解决这个问题，即你在有需要时可随时提供一些内容进行比较。

总而言之，我们已看到确保完全性可不是一次就能完成的任务，尤其是在电影制作的媒体工作流中。文件和文件夹被复制、移动、备份和存档很多很多次，所以完全性的范畴远远超过了电影片场的那一次复制。

为了确保所有这些后续活动的完全性，我们得从预计要进行复制的那一刻起就记录下什么该复制到某处。这意味着完全性总是得从源就开始思考。下面让我们更仔细地看看这对我们的数据管理活动意味着什么。

以列表表示完全性

为了检测进程不完全的活动，提供一份简单的文件列表可能已是一个很好的解决方案。即我们列出该在某个文件夹中的所有文件，可轻松地在任意时刻进行检查。

如果我们还要考虑完整性的问题的话，那么那份文件列表也会是存储每个文件哈希值的最佳位置。你选择的操作系统很可能已经附带了制作这种列表的工具。比方说，以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：是一个目录

遗憾的是，这不能直接用于文件夹结构[2]。通常我们会需要处理更复杂的文件夹结构，因此那部分应该明确被涵盖在其中。

此外，如果采用这种方法，我们并不会知道最后该有什么：如果在2个文件之后中止md5命令，进程停止，而列表看起来就会像是只有2个文件。没有任何迹象表明源有10个文件。

清单文件

因此，好的数据管理软件应该知道源中包括了什么，并将其作为任何文件列表的基础。如果某些进程中止或失败，那么某些内容缺失也该很容易察觉。

在Pomfort的Silverstack和Offload Manager软件中，这是通过所谓的清单文件完成的。这些文件类似于我们上面看到的简单文件，但是采用了更结构化的句法，并且提供了更多适合媒体工作流的信息。这些清单文件通常采用一种称为“MHL”（“media hash list-媒体哈希列表”的缩写）的格式，或者更新的“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清单文件。这样，你就可以将清单分成组，并得到一个检查完全性的起点。

最佳实践

不幸的是，清单文件本身不会检查任何东西。因此，用户需要在工作流中找到使用清单检查可用数据是否完全的正确位置。

因此，如果你是负责与文件拷贝一起创建清单文件的人，请让这些数据的接收者知道有这么一份清单文件以及如何检查它们。对于Silverstack的封印和MHL文件，有一个同时支持macOS和Windows的软件叫“Pomfort SealVerify”（在这里可以免费获得）。截至现在（2023年1月），ASC MHL还很新，因此并不是所有数据管理工具都能写入或验证这些内容。命令行工具是开源参考实现（open source reference implementation）的一部分，可用于验证带ASC MHL文件的硬盘或文件夹。

你应该鼓励数据包的接收者用给定的清单文件和上述工具检查完全性。问题发现得越早就越容易解决。此外，你需要不时自行测试和检查你要交出去的数据，这样你会熟悉这些工具并清楚它们确实有效。

请注意：ASC MHL已在Silverstack测试版中可用，并将于2023年2月初与Silverstack v8.4一起正式发布。

总结

本文中，我们讨论了包含文件列表、哈希和上下文信息的清单文件是怎样的一种强大工具，它能够记录已处理数据，还能记录数据传输后应接收内容。有了这些清单文件的内容，你可以检查单个文件的一致性（通过比较哈希值）和整个数据集的完全性（通过比较文件列表）。通过在关键时刻定期检查，以及为防止出现问题充分备份以进行恢复，你已为成功的数据管理工作流做好了充分准备。

本系列所有文章：

第一部分：数据管理之校验和+哈希值检验数据完整性

第二部分：数据管理之清单文件中数据的完全性

[注1]：你可能会反驳说这之前还有一个层面：确保每个单独文件的完全性，但那已经在之前以哈希值检查“完整性”的文章里探讨过了。

[注2]：结合md5和find命令当然可能会更复杂一些，例如执行：find A001R2EC/ -type f -exec md5 {} \;。但那意味着你迈出了成为数据管理软件开发者的第一步，这就超出本文探讨的范畴了。

出处：Pomfort

编译：Charlie | 盖雅翻译小组