前言

文件目录，即我们常说的“文件夹”。通过层级结构帮助使用者快速定位所需文件，同时让操作程序能够基于方法名实现按名存取。在实际使用中，使用者常面临以下痛点：

• 大量文件混杂导致查找效率低下。
• 不同使用者之间出现文件名冲突。
• 共享文件时难以同步删除或防止误删。
• 磁盘 I/O 次数过多导致访问慢。

这篇文章从操作目录的实现原理，并提供针对上述痛点的高效管理方案。

文件目录概述

文件控制块

在操作程序内部。目录是一种有结构的文件由一条条目录项组成，每个目录项对应一个文件或子目录。

FCB 包含三类信息：

• 基本信息：文件名、物理地址、逻辑/物理结构等。
• 存取控制信息：读/写权限等安全属性。
• 使用信息：创建时间、最终修改时间等元数据。

使用者痛点：在大型程序中。单纯依赖完整 FCB 会导致每个磁盘块只能容纳少量目录项，从而增加搜索时的磁盘 I/O。

目录的基本操作

Pain Point: 手动执行这些操作时特别是批量重命名或迁移，会因方法错误而导致数据丢失或无法定位。不过，建议使用脚本或批处理工具统一管理，以降低人为错误概率。其实，

常见目录结构及其痛点分析

单级目录结构

A single flat table holds every file’s FCB.

• 优点：实现极其简单。天然支持按名存取，
• 缺点： 不允许同名文件；因为使用者增多，搜索效率急剧下降；不适合多使用者环境，
• Pain Point： 公司内部经常出现“同事上传同名报告被覆盖”的尴尬情况，需要额外命名规范才能规避。话说回来，

MFD记录每个使用者的 UFD位置； UFD 中保存该使用者所有文件的 FCB。

• 优点： 不同使用者可拥有相同名字的文件，实现基本隔离与访问控制。
• 缺点： 每个使用者只能在自己的根层级组织文件。缺乏子分类功能，管理灵活性不足。按理说，
• Pain Point： 项目组成员需要频繁在同一层级中区分不同模块的文档。却只能靠手工前缀或后缀来实现，易产生混淆。

树形目录结构

The modern OS default – directories can contain sub‑directories forming a tree.

• Pain Point 1 – 方法过深导致 I/O 高耗费： 从根到目标若有 n 层。每层都要一次磁盘读取，累计 n 次 I/O。方法是利用“当前工作目录”缓存已打开层级，从而只读取剩余层次。
• Pain Point 2 – 共享困难： 树形结构天然是一对一映射。 同一份数据只能拥有唯一方法，不利于多人协作共享同一个文档版本。 后续章节将介绍 DAG 方案缓解此问题。
• Pain Point 3 – 权限粒度不细： 子树整体继承父节点权限。若需要对单独子项做例外设置，需要额外 ACL 或符号链接机制。老实说，
• Pain Point 4 – 移动/重命名成本高： 跨层级移动会触发多个方法更新和缓存失效。需要谨慎规划层级深度，
• You can mitigate most of se issues by:
  • - 定期使用软链接或快捷方式建立跨树共享入口；
  \
  • - 将热点子树设为“挂载点”，提前加载到内存；
  \

当前工作目录与磁盘 I/O 调整示例

If a file resides at “/project/docs/spec.pdf”,without caching you’d incur 5 disk reads. By keeping “/project/docs” as current directory in memory。only final level requires an extra read – cutting I/O by up to 80%.

无环图 共享型 目錄 結構

在传统树形基础上允许不同父节点指向同一个子节点，从而形成有向无环图。这为 “多使用者共享同一文档” 提供了天然支撑。

• **优势**的观点是。同一份数据可以通过多个方法访问，实现灵活共享而无需复制副本。
• 再看**挑战**，必须维护引用计数。否则删除任意方法时可能误删仍被其他方法引用的数据。

共享计数器机制

• 删除某个方法仅将该方法对应的计数器减1；
• 当计数器归零时才真正回收硬盘空间；

四种典型结构对比

​ ​ ​ ​ ​ ​ ​ ​

​​ ​​

​​

​​​

​

...

目錄結構	是否允許重名	是否支援共享	主要缺點
單級目錄	不允許	不支援	重名衝突、擴展性差
二級目錄	同用戶可重名、跨用戶不允許	不支援	缺乏子分類、靈活性低
樹形目錄	同層可重名、跨層不允許	難以直接共享，需要額外機制	複雜度升高、I/O 多次
無環圖	任意路徑均可重名