数据持久化

TIP

Scoop 最强大的特性之一就是数据持久化：卸载应用时保留用户数据，重装后自动恢复
abyss 使用了 Persist + Link 两种机制，以 Link 为主

Persist

通过在清单中定义 persist 属性可以持久化数据
但只能持久化 应用安装目录 中的数据
在 abyss 中，persist 的使用受到严格限制
- 当需要定义持久化数据时，会优先使用 link
- 参考: Persist vs Link

参考: Persist 机制详解

Link

大多数现代应用将数据存储在 Windows 标准目录，而非安装目录
- C:\Users\<username>\AppData\Roaming\xxx
- C:\Users\<username>\AppData\Local\xxx
- C:\Users\<username>\Documents\xxx
- C:\Users\<username>\xxx
- ...
由于 Persist 无法持久化这些目录，abyss 使用 Link 机制，在数据的原始位置创建文件系统链接，将其关联到 Scoop 的持久化目录

参考: Link 机制详解

Persist vs Link

Link 的优势

统一的链接规则

Scoop 的 Persist 允许自定义目标目录，这提供了灵活性，也带来了一些思考：
- 这个应用的数据应该放在哪个目录下？
- 目录命名应该用什么格式？
- 不同应用之间如何保持一致？
以部分官方清单为例，可以发现它们的处理方式各不相同
- extras/bucket/vscode.json
  - $env:Appdata\Code => data\Code
  - $home\.vscode => data\.vscode
部分应用也会因为 Persist 的局限性受到影响:
而 Link 使用了统一的 Link 规则，让清单编写者只需关注数据目录本身
- 降低心智负担：不需要思考目标目录的命名和结构
- 提高一致性：所有应用的数据目录都遵循相同的规则
- 便于维护：目录结构有规律可循，方便管理和查找

直接链接 vs 间接实现

由于 Persist 的局限性，官方清单针对数据存储在其他位置的应用，发展出了两种变通方案：

变通方案 1：脚本复制

通过脚本将数据复制到安装目录，再进行持久化
问题：
- 缺乏实时性：数据同步只在安装和卸载阶段进行，而非实时同步
- 增加复杂性：清单编写者需要编写额外的脚本逻辑（如 Copy-Item）

变通方案 2：命令行参数

通过参数（如 --user-data-dir）重定向数据存储位置
问题：
- 更新风险：应用更新时，参数可能被忽略或重置，导致数据回退到默认位置
- 应用限制：要求应用必须支持特定参数，适用性受限

这两种变通方案都是对 Persist 局限性的妥协
而 abyss 的 Link 机制从根本上避免了这些问题 (在数据原始位置创建文件系统链接)
- 实时同步：数据变更立即生效
- 简单直接：无需额外脚本或参数
- 标准目录结构：应用始终看到原始的数据目录

Link 的局限

尽管 Link 机制解决了 Persist 的许多问题，但它也有一些局限：

备份与迁移问题：备份 Scoop 到新电脑时，已安装的应用数据没有 Link
命令限制：无法使用 scoop reset 命令

TIP

以上两个局限都可以通过以下命令来解决：

scoop update --force <app> 强制更新应用（重建 Link）
scoop cleanup * 清理旧版本