自从 0.9.18 版本起，CloudDrive2 支持云盘文件的本地缓存，用户可以在本地存储中划分一定配额，让 CloudDrive2 用来进行文件缓存。缓存语义如下：

云盘文件和本地文件建立一一映射。本地缓存以 HASH_64_HEX.cache 命名。哈希值计算方法目前不详，非直接从云盘获取的 SHA256，也并非云盘文件添加前缀、尾缀之后的 SHA256.

经过二进制对比，发现 CloudDrive2 会给文件添加前缀

00000000: 4344 4643 4143 4845 0200 0000 5876 6300 CDFCACHE....Xvc.

00000010: 0000 0000 0100 0000 0000 0000 0000 0000 ................

00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................

00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................

以及后缀

00637690: **** **** **** **** 0000 0000 0000 0000 *******.........

006376a0: 5876 6300 0000 0000 Xvc.....

前后缀用来增加 cache 文件的辨识度。此外，文件哈希计算基于某种静态算法，和客户端、网盘提供商并不绑定，因此可以夸网盘、跨用户、跨客户端使用。

目前来看，该文件是一个稀疏文件。当用户首次读取云盘上的某个文件时，CloudDrive2 会根据某种哈希算法创建与之对应的本地缓存文件。该缓存文件在初始阶段属于全 hole 文件，即所有的块都是 0000. 随后，当具体的数据从云端读被读取出来之后，CloudDrive2 会同步地在该文件的对应偏移处进行写入该数据。用户再次读取该文件偏移据时，CloudDrive2 将直接以缓存文件的内容进行反馈。

因此，在不依赖文件系统语义的情况下，理论上 CloudDriv2 应该会维护一个本地的文件 bitmap，用来记录缓存文件里哪些是真实的块，哪些是 hole. 然而 CloudDriv2 声称该缓存文件可以随意转移，这意味着该 bitmap 有可能事实上并不存在。如果确实不存在，CloudDrive2 是如何区分 hole 与真实的 0000 记录的呢？毕竟很多 copy 工具会在拷贝时把 hole 彻底 0 化，变成真实的 0 块。所以笔者猜测，随意转移这句话在工程上通常隐含前提：用能保稀疏的方式迁移。当然，纯单机、本地使用在没有 bitmap 的情况下问题不大，因为 CloudDrive2 可以调用 lseek(SEEK_HOLE) 找 hole.

此外，如果某文件在云端被修改，但是云盘没有通知 CloudDrive2 客户端要同步缓存，这也会导致严重的数据不一致问题。

在上述两个问题研究清楚之前，该缓存方案应该仅被谨慎地应用于只读类型的文件。