如何在 icloud 中存储扩展文件属性-尊龙游戏旗舰厅官网

一些扩展属性由 macos 自己创建和管理，但应用程序也可以创建自己的扩展属性并存储它们。由每个应用决定如何管理扩展属性。

有些文件系统根本不支持扩展属性，例如 nfs。如果将文件复制到不支持扩展属性的文件系统，这些属性将永远丢失。

大多数常见的现代文件系统都支持扩展属性，但可能以不同的方式管理数据。在大多数操作系统上，扩展属性不与文件本身一起存储，而是存储在卷元数据目录中，卷元数据目录将每个文件的附加属性存储在列表或数据库中。

当一个文件被复制时，元数据也随之被复制并插入到目标卷的元数据目录中以保留额外的属性。使用此行为，操作系统在复制期间将文件元数据与文件本身一起从一个卷移动到另一个卷。

apple 发布了有关 macos 元数据系统及其工作原理的开发人员信息，但并非全部。目前没有用于在 macos 或 ios 上管理元数据的用户级 apple 文档。

xattrs 和反向域名组织

我们确实知道，在 macos 中，扩展属性和元数据是在反向域表示法下组织的——很像应用程序包名称和公司组织。一些用于元数据的 apple 反向域包括：

1. com.apple.finderinfo
2. com.apple.metadata
3. com.apple.textencoding

并非每个文件都需要所有扩展属性 – 某些文件可能完全缺少来自某些反向域的 xattrs。

icloud 中的 xattrs

当 apple 发布 icloud drive 作为在云中复制和存储文件的一种方式时，用户开始注意到一些（但不是全部）文件元数据丢失了。更糟糕的是，这种行为在不同版本的 macos 之间变得不一致，有时是在 mac os x mojave 发布前后。

用户注意到，一些（但不是全部）扩展属性在移入 icloud 时会从文件中删除，然后再复制回来。

至少我们知道，当文件移动到 icloud 时，来自 com.apple.finderinfo 的所有扩展属性和所有用户添加的元数据（包括 com.apple.metadata 域中的 get info 评论）都会被删除。

com.apple.textencoding 域和某些其他域中的扩展属性将被保留。在某种程度上，这是有道理的，因为每个应用程序甚至 finder 都必须知道每个文件中的文本数据是如何编码的，以便正确显示它。

另一方面，对于 apple 而言，icloud 保留某些属性（如 com.apple.finderinfo）可能没有意义，因为该数据对于每个用户 mac 上的 finder 显示首选项可能是唯一的。

尽管如此，剥离文件的 get info 用户评论显然是数据丢失。更糟糕的是，有报告称，当访问 icloud 中的相同文件时，icloud drive 会从不同版本的 macos 文件中剥离第三方扩展属性。这显然很糟糕。

到目前为止，apple 尚未公开解决或评论此事，因此我们不知道这是有意为之还是未解决的问题。

一个简陋的修复（有点）

自 2013 年左右的某个时候以来，apple 所做的就是悄悄地向文件元数据添加一种开发人员黑客技术，称为扩展属性标签。

apple 的 xattrs 标签系统包括将四个字符（c、p、n 或 s）之一附加到每个 xattr 的末尾，前面是 #’ 字符。由于 #’ 是 xattr 名称中禁止使用的字符之一，因此大多数处理 xattrs 的应用程序代码都会忽略标志。

四个标志字符中的每一个都对应于 apple 编程接口中的一个 xattr 元数据保存级别。我们不会在这里讨论这些细节，但足以说明 p、n 和 s 标志大致对应于这些属性保留级别：

1. c – 文件数据更改时保留。
2. p – 复制时保留。
3. n – 始终剥离 xattrs – 即使在复制时也是如此。
4. s – 同步时始终保留 xattrs。

因此，当将文件复制到 icloud drive 时，任何末尾附加有“#s”标志的文件 xattrs 都将被保留。

目前，如果不使用终端并准确理解应该进行哪些更改，则没有简单的方法可以对文件进行这些修改。

我们应该警告您，更改扩展属性可能是一项有风险的业务。xattrs 中的任何错误都可能改变文件在 finder、获取信息窗口、文件创建和修改日期中的显示方式，甚至在某些情况下甚至可能导致文件损坏或无法使用。

我们可以肯定地知道，从 macos ventura 开始，spotlight 索引知道如何处理额外的 xattr 标志而不会造成混淆或数据丢失，但 finder 的“获取信息”窗口并不总是如此。通常，将 xattr 标志添加到 finder 的获取信息使用的 xattrs 会使文件无法读取，甚至可能无法从 finder 打开。

另请注意，finder 在复制期间将始终遵守任何 xattr 标志 – 例如，如果在本地finder 复制期间任何文件的任何 xattrs 中存在“#n”标志，则在所有情况下这些属性将始终从复制的文件中剥离。

另一方面，终端文件复制命令 (cp) 在任何情况下都将始终保留所有 xattr 标志 – 无论如何复制所有复制文件的所有 xattr。

您可以通过键入以下命令在终端中查看关于 xattr 标志的相当稀疏的开发人员信息：

man xattr_name_with_flags并按下return。

但除非您是开发人员，否则所提供的信息可能难以理解，因为它主要是包含在 c 头文件中的标准 c 库编程信息xattr_flags.h

终端中的 xattrs

您可以使用xattr命令在 macos终端中查看和更改文件的 xattr ，但这样做时要格外小心。

您还可以使用标准终端目录列表来查看给定文件是否具有 xattrs。为此，在终端中，使用“cd”命令导航到要查看其文件的目录，然后键入：

ls -l

然后按return。

您将看到目录列表，类似于：

目录列表的左侧是每个文件的 unix 权限。以“@”或“ ”结尾的文件权限表示附加了扩展属性的文件。

要查看每个文件的属性属于哪些反向域，请键入：

ls -l@

然后按return。

该列表将与使用“ls -l”相同，只是还会列出文件中使用的任何 xattr 反向域：

xattr unix 命令是一种查看和更改文件 xattrs 的方法，但正如我们上面提到的，使用它时要格外小心。该命令功能强大，很容易破坏文件的可用性。

您可以通过键入以下命令在终端中查看所有 xattr 命令选项：

man xattr并按下return。

按control-z退出 man 系统。

总之，在将文件复制到 icloud 或从 icloud 复制文件时，没有任何简单易行的方法来处理 xattrs。

只要在与 icloud 同步或从 icloud 同步时将给定的 xattr 标志设置为“#s”，该 xattr 将始终被保留。

apple 应该在 macos finder 和 ios 中修复此问题，但这样做会带来一个问题：它需要在同步时向所有文件 xattrs 添加“#s”标签，这样做可能至少会破坏一些第三方应用程序，这些应用程序读取并编写 xattrs 但还不知道如何处理标签。

xattr资源

开发人员 howard oakley 编写了多个应用程序和工具来帮助处理 xattrs——包括一个名为xattred （与“scattered”押韵）的编辑器，以及比较和显示两个文件之间所有 xattr 差异 的命令行工具cmpxat 。

他还编写了cirrus——一个 icloud 浏览器工具——他的博客对 icloud xattr 问题进行了多次讨论。

使用 cirrus1.0b4 直接查看 icloud 的文件和文件夹

他还有两个非常有趣的虚拟化应用程序，viable 和 liviable，它们在 apple silicon mac 上运行 macos 和 linux 虚拟机。

michael tsai 在xattr flags 和 icloud drive上有一个简短的页面，其中有类似的讨论。

apple 有一个文件元数据属性参考，但它只涵盖了 spotlight、icloud 和 core data 属性。

如果您是开发人员，还可以使用公共 swift 或 objective-c apple文件元数据 api 文档。

如果您可以阅读 c 代码，apple 的开源文件xattr_flags.c会向您展示 apple 在 2013 年添加的 xattr 标记代码的内部工作原理。

有一个关于如何在 stackexchange 上保存 xattrs 的较早的技术讨论，但它是相当技术性的，并且深入研究了 bsd 文件系统的内部工作 – 并且它比 macos 更特定于 linux ext3 文件系统。

apple 的file system programming guide是为开发人员准备的，但同样，它非常技术性且冗长 – 而且更通用。