%EF%BC%9F.png)
我使用 macOS 将一些文件复制到 HFS+，确保复制准确。根据 ，在 macOS 上，这些复制的文件的所有者为 501 ls -han。
然后我将 HFS+ USB 棒插入 Ubuntu，根据 ，文件的所有者有 1000 个ls -han。为什么？
然后，我尝试在 Ubuntu 中复制 501 个拥有的文件之一（到同一个 HFS+ 卷），确保使用cp -a.
现在，macOSls将新文件视为用户 1000 拥有...
真的吗？我不明白 —如果它甚至不保留所有者的用户 ID，那么使用cp该选项还有什么意义呢？-a我错过了什么？
更新：澄清一下，我认为我的困惑源于——在我看来——HFS 原生支持 Unix 文件权限，并且应该“正常工作”。
我最近了解到cpspreserve=timestamps实际上并不保留时间戳（创建日期被重置）。我现在是否相信它preserve=ownership不保留所有权？
答案1
安装选项
uid=n，gid=n
指定拥有文件系统上具有未初始化权限结构的所有文件的用户/组。默认值：安装进程的用户/组 ID。
501 是现代 macOS 上第一个普通用户的默认 UID。
因此，显然 macOS 不会初始化某些文件的“权限结构”。还，Apple 技术说明 #1150表明所有者 ID 的存储有一个额外的问题：
所有者ID
文件或文件夹所有者的 Mac OS X 用户 ID。 10.3 之前的 Mac OS X 版本将用户 ID 99 视为当前登录到控制台的用户的用户 ID。如果没有用户登录控制台，则用户 ID 99 将被视为用户 ID 0（root）。 Mac OS X 版本 10.3 将用户 ID 99 视为进行调用的进程的用户 ID（实际上，使其同时为每个人所拥有）。这些替换发生在运行时。磁盘上的实际用户 ID 不会更改。
然后：
笔记：
如果 fileMode 字段的 S_IFMT 字段（高 4 位）为零，则 Mac OS X 假定权限结构未初始化，并在内部使用所有字段的默认值。默认用户和组 ID 为 99，但可以在安装卷时更改。然后，该默认所有者 ID 将被替换，如上所述。
这意味着，由 Mac OS 8 和 9 或将权限字段设置为零的任何其他实现创建的文件，其行为就像为这些文件启用了“忽略所有权”选项，即使为这些文件禁用了“忽略所有权”。整体体积。
这里提到的S_IFMT是16位值的最高4位，用于存储Unix风格的权限位：3x读/写/执行，以及setuid/setgid/sticky位。常规文件需要将最高 4 位设置为特定的非零值 ( S_IFREG)，否则上述向后兼容机制将启动。
HFS+ 文件系统的结构显然开启了有时“快速而宽松”地处理文件所有权的可能性，并且您的结果表明 macOS 在某些情况下似乎正是这样做的。
对于可移动媒体，macOS 自动启用“忽略所有权”选项是有一定意义的，因为将文件写入媒体的系统可能与读取文件的系统不同，并且两者系统可能具有完全不同的 UID 映射，从而给用户带来不便。
因此，这可能只是 macOS 试图在可移动媒体上做到用户友好，并假设用户对可移动媒体的物理拥有相当于其中数据的所有权证明。
Ubuntu 的第一个常规用户帐户是使用 UID 1000 创建的，这显然是您将 HFS+ 卷安装到 Ubuntu 的帐户。
由于 Linux 创建的文件将其 UID 1000 保留在 macOS 中，这表明 Linux将要使用文件所有者 UID 填充 HFS+“权限结构”，一旦 macOS 读取它们，它们就会按预期工作。
经典的 POSIX 时间戳是：
ctime= 最后状态/元数据更改的时间mtime= 内容最后一次修改的时间atime= 最后访问时间。
创建时间（crtime , 或出生时间）不是其中之一。文件系统可能支持也可能不支持创建时间，并且其确切语义可能因文件系统类型和 Unix 风格操作系统而异。
一些文件系统驱动程序在内部处理分配创建时间，并且之后完全不可能修改crtime文件的时间：在这样的文件系统中，意外删除并从备份恢复的文件可能有其经典ctime和mtime恢复，但创建时间将反映从备份恢复的时间，因为该文件现在不再原本的，尽管它可能是一个它的精确副本。
当您复制文件时，您显然创建一个新文件：在复制操作中“保留创建时间”的想法是一个矛盾的说法。
文件系统本身可以跟踪文件的创建时间文件，但这不一定与创建时间相同文件内的数据。如果您想跟踪后者，通常需要版本控制系统或可以包含数据创建时间元数据字段的文件格式......并且使用该数据格式的所有应用程序必须就“内容”的语义达成一致。数据创建时间”的意思，否则就变得毫无意义。