修改 2040 年后 macOS 文件的创建/修改日期

Question

在我的 Synology NAS 中，我有一个 APFS 共享文件，这些文件在不同操作系统之间来回传输了数十年。

• 原始系统：可能是 ext4 文件系统和 Synology 托管的 NFS 挂载，几年前（各种系统，Linux/Windows）
• 当前系统：EXT4 文件系统，带有 Synology 托管的 AFP 挂载（到 macOS 10.15 系统，尽管我怀疑这是否重要）

对于最初通过 NFS 复制的文件，现在通过 AFP 托管的文件，所有文件日期似乎都有一定的偏移。我可以看一下日期时间偏移量，但是我可以使用一个确定的数字吗? （还有一种使用 GetFileInfo 之类的东西来解析/修改时间的简单方法？）

• 作为参考，我有一份 iTerm2-3_2_6.zip 的副本，日期为“2039-01-22 08:25:17”。我可能会将其映射到 2019-01-21（3.2.7 的发布日期），这意味着 20 年的偏移量。
• 我能想到的最接近的事情是从 2001-01-01 而不是 UNIX 1970-01-01 开始的 macOS 纪元，但那是30-年偏移量。
• 还有“year 2038 problem”，一些软件可能会通过 32 位溢出来支持 2038 年后的日期时间，但我至少有一个文件日期为“2031-08-10”，因此似乎不太可能。

Answer 1

这似乎与 32 位和 64 位溢出有关，在这个复杂的存储堆栈中的某个地方；日期时间 + 错误偏移加起来的方式始终接近 2^31，尽管我无法找到任何清晰的模式。

此外，我注意到我的 Synology 系统使用 eCryptFS 时出现了奇怪的行为，这在批量完成时似乎会滞后元数据更新。 （特别是，我怀疑某些 eCryptFS/Synology 元数据翻译不正确，或者只是从未写入磁盘。）

---

无论如何，我基本上写了一个 Python 脚本，它执行以下操作：

• 检查 os.stat() 是否报告了比 2030 更新的 atime/mtime
• 检查 atime 和 mtime 是否更新；如果它们不同，则会出错
• 将两个时间都向后调整 632599096 秒（偏移量基于比较我在两个系统之间发现的共同文件的副本）。

需要注意以下警告：

• macOS 的 GetFileInfo/SetFile 实用程序仅支持 32 位日期时间，因此您通常应避免使用它们（即使只是为了验证元数据更新）。
• Synology/eCryptFS 加密中的某些内容变得非常慢，因此在几十次元数据更新后，更新将不再可见（即使从 shell 调用 sync 后）。但是如果你给它一些时间，你会看到更正的 atime/mtime 变化。
• 特定于操作系统的os.stat 字段ctime 确实跟踪元数据更新时间。而且似乎没有办法手动设置它（也不需要，因为这在任何 GUI 中都看不到）。

元数据更新缓慢 + GetFileInfo 报告错误时间的组合使这令人难以置信的沮丧，直到我弄清楚两者。实际上，这意味着您必须一次测试几个文件的元数据更新，然后您的大批量执行只能在几个小时后验证（我等了一天）。

这应该是一篇博客文章，很好摆脱。