从 PC 上的家目录开始谈起

在鸿蒙 PC 上，无论是打开 HiShell 还是打开文件管理器，进入到的第一个目录都是用户的家目录。这个目录在应用沙箱视角下的路径是 /storage/Users/currentUser。当用户在 HiShell 里面访问 $HOME 变量的时候，指向的正是这里。

这个看似平常的家目录背后，隐藏着一个巨大的技术背景——它并非建立在常规的 EXT4 或 F2FS 文件系统之上，而是构建在 HMDFS（HarmonyOS Distributed File System，鸿蒙分布式文件系统） 这一文件系统之上的。

什么是 HMDFS？

首先需要澄清的是，HMDFS 并不是 HarmonyOS 的私有特性，它在 OpenHarmony 中同样有完整的实现。

HMDFS 是 OpenHarmony 分布式特性的基石功能之一。它的核心作用是跨设备文件共享。简单来说，当你有多台鸿蒙设备（如 PC、手机、平板）登录同一个账号并组网时，HMDFS 能够让这些设备之间的文件访问像访问本地目录一样透明。

在 OpenHarmony 的架构设计中，系统默认将用户的公共数据区和家目录挂载到 HMDFS 上。这意味着你在 PC 家目录下的一份文档，在底层正通过分布式软总线与你的其他设备进行无缝同步。

“水土不服”：HMDFS 对底层开发的硬伤

对于习惯了标准 POSIX 语义的程序员来说，HMDFS 为了兼容分布式特性和移动端需求，在语义上做了大量删减。这导致了许多底层工具在 $HOME 目录下运行时会产生严重的“水土不服”：

1. 文件名大小写不敏感：在 HMDFS 下，a.txt 和 A.txt 会被视为同一个文件。如果你尝试解压一个包含类似命名冲突的压缩文件，文件会发生互相覆盖。
2. 对文件属性（DAC）的操作支持不完整：假如你在这上面执行 chmod 0777 这种修改权限的操作，系统虽然返回成功（Return 0），但实际表现并不符合预期。
3. 不支持 UDS（Unix domain socket）文件：如果你尝试在 $HOME 下监听一个 UDS 文件（常用于本地进程间通信），系统会直接报错。
4. 不支持硬链接：尝试创建硬链接会触发 Operation not permitted。

规避手段：寻找“常规”文件系统

如果你正在移植的软件对 POSIX 语义有严格要求，那么 $HOME 目录显然不是一个好的选择。

在应用沙箱内部，并非所有目录都是 HMDFS。 为了规避上述限制，开发者可以将数据存放在应用私有的数据目录下，例如：/data/storage/el2/base/files。该目录位于设备的本地常规文件系统上，提供完整的 POSIX 支持：大小写敏感、支持硬链接、支持 UDS。

但这种规避手段是一把双刃剑，存在两个致命伤：

• 物理层面的“孤岛化”：这是最大的工程阻力。虽然每个应用内部都有 /data/storage/el2/base/files，但由于 Mount Namespace 的物理隔离，它们实际上是互不相通的独立沙箱。你在 HiShell 里面创建的文件，在 IDE 里面根本找不着。这种“路径重名，空间隔离”的怪象，会让传统的本地开发链条彻底“断片”。
• 生命周期受限：作为应用私有的“自留地”，该目录的数据生命周期与应用绑定。一旦应用被卸载，目录下的源码或数据也会随之“灰飞烟灭”，极不适合存放需要长期固化的项目代码。

总结

HMDFS 是一项强大的分布式特性，但对于鸿蒙 PC 的底层开发而言，它并不适合程序员用来“干活”。

• 如果你需要跨应用协作，你不得不迁就 HMDFS 的限制，并针对性地修改自己的工程实现（如规避文件名冲突）。
• 如果你的项目是自包含、对 POSIX 要求极高的，那么考虑使用私有路径，但必须接受数据在不同工具间“老死不相往来”的现状。