帮你将Workbuddy"存储空间"应用数据无损迁移到非系统盘——一次失败迁移的复盘

作者按：本文记录一次真实的"Workbuddy"存储空间"应用数据目录从 C 盘迁移到 E 盘"全过程。重点不是"搬文件"本身，而是为什么搬——尤其是为什么在应用运行时硬搬必翻车，以及如何用 Windows 目录联接（Junction）+ robocopy 做到零风险、可回滚、应用无感知的迁移。案例以 AI 编程助手 WorkBuddy 为例，方法对所有"数据目录默认落在 %USERPROFILE%"的桌面应用通用。

摘要（TL;DR）

• Workbuddy"存储空间"应用数据目录默认在 C:\Users\<用户名>\.workbuddy，C 盘吃紧，需要挪到 E:\<自定义>\.workbuddy。
• "自动迁移"脚本翻车了：robocopy 因权限选项出错、切换因备份已存在中止、回退因文件被占用三次移动失败，C 盘留下 5 份半截副本。
• 根因只有一个：应用还在运行时，强行移动/重命名它正在用的文件，必然失败。
• 正确做法：先完全退出应用 → 用 robocopy 把活目录完整同步到目标盘 → 把历史残留副本"只补不覆盖"地合并进去防丢数据 → 校验 → 移走活目录 → 在原位置建目录联接（Junction）指向新盘。
• 事后再通过联接验证读写确实落到新盘，并回收 C 盘约 2.4 GB 的备份空间。
• 全文附可直接运行的 PowerShell 脚本与验证命令，复制即用。

一、背景：为什么要把数据搬出 C 盘

很多桌面应用（IDE、AI 助手、笔记、同步盘）都会把数据目录放在当前用户的家目录下，例如：

随着使用时间变长，这里面会累积数据库、向量索引、缓存、附件、日志等，轻松涨到几个 GB。一旦 C 盘（系统盘）空间紧张，最直接的想法就是："把这个目录整体挪到空间充裕的 D/E 盘。"

看似简单，但挪一个"正在被应用使用"的目录，比想象中危险得多。下面是我踩过的坑。

二、第一次踩坑：自动迁移为什么失败了（复盘）

我最初尝试用一段自动化脚本做迁移，过程留下了一堆日志。把它们按时间拼起来，失败链条非常清楚：

结果：C 盘残留下 .workbuddy（活的）、.workbuddy_old、.workbuddy_bak、两个带时间戳的 _old 副本，共约 2.4 GB；而 E 盘那份拷贝是"昨天 17:51 的快照"，之后应用一直在 C 盘写新数据，所以 E 盘那份已经过期。

如果这时候图省事，直接把 E 盘那份旧拷贝顶上去——会丢数据（活目录可能已被移走部分文件，且 E 盘快照过期）。这就是为什么"看似搬完了，其实半路翻车"。

三、核心认知：应用运行时，文件不能"硬搬"

复盘后一句话总结根因：

只要应用进程还活着，它打开的文件（尤其是 SQLite 的 -wal/-shm、日志、锁文件）就无法被可靠地移动或重命名。任何"先移走再指过去"的操作，都会在这一步失败。

所以迁移的硬前置条件只有一个：操作前，必须完全退出应用（托盘退出 + 任务管理器确认无残留进程）。不满足这个条件，任何脚本都应该主动拒绝执行——这正是后文脚本第 1 步做的事。

四、方案：用目录联接（Junction）做无损迁移

4.1 什么是 Junction

Windows 的 NTFS 支持"重解析点（Reparse Point）"，目录联接（Junction）是其中一种：它让一个路径"伪装"成另一个真实目录的入口。

对应用来说，C:\Users\<用户名>\.workbuddy\xxx 和 E:\<自定义>\.workbuddy\xxx 是同一个东西。应用在 C 盘原路径读写，数据实际落到 E 盘，应用本身完全无感知、无需任何配置改动。

4.2 为什么选 Junction，而不是别的方案

注意：Junction 只支持本地路径（不能跨到网络盘 \\server\share）。本文目标是本地 E 盘，完美契合。

4.3 整体流程设计（每一步都可回滚）

1. 同步：robocopy 把活的 C 盘目录完整覆盖同步到 E 盘（用 /COPY:DAT，避开权限坑）。
2. 合并残留：把此前失败留下的历史副本，以"只补不覆盖（更旧的不动）"方式合并进 E 盘，防止丢被移走的旧文件。
3. 校验：确认 workbuddy.db、settings.json 等关键文件都在目标盘。
4. 切换：把活的 C 盘目录移走备份（不是删除），在原位置建 Junction 指向 E 盘。
5. 验证：通过 Junction 路径读写，确认确实落到 E 盘。

任一步失败都会自动回滚、不动原数据，日志落盘。

五、实战：完整 PowerShell 脚本

把下面脚本存成 migrate-to-other-drive.ps1。它默认把 %USERPROFILE%\.workbuddy 迁到 E:\HOU\.workbuddy，你可按需改 $SourceDir / $DestDir 两个参数。

六、操作步骤

1. 完全退出目标应用：右键托盘退出；打开任务管理器，确认没有 WorkBuddy / CodeBuddy（或你自己的应用）进程残留。
2. 打开 PowerShell（无需管理员）：
   • Win + R → 输入 powershell → 回车。
3. 运行脚本（若被执行策略拦截，加 -ExecutionPolicy Bypass）：
4. 看到绿色 SUCCESS 即完成；重新打开应用，它已透明改用新盘。
5. 若脚本报告 App still running —— 说明还没退干净，关掉再跑一次即可（这是保护机制，不是报错）。

七、如何验证迁移成功

重开应用后，用下面几条命令确认"联接建好了、读写真的落到新盘"：

三条都符合，就说明迁移彻底生效：应用在新盘读写，C 盘原路径只是一个"指路牌"。

真实案例里的验证结果：

八、收尾：回收 C 盘备份空间

迁移成功后，C 盘上这些备份副本已不再被使用，确认应用正常用几天后再删除（不要删 E:\<自定义>\.workbuddy 和 C 盘的 Junction 本身）：

本案例合计可回收约 2.4 GB。删除前务必确认：C:\Users\<用户名>\.workbuddy 仍是 Junction（见第七节），且应用在 E 盘工作正常。

删除用资源管理器或 Remove-Item 均可；这些是普通文件夹，移入回收站更稳妥。

九、避坑清单（Checklist）

• ✅ 操作前一定完全退出应用。文件被占用时移动/重命名必败，这是 90% 迁移失败的根因。
• ✅ robocopy 用 /COPY:DAT，别用 /COPYALL。后者要"安全描述符/审核"等特殊权限，普通用户会直接报错退出，导致拷贝不完整。
• ✅ robocopy 加 /XJ，避免把已有的联接/符号链接又拷一遍造成循环。
• ✅ 切换前先校验关键文件（数据库、配置、身份文件）都在目标盘，再动活目录。
• ✅ 移走 ≠ 删除：先把活目录改名为备份，建好 Junction 并验证通过后再考虑清理，留好回滚余地。
• ✅ Junction 比符号链接更适合普通用户：免管理员、本地盘稳定；但它不支持网络路径。
• ✅ 历史残留要"只补不覆盖"合并（/XO）：防止把一个"被移走过文件"的旧副本覆盖掉新盘里的完整数据。
• ❌ 不要在应用运行时跑任何移动/重命名脚本。
• ❌ 不要直接拿"过期快照"顶替活目录（会丢数据）。

十、总结

把应用数据从系统盘搬到数据盘，本质不是"复制粘贴"，而是一次需要停机窗口 + 可靠同步 + 可回滚切换的小运维。Windows 的目录联接（Junction）是这里最省心的关键技术：它让应用"以为自己还在 C 盘"，数据却安静地躺在 E 盘，无需改动任何配置。

记住那句核心经验：应用活着，文件就别硬搬；先退干净，再用 robocopy + Junction，稳。