[bug] bugs on Windows

[shayne-snap]

用户的建议和方案

======================================================================
Whale Bug B1 & B3 验证测试报告
Generated by test_b1_b3_verify.py

运行时间: 2026-05-22T23:38:39.278929
系统: Windows 11 AMD64
Python: 3.14.4 (tags/v3.14.4:23116f9, Apr 7 2026, 14:10:54) [MSC v.1944 64 bit (AMD64)]

======================================================================
B1: os.Rename(tmp, path) 无法覆盖已有文件

系统: Windows 11
Python: 3.14.4 (tags/v3.14.4:23116f9, Apr 7 2026, 14:10:54) [MSC v.1944 64 bit (AMD64)]

[步骤 1] 创建目标文件: C:\Users\jiran\AppData\Local\Temp\whale_b1_av4dd560\target.jsonl
[步骤 2] 创建临时文件: C:\Users\jiran\AppData\Local\Temp\whale_b1_av4dd560\target.jsonl.tmp
[步骤 3] 执行 os.rename('C:\Users\jiran\AppData\Local\Temp\whale_b1_av4dd560\target.jsonl.tmp', 'C:\Users\jiran\AppData\Local\Temp\whale_b1_av4dd560\target.jsonl')
[结果] os.rename 失败！错误: [WinError 183] 当文件已存在时，无法创建该文件。: 'C:\Users\jiran\AppData\Local\Temp\whale_b1_av4dd560\target.jsonl.tmp' -> 'C:\Users\jiran\AppData\Local\Temp\whale_b1_av4dd560\target.jsonl'
[判定] B1 确认存在: os.Rename(tmp, path) 在 Windows 上无法覆盖已有文件
[根因] Go 的 os.Rename 调用 MoveFileW 默认不带 MOVEFILE_REPLACE_EXISTING 标志，
当 dest 已存在时返回 ERROR_ALREADY_EXISTS / ACCESS_DENIED。
[副作用] 临时文件残留: C:\Users\jiran\AppData\Local\Temp\whale_b1_av4dd560\target.jsonl.tmp

[Go 官方参考]
https://pkg.go.dev/os#Rename — 'If dest already exists, the rename fails on some OSes (e.g., Windows).'
修复方案: 调用前先 os.Remove(dest)，或用 syscall.MoveFileExW + MOVEFILE_REPLACE_EXISTING。

======================================================================
B3: cleanTargetPath() 剥离反斜杠破坏 UNC 路径

输入: '\\server\share\project\file.go'
描述: UNC 绝对路径 — 应当保持原样
输出: '\\server\share\project\file.go'
[正常] UNC 路径前缀保留

输入: '\relative\dir\file.go'
描述: 以反斜杠开头的相对路径 — 应当剥离前导反斜杠
输出: 'C:\workspace\relative\dir\file.go'

输入: 'C:\absolute\path\file.go'
描述: 普通绝对路径
输出: 'C:\absolute\path\file.go'

输入: 'relative\path\file.go'
描述: 普通相对路径
输出: 'C:\workspace\relative\path\file.go'

输入: '\\?\C:\very\long\path'
描述: Win32 设备路径
输出: '\\?\C:\very\long\path'
[正常] Win32 设备路径保留

[判定] B3 在当前测试环境下未复现

[修复方案]
在剥离前先检查是否是 UNC 路径: if strings.HasPrefix(raw, "\\") { return filepath.Clean(raw) }
或使用 filepath.VolumeName 判断后再决定是否做剥离。

======================================================================
B3 深入: safeWorkspacePath() 拒绝有效 UNC 路径

输入: '\\server\share\project\file.go'
描述: 有效 UNC 路径
target: '\\server\share\project\file.go'
状态: Rel 失败: path is on mount '\\server\share', start on mount 'C:'
[异常] 有效 UNC 路径被 safeWorkspacePath 拒绝: Rel 失败: path is on mount '\\server\share', start on mount 'C:'
[影响] 通过 safeReadPath 的 fallback 到 cleanTargetPath 可以绕过，
但直接调用 safePath/safeWorkspacePath 会失败

输入: '\\server\share\project'
描述: UNC 路径无文件名
target: '\\server\share\project'
状态: Rel 失败: path is on mount '\\server\share', start on mount 'C:'
[异常] 有效 UNC 路径被 safeWorkspacePath 拒绝: Rel 失败: path is on mount '\\server\share', start on mount 'C:'
[影响] 通过 safeReadPath 的 fallback 到 cleanTargetPath 可以绕过，
但直接调用 safePath/safeWorkspacePath 会失败

输入: '\\server\share'
描述: UNC 根目录
target: '\\server\share'
状态: Rel 失败: path is on mount '\\server\share', start on mount 'C:'
[异常] 有效 UNC 路径被 safeWorkspacePath 拒绝: Rel 失败: path is on mount '\\server\share', start on mount 'C:'
[影响] 通过 safeReadPath 的 fallback 到 cleanTargetPath 可以绕过，
但直接调用 safePath/safeWorkspacePath 会失败

输入: '\\server'
描述: 不完整 UNC (无 share)
target: '\\server'
状态: Rel 失败: path is on mount '\\server', start on mount 'C:'
[异常] 有效 UNC 路径被 safeWorkspacePath 拒绝: Rel 失败: path is on mount '\\server', start on mount 'C:'
[影响] 通过 safeReadPath 的 fallback 到 cleanTargetPath 可以绕过，
但直接调用 safePath/safeWorkspacePath 会失败

输入: '\relative\path\file.go'
描述: 以 \ 开头的相对路径
target: 'C:\workspace\relative\path\file.go'
状态: OK

输入: '\\?\C:\very\long\path'
描述: Win32 设备路径
target: '\\?\C:\very\long\path'
状态: Rel 失败: path is on mount '\\?\C:', start on mount 'C:'

[结论]
safeWorkspacePath 中的 Rel 验证以 'C:\workspace' 为根，
导致所有不同盘符/卷的绝对路径（含 UNC）被判定为逃逸。
这其实是设计如此（确保路径在 workspace 内），并非 bug。
真正的 bug 在 cleanTargetPath 的非绝对路径分支:

[cleanTargetPath 非绝对路径分支测试]
Go 的 filepath.IsAbs 在 Windows 上:
'\server\share\path' → IsAbs = true (UNC)
'\server' → IsAbs = false (不完整 UNC)
'\relative' → IsAbs = false

输入: '\\\\server'
IsAbs = True
绝对路径分支: '\\\\server'
[正常] 被正确处理

输入: '\\relative\\file.go'
IsAbs = False
剥离后: 'relative\\file.go'
最终: 'C:\\workspace\\relative\\file.go'
[异常] 非绝对路径分支中前导反斜杠被剥离

输入: '\\foo'
IsAbs = False
剥离后: 'foo'
最终: 'C:\\workspace\\foo'
[异常] 非绝对路径分支中前导反斜杠被剥离

======================================================================
测试汇总

B1: os.Rename(tmp, path) 在 Windows 上无法覆盖已有文件
- Go 官方文档明确说明: 'If dest already exists, the rename fails on some OSes (e.g., Windows).'
- 根本原因: Go 的 os.Rename 调用 MoveFileW/MoveFileExW 时未传递
MOVEFILE_REPLACE_EXISTING 标志 (0x1)。
- 影响范围: 会话自动压缩、消息更新全部崩溃。
- 修复建议: rename 前先 os.Remove(dest)，或使用 syscall 直接调用
MoveFileExW 并传入 MOVEFILE_REPLACE_EXISTING。

B3: cleanTargetPath() / safeWorkspacePath() 非绝对路径分支的前导反斜杠剥离
可能破坏语义

  [情况 1] cleanTargetPath()
  - 第 115 行有 filepath.IsAbs 前置检查，有效 UNC 路径 (\server\share\...)
    被识别为绝对路径并直接返回 Clean 结果，不会被剥离。[正确]
  - 但像 '\\server' (不完整 UNC, 无 share 部分) 这类路径，Go 的 IsAbs
    返回 false，进入非绝对路径分支后被剥离为 'server'，变为相对路径。[异常]

  [情况 2] safeWorkspacePath()
  - 同样有 IsAbs 前置检查，有效 UNC 路径进入绝对路径分支后被 Clean 保留。[正确]
  - 但后续 filepath.Rel(b.root, target) 验证会因 UNC 路径在不同卷而失败，
    导致 UNC 路径被拒绝 (path escapes workspace)，无法通过此函数访问。[异常]
  - 通过 safeReadPath 的 cleanTargetPath fallback 可绕开此限制。

  [情况 3] 非绝对路径分支
  - '\relative\dir' -> 剥离前导 \ -> 'relative\dir' -> Join(root) [正确]
  - 此转换对常见相对路径场景无问题。
  - 只有当 '\' 开头的路径本意是某种绝对/网络路径但 IsAbs 返回 false 时
    才会产生语义错误。即 '\\server' 这种不完整的网络路径。

  - 修复建议: 在剥离前检查是否是 UNC 路径前缀:
    if strings.HasPrefix(raw, "\\\\") { return filepath.Clean(raw) }
    或使用更通用的: if len(raw) >= 2 && raw[0] == '\' && raw[1] == '\'

======================================================================
测试结束

• B3 的实际真实风险分析
经过完整的代码追踪，B3 的真实风险比原表描述要窄得多。以下是诊断结果：
────────────────────────────
两条关键调用链的分叉
函数 │ 调用者 │ 对 UNC 路径的处理
─────────────────────────────────────┼─────────────────────────────────────┼──────────────────────────────────────
safePath() → safeWorkspacePath() │ 写工具: edit, write, apply_patch, │ 失败 — IsAbs 走绝对路径分支正确
│ shell │ Clean，但随后 filepath.Rel() 因 UNC
│ │ 在不同卷而报错，直接返回 error
safeReadPath() → │ 读工具: grep, ls(list_dir), │ 成功 — safeWorkspacePath 失败后
safeWorkspacePath() 失败 → fallback │ search_files, view(read_file) │ fallback 到 cleanTargetPath，其中的
cleanTargetPath() │ │ IsAbs 正确识别 UNC
│ │ 为绝对路径，直接返回 Clean 结果
────────────────────────────
实际风险矩阵
场景 │ 风险等级 │ 详情
───────────────────────────────────────────────────┼──────────┼───────────────────────────────────────────────────
用户 workspace 在本地盘 │ 🔴 高 │ edit/write/apply_patch/shell 全部返回
(C:)，试图写文件到网络共享 (\nas\share...) │ │ "permission_denied" 错误。即使 os.WriteFile
│ │ 本身可以写入 UNC 路径，也因为 safePath
│ │ 的安全校验提前拒绝了。用户完全无法通过 LLM
│ │ 工具向网络共享写入任何文件
用户 workspace 在本地盘，试图读文件从网络共享 │ 🟢 无 │ fallback 机制让 read_file/grep/list_dir 正常工作
用户 workspace 本身在 UNC 路径上 │ 🟢 无 │ 相对路径操作正常（Join 在 UNC root
(\nas\share\whale) │ │ 上工作良好）。跨卷访问被拒绝是设计意图，不是 bug
传入不合法路径 \server（缺 share 部分） │ 🟡 极低 │ Go 的 IsAbs 对此返回
│ │ false，反斜杠被剥离，路径变为
│ │ C:\workspace\server。但此路径本身在 Windows
│ │ 上就不合法，实际用户不会传入
传入 \foo\bar 相对路径 │ 🟢 无 │ 剥离前导 \ 后拼接
│ │ root，这是预期行为（将"当前盘符根"转为"workspace
│ │ 根"），不是 bug
────────────────────────────
一句话总结
│ B3 的真实风险是：当 workspace root 在本地盘时，所有写工具（edit/write/apply_patch/shell）无法写入 UNC
网络共享路径，而读工具不受影响。

这与原表描述的"触发验证码、搜索结果降质"没有直接关系——那个副作用描述很可能属于 B2（硬编码 macOS Safari
UA），是表格行对齐的笔误。

影响规模评估：Medium（原评级的 High 偏高了），因为：

• 影响面局限在 写操作 × 跨卷 UNC 路径 这一狭窄场景
• 有变通方案（用户手动 os.Rename 或通过系统 shell 写入）
• 大多数用户的 workspace 和操作目标都在同一卷上

[shayne-snap]

B3 is partially already covered by the current implementation:

• valid UNC paths like \\server\share\project\file.go are not damaged by cleanTargetPath(), because filepath.IsAbs() handles them before the
  leading-backslash normalization branch
• single-leading-backslash paths such as \relative\dir\file.go are intentionally normalized as workspace-relative paths
• safePath() rejecting \\server\share\... when the workspace is on C: is intentional, because write tools must stay inside the active workspace