☰

在 Debian 上挂载 HFS+ 文件系统时无法识别的文件

tag-icon • tag-icon mac debian hfs+
在 Debian 上挂载 HFS+ 文件系统时无法识别的文件

我正在用 Raspberry Pi 替换 Mac mini 作为文件服务器。驱动器已经转移，大部分工作正常。在设置一些作业时，我注意到rsync有人抱怨文件消失。最初，我以为文件名称中包含泰语字符或变音符号（重音符号、变音符号等 - 是的，我必须查找！）是导致问题的原因。但rsync并没有为每个这样的文件抛出错误。

不过，有许多文件（据我所知，它们的名称都包含泰语字符）被报告消失rsync。此外，当我在 MacBook 上安装 Pi 托管的驱动器时，这些文件不会显示，并且在 Pi 的控制台上，它们显示“？”表示权限、所有者、大小、日期等。问题不在于。rsync例如ls，也在抱怨它无法访问该文件。问题似乎更根本。

  • 那么，也许文件只是被搞坏了？不。当我拿起驱动器并将其直接插入 Mac mini 时，这些文件可用，我可以正常访问它们。

  • 我认为这可能与文件名的编码有关，但这并不能解释为什么这些文件对 Debian 来说成了完全的谜。

  • 文件系统似乎井然有序，我已经运行fsck.hfsplus并且报告一切正常。

  • 当我将驱动器连接到 Mac mini、共享它（smb）、将它安装在 Pi 上时，该文件在 Pi 上也显示正常。

我不知道下一步该怎么做才能进一步解决此问题。有人有什么想法吗？

[Mac mini 运行 macOS 10.13.6，Pi 运行 ARMBIAN 5.46 实验版 Debian GNU/Linux 9 (stretch) 4.14.52-v7+]

答案1

以下是我解决这个问题的方法：

  1. 在 Mac 上安装原始 HFS+ 文件系统
  2. 在 Pi 上安装一个大小相同的空驱动器，ext4 格式
  3. 在 Mac 上打开文件共享，将此共享挂载到 Pi 上
  4. 用于rsync通过网络将所有文件从 Mac 移动到 Pi

报告为消失的文件已同步到 ext4 文件系统，没有任何问题，可以正常使用。问题解决了！

但是，这并不能解释问题的根源。我进一步排除故障的唯一线索是，每个报告为消失的文件的名称都包含泰语“sara am”字符（Unicode U+0E33）。这个字符的唯一特殊之处在于它不是独立的，而是总是与另一个字符组合在一起。也许 Debian 中的 HFS+ 实现会因此而受阻？不过对我来说太技术化了，我的问题已按上述方法解决。

相关内容