不同部门通常会使用不同的硬件、软件和工作流程多次复制数据。如果在数字生产管线的某个环节出现问题，可能很难找出错误的根源，甚至无法解决。想想文件损坏或流程中某个步骤的质量控制问题。调查数据问题既费时又费力，这正是您希望避免的。

这也正是 ASC MHL 发挥作用的地方，它为在整个数字电影制作过程中建立安全的数据工作流程提供了可能。在本文中，我们将深入探讨数据安全这一主题，包括解释什么是 ASC MHL 以及如何从工作流程中获益。如果您想立即开始使用 Silverstack 和 MediaVerify 搭建基于 ASC MHL 的工作流程，可以直接跳到 “使用 ASC MHL 从片场到后期对数据进行管理” 部分。

电影制作的安全数据工作流程

“安全”是什么意思？

在使用 “确保数据安全 “这一表述时，我们实际上指的是两个重要方面： 数据完整性和完全性。完整性是指在数据管理过程中，单个文件没有被无意更改，而完全性是指接收到的数据量与发送者预期的相同。数据完整性一般通过特定哈希算法生成的哈希值来检查。如果（传输后）前一个哈希值和计算出的哈希值一致，则认为文件是一致的。在有多个子文件夹的文件夹结构中，完全性包括两个方面： 单个子文件夹（及其包含的所有文件）的完全性和整个根文件夹结构的完全性（或完整性）。^[1]

媒体哈希列表（MHL）

著名的媒体哈希列表（经典 MHL）格式的诞生，是媒体行业安全数据工作流程迈向标准化的第一步。它引入了一种简单的 XML 格式，用于存储范围内每个文件的哈希值和其他信息。虽然经典 MHL 可以验证单个文件夹及其文件的完整性和完全性，但它无法确保整个（根）文件夹结构（如摄影机存储卡文件夹集合）的完全性。经典 MHL 的范围仅限于一个文件夹及其内容。因此，如果一个子文件夹（例如，一个摄影机存储卡的子文件夹）连同其经典 MHL 文件一起丢失，就没有任何信息告诉接收者还应该存在一个文件夹。我们在下面的图 1 中直观地展示了这种情况。考虑带有经典 MHL 文件的文件夹结构，如拍摄时管理的文件夹（左）和后期接收的文件夹（右）。如果没有额外的信息，就无法判断文件夹 A005R2VJ 已经丢失了。

考虑到这些缺失的功能，以及创建一个能在整个生命周期内保护数据安全的标准这一总体目标，美国电影摄影师协会（ASC）成立了一个工作小组，以开发经典 MHL 的改进型后续产品： 这就是 ASC MHL！

ASC 媒体哈希列表

ASC MHL 由美国电影摄影师协会（ASC）的动态影像技术委员会（MITC）开发和维护。其目标是实现媒体数据管理的标准化并保留相关信息。相关配套信息存储在被称为 “ASC MHL 清单 “和清单中列出的 “链文件 “中。它们共同构成了 ASC MHL 的文件历史信息。

ASC MHL 的一个重要特点是 “世代 “的概念。每一次数据操作，如传输或验证，都会创建一个新的所谓 “世代”，它代表了 “数据管理之旅 “的一个步骤。创建新世代包括以下步骤： 

• 创建所有文件的哈希值（例如，媒体文件）
• 创建新的 ASC MHL 清单（例如，为每一个已存在的历史记录创建新的附加清单）
• 更新链文件中的引用（例如，为特定世代添加新的序列号）
• 对所有嵌套历史进行递归更新

这听起来可能很复杂，但最终可以让您了解和回溯从后期到片场的大部分数据管理活动  – 前提是监管链被保留。由于 ASC MHL 历史记录存储了所有世代的哈希值，因此可以将错误定位到特定世代，并最终定位到文件。如前所述，单个文件的哈希值不匹配就表示内容已更改。在这种情况下，文件的状态是 “失败”，而不是 “已验证”。

为了更好地理解这一点，让我们来看看下面的图示。图 2 显示了 MacOS 文件系统（左侧）和 MediaVerify 文件历史视图（右侧）的合成图。MediaVerify 从 ASC MHL 清单中提取信息，并在用户界面上显示生成的信息（蓝线）。文件 A001C001_160205_R2VJ.mov（红色方框）的验证在第三代（橙色方框）失败，这意味着文件内容在第二代和第三代之间发生了变化。

最重要的是，ASC MHL 还通过将 ASC MHL 历史记录与文件夹结构嵌套在一起的方式，解决了上述顶层完整性缺失的问题。这意味着可以创建额外的顶层历史记录，存储对子目录中所有子历史记录的引用，从而可以识别特定子目录中缺失的文件夹，最终解决完整性问题。

让我们再次快速浏览一下图示。图 3 显示了这种嵌套历史的一个例子： 红色箭头表示引用文件的清单。橙色箭头表示引用清单的链文件。蓝色箭头是从顶层 “根 “历史记录到最新一个世代历史记录的引用。由于文件夹结构包含两个清单，因此历史记录包含两个世代。

使用 ASC MHL 从片场到后期对数据进行管理

ASC MHL 是一种免费开源格式。这意味着任何软件都可以实施 ASC MHL，或采用同样免费和开源的参考实施方案。您可以在任何支持该标准的软件中使用 ASC MHL。在 Pomfort 生态系统中，Silverstack Lab、Silverstack/XT 和 Offload Manager  允许您创建、验证和延续 ASC MHL 历史记录。Pomfort MediaVerify 可补充后期制作方面的工作流程，并验证之前使用 ASC MHL 管理的任何数据。那么，让我们来详细了解一下从拍摄到后期制作的工作流程！下面的图示概述了从拍摄到后期制作的典型数据管理工作流程。在接下来的章节中，我们将逐一介绍每个步骤。

装载

为了简单起见，我们只解释处理原始摄影机素材的流程。当然，该流程也适用于录音、报告或转码样片等其他数据。首先，您需要在 Silverstack 中启用 ASC MHL。如下图 5 所示，打开设置，在拷贝和工作选项卡中将哈希清单从 “Classic MHL “更改为 “ASC MHL”。这也会在下拉菜单旁边显示一个新的省略号图标（三个点），它将带你进入 ASC MHL 设置。如图 6 所示，在这里你可以调整创建者信息或设置自定义忽略模式。

从片场到后期的典型场景包括以下基本步骤：

1. 将多张摄影机卡装载/备份到旅行硬盘或现场 RAID 阵列上
2. 创建拍摄日文件夹结构
3. 转码样片
4. 备份整个拍摄日文件夹

在某些情况下，ASC MHL 历史记录需要初始化。这可能发生在摄影机内，也可能发生在第一次装载时。如果历史记录是在卸载过程中初始化的，Silverstack 会创建第一代文件，计算每个文件的初始哈希值，并将它们标记为 “原始文件”。假设历史记录已经在拍摄过程中生成，那么装载将创建第二代文件，并将文件标记为 “已验证” – 因为装载是通过哈希值比较进行验证的。

如果您在装载向导中打开带有预先存在的 ASC MHL 历史记录的数据，Silverstack 会通过比较文件系统中的数据和历史记录中的数据来通知您历史记录的状态。这包括有关丢失、新增或忽略的文件和错误（如不完整的历史记录）的信息。Silverstack 的装载向导会通知您 ASC MHL 历史记录的任何问题（标记为黄色栏）。这在下面的图 7 中可以直观地看到。正如您所看到的，日志包含有关问题的更多信息 – 在本例中，Silverstack 检测到缺少一个素材片段。

此外，您还可以选择特定的校验方式，并决定是继续还是从头开始创建历史记录（复选框：”启动新的 ASC MHL 历史记录”）。此外，创建历史记录时还会自动考虑级联复制等功能。

备份

在一天的拍摄过程中，数据卡会被装载，拍摄日文件夹结构会被建立，样片也会被转码。这听起来可能显而易见，但请注意，仅在转码过程中，不会创建任何 ASC MHL 历史记录，因此，样片（还不是）历史记录的一部分。要包含样片和当天创建的所有其他数据，您需要备份整个拍摄日文件夹。这将创建一个嵌套的 ASC MHL 历史记录： 所有之前存在的历史记录都将作为新一代文件继续保存，而所有新文件都将作为第一代文件包含，并标记为 “原始”。通常情况下，该备份应该是拍摄日结束时的最后一步，它代表了数据包被认为是完整的，可以被用于后期制作单位的使用。

在后期制作时的数据验证

作为后期制作主管，在将数据交给整个团队进行进一步处理之前，必须确保数据完整并经过验证。最糟糕的情况是在几周后发现文件损坏，让所有人都等着解决问题。

然而，当数据使用 ASC MHL 管理时，使用 Pomfort MediaVerify（我们的增强型免费验证软件）可以轻松完成后期验证。该软件易于使用，专门为数据验证过程定制，并提供足够的自定义功能，以适应各种数据管线。

MediaVerify 的验证过程包括两个步骤，简单明了。第一步是自动文件扫描，通过将文件夹结构与 ASC MHL 历史记录中的文件列表进行比较，识别磁盘上的实际内容与历史记录中录制内容之间的差异。这一步只识别丢失的文件或新增文件，并提供快速的首次完整性检查。该步骤可在短时间内（即几秒钟）完成，几乎可以立即反馈可能无法通过验证的明显问题。在实际验证步骤中（也会在历史记录中创建新的一个世代），MediaVerify 会为所有文件创建哈希值，并将其与 ASC MHL 清单中的哈希值进行比较。因此，所有文件也会进行完整性检查。

核查必须满足以下方面的要求才算成功： 

•  ASC MHL 历史记录已完成。
• 所有文件都可用。
• 所有哈希值均匹配。

你可能无意中发现了第一个要点，因为我们还没有讨论过它。在某种程度上，ASC MHL 历史记录会自我监控，并通过上述列出所有 ASC MHL 清单的 “链文件 “检测是否缺少某些内容。如果出现内容缺失的情况，历史记录将被视为不完整，无法进行验证。

验证完成后，MediaVerify 会显示验证结果，并提供全面的大纲来深入评估历史记录和文件。此外，保存日志和报告文件的功能有助于记录您的工作。这些报告可以被发送到现场拍摄组，以确认数据传输是否成功。由于验证为历史记录添加了新一世代的内容，因此 “监管链 “得以延续。

展望

在本文中，我们讨论了 ASC MHL 的优势及它在监控和检查数据方面的更多可能性。在对该规范有了大致了解后，我们概述了使用 Silverstack 和 MediaVerify 进行从片场拍摄到后期制作的正确数据管理工作流程。在整个拍摄流程中，ASC MHL 可以帮助您对数据状态充满信心，因为它允许您在各部门和设备之间建立安全可靠的数据工作流程。作为一项不断发展的行业标准，ASC MHL 正被越来越多的制造商所采用（例如，RED 为特定摄影机实施了机内 ASC MHL）。此外，ASC MHL 还能提供一些有价值的功能，例如检测重命名文件（并将新文件名存储在 ASC MHL 历史记录中）或通过创建者信息包含相关联系信息，而无需额外费用。因此，如果您正在管理重要的拍摄数据，我们建议您考虑使用它。有关 ASC MHL 的更多信息和详情，请查看我们的知识库。

[1] 我们假定您具备有关数据完整性和完全性主题的常规技术知识。请注意，他的文章侧重于描述传输完整且一致的数据方面的数据安全性。ASC MHL 不能取代在多个备份存储设备上使用经过验证的数据副本这种普遍使用的合理备份策略。

数据的完全性

谈到 “完全性”，我们可以区分两个层面： 首先，我们需要确保每个单独的数据管理流程或活动（如备份一张摄影机数据卡）都是完全的^[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 {} \;. 这样的命令。不过，现在你已经迈出了成为数据管理软件开发者的第一步，而这已经超出了本文的讨论范围。

在后续的文章中，我们将讨论清单文件以及如何使用清单文件来保持数据的完全性，从而转向成功数据管理的第二个支柱。但首先，我们还是要谈谈数据完整性！

数据完整性

保持完整性（或 “数据完整性”）是指确保数据在整个生命周期内都是 “正确 “的。对于已录制的媒体文件，这意味着文件未被无意更改，所包含的内容与摄影机录制时相同。

理论上听起来很简单，但实际操作起来却很棘手。试想一下，将文件从摄影机数据卡传输到外置硬盘时，需要一长串硬件和软件组件协同工作： 

• 通过可插拔电缆连接的各种不同的设备，
• 读卡器自带控制器和连接器，
• 固态硬盘或磁盘控制器组件和缓存，
• USB 或 Thunderbolt 接口组件，
• RAID 阵列系统（硬件或软件阵列），
• 多个文件系统（可能是不同类型的），有时是虚拟文件系统（如 Codex VFS），在需要时为磁盘卷创建文件数据，
• 一个操作系统，带有用于读写文件的文件访问例程、访问权限管理系统、RAM 中的文件缓存机制、多线程支持，
• 以及执行数据传输的软件应用程序，如 Pomfort Silverstack 或 Offload Manager。

好消息是：文件发生意外更改的情况并不常见。不过，这也并非不可能。物理和交互式组件的数量、物理连接器和电缆连接、独立电源以及不同供应商的固件和软件版本，都会在某些情况下增加出错的几率。那么，潜在的后果是什么呢？让我们来看几个在文件传输或存储过程中可能出现问题的例子： 

空文件： 复制过程中可能会出现这种情况，即文件已创建，但未成功写入其内容。可能的原因 介质已满、访问权限不足或创建文件后进程中止。

文件缩短： 在复制过程中，由于写入过程不完整，可能会出现这种情况。可能的原因：复制中止、介质已满、电源或连接故障以及未恢复进程。

文件内容错误：可能的原因有很多： 这可能发生在数据块在写入过程中出现混乱，例如，多线程的问题或错误。数据块在卷上分配但未写入时也可能发生这种情况。这样，格式化存储卡前写入的旧内容就会 “闪现 “出来，显示为错误的内容。另一种可能的情况是在传输或存储过程中出现比特错误，例如，组件或存储/内存出现故障或不可靠。文件内容也可能完全错误或损坏，例如文件系统结构损坏。

通过编辑修改文件：文件也可能被编辑改变，例如，软件应用程序在打开文件时覆盖了整个文件或部分文件，而用户可能无意中操作或者未察觉到这种操作。

如何实现数据完整性 

好了，恐怖场景就讲到这里。您现在可能会问自己，该如何帮助维护数据完整性。下面，我们将向你介绍一个有助于检测上述问题的核心概念： 计算和验证单个文件的校验和。

首先，让我们来了解一下什么是校验和、如何使用哈希算法来创建校验和，以及如何使用它们来检查文件内容的完整性。

为了检测文件在传输或存储过程中的错误，通常会创建校验和。其原理是使用一种算法（校验和函数），从任意大小的数据块（例如，文件）中创建一小段数据（校验和）。一个好的校验和函数有一个非常（非常非常）高的概率，即当文件内容的任何部分发生变化时，给定文件的校验和会变得不一样。校验和函数也是确定的，因此可以随时重新计算校验和。

换句话说：

在传输或复制文件后，计算文件的校验和，将计算出的校验和与之前为该文件计算出的校验和（如在源硬盘卷上）进行比较，就能以非常（非常非常）高的概率确保文件内容保持不变。如果校验和不相等，则可以肯定内容发生了变化。如果校验和相等，则可以认为文件未被修改。

这是在软件中使用校验和来检测文件更改，和实施的所有文件的完整性检查的基本原理。

校验和方法种类繁多，有些适用于很小的数据块，有些甚至用于纠错。但最适合和最常用的，确保文件数据完整性的校验和函数是hash（哈希）算法。

HASH （哈希）算法

hash（哈希）函数将任意大小的数据块（即文件内容）映射为一个短的（固定的）大小值。这正是我们对校验和函数的要求。hash 函数创建的值称为 “哈希值”。用于创建哈希值的哈希算法名称有时也称为 “哈希类型”（例如，一个文件的哈希值可能是 MD5 类型的 f5b96775f6c2d310d585bfa0d2ff633c）。

根据维基百科，”一个好的哈希函数要满足两个基本特性： 1) 计算速度要非常快；2) 尽量减少输出值的重复（碰撞）”。

当两个不同的数据文件产生相同的哈希值时，就会发生 “碰撞”。 发生这种情况的概率应尽可能小。相反，输出范围内的每个哈希值都应以大致相同的概率生成。这样，哈希算法就能很好地实现我们的目的 – 当给定的数据不同时，它就会产生不同的哈希值。

以下是媒体管理流程中通常使用的哈希算法的几个示例，并附有示例值：

• MD5 (128 bit, 示例值: f5b96775f6c2d310d585bfa0d2ff633c)
• xxhash64 (64 bit, 示例值: f409b64875d02fa1)
• C4 (512 bit, 示例值: c45TH1egbyWxtjgFmisoPypYXcizxPbywFzkbhevak2NgQr3HND5j99HR8UQDwT8pQoS8k3yxhLRGJPoNgR1zUin31)

碰撞概率

让我们考虑一种能产生完全均匀分布值的哈希算法。那么，当两次查看一个文件时发生碰撞的几率（即修改后的文件会产生相同的哈希值）可以由哈希值的长度决定，如下所示：

碰撞概率（即理想的哈希算法对两个不同文件内容产生相同哈希值的概率）为 其中，l 是哈希长度（比特）。

因此，对于哈希值长度为 64 位的哈希算法（例如 xxhash64），该概率为 1 / 2^ 64，约为 1/18.446.744.073.709.551.616 或 5.42101086 × 10^ -20。换句话说，您需要尝试对同一文件进行约 185.395.973.344.368.338（185 quadrillion）次随机更改，直到所有比较的总体碰撞概率超过 1%。也就是说，每秒尝试 1000 次给定文件的更改，需要 5.878.867（590 万）年的时间，而 99% 的概率仍不会发生碰撞。

即使哈希算法并不能完全均匀地分配值，但可以想象，64 位对于哈希值来说已经是很好的大小了，可以检测文件中的任意变化。

速度

哈希算法可能成为数据传输时的限制因素，因为我们总是希望在传输过程中创建哈希值。因此，除了传输实际数据外，还需要计算这些数据的哈希值 – 这当然需要额外的 CPU 时间。xxhash 系列哈希算法的网站提供了不同哈希算法的速度概览。

第一个启示是，长度（即哈希值的位数）并不一定与算法的速度相对应。另一个启示是，最大速度的差异可能很大（例如，在相同的计算机硬件上，XXH3 和 MD5 之间的差异可达约 50 倍）。这是因为哈希值需要一个字节一个字节地按顺序计算，不容易实现多线程。这意味着，一个 CPU 内核的速度限制了哈希值的计算过程，而将一个哈希值计算过程切换到具有更多内核的 CPU 不会使哈希值计算更快（当然，您的软件可能会同时对多个文件进行独立哈希以提高整体吞吐量）。

结论与展望

在本文中，我们讨论了创建校验和将如何有助于检测数据的完整性的问题。我们讨论了哈希算法的使用和哈希值作为校验和的使用，并展示了软件应用程序是如何发现数据在其生命周期内是否发生了变化，并向用户发出相应的警告。

在接下来的文章中，我们将探讨完全性的问题，以及在数据管理流程中采取哪些措施来确保没有文件被遗忘。敬请关注本系列文章的第二部分！