关于inode与已删除文件条目在*nix系统下的技术疑问

咱们一步步拆解你问的这些点哈：

1. 这种情况的*nix术语是什么？ #

这种场景在类Unix系统里被称为**“已删除但仍被进程引用的文件”**（或者更精准地说，是“未链接但仍有文件描述符关联的inode”）。本质上是*nix文件系统“文件名与数据分离”设计带来的典型现象。

2. 核心逻辑拆解 #

先搞懂*nix文件系统的基础逻辑：

• 文件的目录条目（就是你在文件夹里看到的文件名）只是一个“映射指针”，负责把文件名指向对应的inode编号；
• inode才是存储文件元数据（大小、权限、数据块位置等）的核心结构，实际文件数据存在数据块里，inode记录着这些数据块的地址；
• 当你执行rm命令删除文件时，只是删除了目录条目，同时把inode里的「链接计数」减1。只有当两个条件同时满足时，内核才会彻底释放inode和对应数据块：
  • inode的链接计数降到0（没有硬链接指向它）；
  • 没有任何进程持有该文件的打开文件描述符。

你提到的场景正好是：进程先打开了/dev/ashmem/下的文件，拿到了文件描述符，之后目录条目被删除，inode的链接计数变成0，但因为还有打开的文件描述符，内核不会回收inode和数据块。这时候外部看不到这个文件（目录里没条目了），但持有描述符的进程还能正常读写它，直到进程关闭描述符，内核才会真正清理资源。

3. 结合Android的ext4文件系统 #

ext4完全遵循这个*nix设计：在文件被删除但仍有进程打开时，inode的结构会完整保留所有必要的元数据（包括数据块指针），不会立刻重置inode内容——不然持有文件描述符的进程就没法继续操作了。只有当最后一个文件描述符被关闭，链接计数也为0时，ext4才会标记inode为可用，后续可能会覆盖它的内容。

4. 为什么删除文件条目后还存在打开的文件描述符？ #

这是*nix系统的正常设计，和硬/软链接没关系！举个日常例子：你在一个终端用tail -f /var/log/test.log实时查看日志，另一个终端把test.log删了，这时候tail进程依然能继续读取文件内容，直到你终止tail进程（关闭文件描述符）。原因很简单：进程打开文件后，是直接和inode交互的，目录条目只是“找到inode的入口”，一旦打开成功，就不再依赖目录条目了。

内容的提问来源于stack exchange，提问作者Zoso