[Bug] 更新器以"把整个安装目录改名到父目录"作为升级第一步，在 Windows 上极易失败且无法自诊断

[Joker-Principal]

摘要

DSH 桌面端更新时，安装器的第一个动作是：

MoveFileExW(
    Source      = <install-dir>,
    Destination = <parent-dir>\dsh.old-{GUID}
)

即把整个安装目录改名，并在安装目录之外的父目录里创建 dsh.old-{GUID}。在 Windows 上这个前提过于脆弱：只要安装树里任意一个子目录被任何进程打开（文件监视器、编辑器、杀软扫描、Explorer 窗口、甚至某个进程的当前工作目录），这次改名就会失败，返回 ERROR_ACCESS_DENIED (5)。失败后更新器只在本地留一份日志，用户侧表现为"点了更新，但应用再也没重启"。

本次报告基于连续 5 次、跨 8 天的失败记录。

环境

• 产品：DSH 桌面端（当前 0.2.x，待安装 deepseek-harness-0.2.1-rc.3-win-x64.exe）
• 安装路径：非默认路径（用户指定，下称 <install-dir>，其父目录为 <parent-dir>）
• 更新器缓存：%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater
• app-update.yml：provider: generic、channel: nightly、isAdminRightsRequired: false
• OS：Windows 10.0.26300，NTFS

现象

用户在应用内触发更新 → 安装包成功下载（289 MB，pending\deepseek-harness-0.2.1-rc.3-win-x64.exe 至今仍在缓存里）→ 应用按预期退出 → 安装器开始执行 → 改名失败 → 应用没有起来，也没有任何可见的错误提示。

%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\ 下留了 5 份内容几乎相同的 directory-failure-<timestamp>.log（8 天内，两次尝试分别产生 3 份和 2 份）。

证据

其中一份 directory-failure-*.log：

Operation: MoveFileExW
Windows error: 5 (拒绝访问。)
Source: <install-dir>
Destination: <parent-dir>\dsh.old-{GUID}
Restoration error: 0
Time: <timestamp>
Windows: 10.0.26300
Attempts:
backup: Windows error: 5
backup: Windows error: 5
…（共 10 次）

Restoration error: 0 说明失败后安装器成功把目录名改了回来，因此安装本身没有被破坏 —— 但更新也就此中止。

分析：这个前提为什么脆弱

1. 改名整棵目录，把"树里任何一处被打开"变成致命条件。

Windows 上重命名目录的语义是（本机实测，MoveFileExW 返回码）：

场景	结果
无任何打开	OK
某进程持有子目录句柄（fs.watch / .NET FileSystemWatcher / 裸 CreateFileW）	FAIL，win32 = 5
裸 CreateFileW，且已授予 FILE_SHARE_DELETE	FAIL，win32 = 5
某进程的 CWD 在子目录里	FAIL，win32 = 5
句柄在被改名目录本身	OK

也就是说：授予删除共享权也救不了，只要有任意一个后代目录句柄存在，改名就报 5。而现实里这类句柄随处可见 —— 本次的直接触发者是 VS Code：它在窗口加载工作区后会把 PATH 里每个目录都开一个非递归 watcher，而 DSH 的 <install-dir>\resources\runtime\cli\bin 正好在 PATH 上（dsh.cmd 就在那里）。实测 trace 日志确认了该路径被 watch。

对安装器的含义是：失败条件不受自己控制、范围无界（任何监视器/编辑器/杀软/Explorer 都可能触发），且错误码 5 与"权限不足"完全无法区分，自诊断极难。

2. 在安装目录之外创建目录，把父目录当成了自己的地盘。

dsh.old-{GUID} 落在 <parent-dir> —— 这是用户的目录，不属于应用。由此带来的情况：

• 父目录可能不可写（只读、ACL 受限、网络盘、其他用户所有）→ 同样是错误 5，但原因完全不同；
• 若安装路径是卷根（X:\），旧目录会落到 X:\dsh.old-*；
• 若父目录是共享工作区/仓库，会污染用户的版本控制或搜索索引；
• 同一父目录下多份安装、或多用户共享该目录时，命名与清理都容易互相干扰；
• 中途崩溃可能留下 dsh.old-* 垃圾目录（本次失败路径上靠 Restoration 回滚躲过了，但那是另一条路径）。

3. 失败只写进 installer-logs，用户完全不知道发生了什么。

用户能看到的现象只有"更新后应用没重启"。要定位到 MoveFileExW / 错误 5 需要自己去翻 %LOCALAPPDATA% 下的隐藏日志；本次排查中，日志里也没有任何"谁在占用"的信息。

4. 重试对"持续存在"的占用没有作用。

占用条件是持续的（只要那个 watcher 活着就一直成立），同一次失败里连续 10 次重试只会留下 10 条相同记录。

综合来看：8 天内 5 次更新尝试全部失败，用户始终停留在旧版本，289 MB 安装包长期滞留在缓存里；而"拒绝访问"的报错指向权限、实际原因是树里有句柄，用户会在权限、杀软、路径等方向上反复误判；这个前提对任何"在被打开目录树上改名"的升级方式都成立。

修改方向

如果可能，希望升级流程不要以"把整个安装目录改名"为前提 —— 用逐文件替换，或"版本化目录 + 指针切换"，能把失败面从整棵树缩小到单个文件。

[Joker-Principal]

经过检索发现别的讨论也遇到这个问题，但很可能由于目录被监听占用这个苛刻的复现条件，没有发现真正的原因就结束了讨论，所以这里开一个新讨论。

[wannaknowhys]

补充一个不需要任何第三方软件的触发条件：只要有一个资源管理器窗口停在安装目录的子目录上，就足以复现；而且占用者是否共享 FILE_SHARE_DELETE 不影响结论。这一点在 0.2.1-rc.3 → 0.2.1-rc.5 的升级中仍可复现。

现场

• 安装目录为自定义路径（非默认 per-user 路径），应用内点更新 → 应用退出 → 安装器进入 backup 阶段。
• 没有杀软实时防护，没有编辑器 / 文件监视器打开安装树；唯一相关的是一个 Explorer 窗口浏览着安装目录下的一个子目录。
• 结果与主贴一致：MoveFileExW(<install> → <install>.old-{GUID}) 连续 10 次 Windows error: 5，Restoration error: 0，回滚后旧版本被拉起，版本不变；installer-logs\directory-failure-*.log 与主贴同格式。

实测矩阵

新建目录逐项隔离测试（MoveFileExW(parent, parent + ".old", 0)，Windows 10/11 + NTFS）：

占用方式	句柄 share	结果
无任何句柄	—	OK (0)
句柄在被改名目录自身	READ|WRITE|DELETE	OK (0)
句柄在被改名目录自身	READ|WRITE（无 DELETE）	32（见 #10192）
进程 CWD 在被改名目录自身	—	32
句柄在子目录	READ|WRITE	5
句柄在子目录	READ|WRITE|DELETE	5
句柄在子目录内的文件	READ|WRITE|DELETE	5

两点补充：

1. 后代（子目录 / 文件）句柄即使授予 FILE_SHARE_DELETE，整树改名照样返回 5；只有"被改名目录自身"的句柄共享删除时才不阻塞。所以"共享删除就不会挡"的直觉只对自身句柄成立。
2. 错误码能区分三类原因：5 = 树内（后代）有句柄；32 = 自身是 CWD，或自身句柄未共享删除。看到 5 不应该往"权限不足"方向排查。

最小复现（无第三方工具）

Add-Type -Namespace W -Name D -MemberDefinition @'
[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
public static extern bool MoveFileExW(string a, string b, uint f);
[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
public static extern Microsoft.Win32.SafeHandles.SafeFileHandle CreateFileW(
  string n, uint a, uint s, IntPtr sa, uint c, uint f, IntPtr t);
'@
New-Item -ItemType Directory -Force C:\t\parent\child | Out-Null
# share=3 (READ|WRITE)，对子目录持句柄
$h = [W.D]::CreateFileW('C:\t\parent\child', 0x80000000, 3, [IntPtr]::Zero, 3, 0x02000000, [IntPtr]::Zero)
[W.D]::MoveFileExW('C:\t\parent', 'C:\t\parent.old', 0)   # False，GetLastError() = 5
$h.Dispose()
[W.D]::MoveFileExW('C:\t\parent', 'C:\t\parent.old', 0)   # True

把 share 改成 7（READ|WRITE|DELETE）结果不变。真实升级里，对应的占用者就是停在安装目录任一子目录上的 Explorer 窗口（或任何对该子目录 fs.watch / 预览 / 索引的进程），表现与上表一致。

对修复与测试的影响

1. 影响面比"第三方 watcher 才会触发"大得多：Explorer 是系统自带、日常就在用的程序，任何用户点开过安装目录里的文件夹都可能中招，不需要装任何额外软件。
2. 固定 11.25 s（10 次 × 250 ms 递增）的重试对持续型占用无效，还是需要"失败时定位占用者"或"降级为就地发布"（Windows 自动更新静默失败：安装目录改名被拒（ERROR_ACCESS_DENIED 5），更新永远装不上 #10514 的补丁思路）。注意：Restart Manager 按文件注册，纯目录句柄（例如 Explorer 浏览一个空子目录）抓不到，可能得枚举目录句柄或直接检测 Explorer 窗口，并把提示写成"请关闭正在浏览安装目录的资源管理器窗口"。
3. 回归 fixture 必须持有后代句柄：对安装目录自身持句柄不会复现（见上表），而且测试要覆盖 FILE_SHARE_DELETE 组合，否则会误判"修好了"。

---

English summary. A plain Explorer window browsing a subdirectory of the install directory is enough to make the whole-tree rename fail with ERROR_ACCESS_DENIED (5) — no antivirus, editor, or watcher required. Measured with MoveFileExW(parent → parent.old): any descendant handle (subdirectory or file) blocks the rename even with FILE_SHARE_DELETE; a handle on the renamed directory itself (sharing delete) does not; a process CWD on it returns 32. So 5 means "a descendant handle exists", not "permissions". Minimal P/Invoke repro included. This widens the blast radius and means a regression fixture must hold a descendant handle, not one on the install directory itself.

Related: #11527 shows the same Windows rule for dsh's own file watcher, #9989 covers the missing locker diagnostics, #10514 proposes the in-place publish fallback.

[Howard20181]

补充一份独立复现，给出“任意子目录被打开即失败”的精确规则，以及一个属于产品自身的占用源（Windows 10.0.26300，DSH 0.2.1-rc.3 → 0.2.2-rc.1）。

1. 句柄矩阵

在 a\b\c 上持有一个带 FILE_SHARE_DELETE 的目录句柄：

改名目标	结果
a\b\c	成功
a\b	错误 5
a	错误 5

在 a\b\c 内持有一个文件句柄（无论是否共享 delete）：c、b、a 全部错误 5。

也就是说：句柄所在目录本身可以改名，但它的所有祖先都不能。安装树实测完全一致——resources\runtime\cli\bin 可改名，cli / runtime / resources / <install-dir> 全部错误 5。这条规则解释了报告里 Source: 为什么总是安装根目录而非真正被占用的子目录，也与 #11119 评论中“占用者是否共享 FILE_SHARE_DELETE 不影响结论”吻合。

2. 一个产品自身的占用源

Manage dsh Command… 在 Windows 上把 <install-dir>\resources\runtime\cli\bin 写进用户 PATH。任何会扫描 PATH 的程序（编辑器/IDE 的终端环境解析、索引器、输入法组件等）都会打开这个目录并长期持有句柄。实测整树只有一处句柄：

handle64 -nobanner "<install-dir>"   → 单个 File 句柄指向 <install-dir>\resources\runtime\cli\bin

同时逐文件用 FileShare.None 打开全树 7814 个文件全部成功，Process Explorer 的文件句柄视图也看不到它——占用对象是目录句柄。

这正好补上 #9989 说的“失败报告里没有占用者诊断”这一环：只查文件锁永远查不到。当前安装器的运行检测只覆盖 <install-dir>\DeepSeek Harness.exe，其余占用者既不被检测也不被报告，用户侧只看到“点了更新但版本没变”。

3. 建议

1. 把 CLI 启动器目录移出安装目录（启动时解析当前安装路径），消除“产品自己把安装树挂到 PATH”；
2. 替换失败时用 Restart Manager（RmRegisterResources / RmGetList）把占用进程写进 directory-failure-*.log 与对话框；
3. 或按 建议：Windows 更新改为「版本目录 + 指针切换」 #11980 的“版本目录 + 指针切换”，把更新事务的原子操作降为替换一个小文件。

补充现象（同主贴）：Restoration error: 0 表示备份改名从未成功，旧版本完好、无 .old-* / .new-* 残留；重试 10 次无效，因为句柄不会自行释放。临时规避是退出占用程序后直接重跑 %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\ 下已下载的安装包。