Repository navigation
Replies: 3 comments
|
你的核心指控成立，而且可以做到字节级复现 —— 我把那个 211 B 反推出来了。另外有三处需要修正（一处文件名、一处把有意设计当故障、一处「不存在」的判断），因为写准了才好被采纳。 1. ⭐ 211 B 的来源已精确锁定
const manifest = { name: `dsh-profile-${basename(dir)}`, private: true, dependencies: {},
dsh: { profile: { bundles: [...bundles] } } }
writeFileSync(manifestPath, JSON.stringify(manifest, undefined, 2) + '\n')按这个渲染方式算 与你观察到的 211 B 完全一致（单 bundle 是 175 B）。 而且这个重建每次启动都跑：
只在缺失时重建 —— 被外部删掉，就静默重建成空表，无告警、无返回值、无完整性检查。 2. 文件名要改当前会话日志是 3. 「没有任何可用的应用日志」应改成「只有崩溃报告一种落盘产物」严格说不是坏了，是有意只有这一种： ⇒ 「目录存在但为空」= 本次进程没崩，是预期态。 这一条必须写清，否则会把维护者引向「日志功能坏了」的错误结论。你的诉求 1 依然成立，但它是功能请求，不是缺陷修复 —— 这个区分会显著影响它被采纳的速度。 4. 你问的三样，我确认「不存在」
5. 最小可行改进点（建议这样提）诉求 2 最有价值，而且改法很小：在 比「新增备份系统」这种大改造更容易被接受，而且正好堵住你这次的实际损失路径。 一条边界「无法定责」客观成立，但要注意即使日志齐全，DSH 也不会审计外部进程的删除 —— 那是 OS 层取证问题，不是 DSH 能补的洞。所以「可回滚删除 + 审计」这条诉求建议单独说明它期望的责任层。 |
0 replies
|
Follow-up：这条因果链在同一天又发生了第二次——而第二次只删了一个文件 谢谢 PerryLink 的逐条核对。三点先对齐，再报一条新增现场证据。 一、我们接受并复核了你的结论
二、一处仍需更正：会话日志文件名实测是 v4
三、新增证据：同一天的第二次删除（20:10:29），删掉的正好是
四、为什么两条要一起看：因果链是同一条 03:17 那次是"外部批量删除 五、我们建议把它压到最小（比你提的还小一档，共三行级改动）
六、我们这边的损失清单（供你核实，全部可复现）
如果这三条（缺了要说、重建要说、坏了要说）能落地，这类事故的可观测性就够了——我们不需要 DSH 去审计外部进程，只需要它别在自己被掏空时保持沉默。 证据附录（T0：全部已脱敏，<DSH_HOME>///<CLEANER_*> 为占位符）A. 删除窗口内 DSH 自身的日志
|
| 原始证据文件（本机） | 大小 | SHA-256（前 16 位） |
|---|---|---|
<DSH_HOME>\profiles\desktop\hub.log |
2,708 B | 85980986ecb12cbe |
<WORKSPACE>\_forensics\…\w6-mtime-0245-0430.txt |
38,372 B | b468163518634c1a |
<WORKSPACE>\_forensics\…\w7-mtime-0200-0500-extended.txt |
9,585 B | 86c15f669bb0527c |
<WORKSPACE>\_forensics\…\session-timeline.txt |
60,867 B | 355b80f773b2d03d |
<DSH_HOME>\storages\workspace.json |
6,948 B | b05e25218bc3bb26 |
<DSH_HOME>\storages\session-index.json |
61,231 B | 64dd7e56a1679868 |
| 我方事故取证报告（完整版） | 19,552 B | 70e60a5eb6006acb |
| 我方插件审计报告（完整版，含 20:10:29 事件） | 37,509 B | ddba94e5da67f9f8 |
上面 8 个文件共 231 KB。我没有上传任何会话日志（
session.v4.jsonl.zstd）——按你们的规则它们也挂不上（附件需仓库写权限，且.zstd不在允许类型里）；若你们需要某个具体会话的原文片段或完整文件，请指名会话 id 与区段，我再按需提供。
0 replies
|
先更正我自己：文件名这条我说错了，你是对的。 是文档滞后，不是版本差异。 1. 更正：当前文件名确实是
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
一句话摘要
2026-10-10 凌晨本机发生一次目录级批量删除事故：两波清扫（03:17–03:18 与 04:10 之前）永久删除（绕过回收站）了 DSH 托管目录（
%DSH_HOME%\electron、%DSH_HOME%\python-engine、%DSH_HOME%\profiles\...\node_modules）以及 Windows 壳层的已知文件夹（Start Menu、Recent、WindowsApps别名）。事故后无法定责：DSH 桌面端没有应用级日志、会话正文与元数据也一起被删。重启后 DSH 静默地按“空 profile”重建（重建出 211 B 的package.json），插件市场变空白，用户只看到“插件没了”。（下文
%DSH_HOME%指 DSH 的数据根目录，即~/.dsh。）这条帖子不是要指认 DSH 删了文件（证据不支持），而是把一次真实的外部删除事故作为样本，提交 DSH 在“可观测性 / 自愈 / 可回滚”上的具体缺口。
时间线（全部是文件系统 mtime / 创建时间，可复现）
%DSH_HOME%\electron被动（该目录当天 00:23:49 才下载）%DSH_HOME%\profiles\desktop\node_modules被掏空，只剩两个“正在被进程占用”的目录%DSH_HOME%\profiles、%DSH_HOME%\python-engine、%USERPROFILE%\.local\bin接连被动%APPDATA%\Microsoft\Windows、…\Windows\Recent、%LOCALAPPDATA%\Microsoft\WindowsApps被删%APPDATA%\Microsoft\Windows\Start Menu不存在（删后未被重建 ⇒ 开始菜单里少了 PowerShell 等入口）Test-Path= Falsepackage.json（211 B），17 个依赖 / 20 个 bundle 的清单全部丢失自动清理器的指纹（这是判断“不是人为误删”的依据）
C:\$Recycle.Bin里没有 10/09–10/10 的删除墓碑（唯一一条与本次无关）。.dll/.node、一个正被进程持有的插件目录、浏览器缓存、被锁的.log2—— 典型的“删得掉就删、删不掉跳过”。%DSH_HOME%与%USERPROFILE%\.local\bin；04:10 前另一波打 Windows 壳层已知文件夹。不是单次点击能造成的形态。对 DSH 的实际影响（这才是本贴的重点）
package.json（211 B）。用户看到的只是“插件市场空了/插件全没了”，无法知道是外部删除导致的。%DSH_HOME%\storages的会话元数据、以及sessions\**\session.v4.jsonl.zstd正文一起丢失（一个工作区的 8 个会话正文一个都没剩）。其中一个可疑会话的 projcache 元数据后来被第三方恢复工具找回，但内容是 26,513 B 的随机字节（已损坏，无法解析）。%APPDATA%\@deepseek-ai\dsh-desktop\logs\目录存在但为空。于是“谁在什么时候删了什么”完全不可查——这直接导致无法区分“外部清理器 / 另一个 agent 会话 / 自身运行时修复流程”三种可能。.dsh\electron、.dsh\python-engine、.dsh\profiles恰好都是 DSH 托管、并在启动时校验/重装的目录；它们被清掉后没有任何“完整性检查失败”的显式提示。我排除掉的（避免误导）
Unregister-ScheduledTask、一个只操作-LiteralPath <root> -Filter <白名单正则>的日志轮转脚本）在代码层面都与文件删除无关。safe-delete钩子，其 10/08 日志里有 214 行 “moved to trash”、去重后 169 个路径（删的是另一个盘的项目目录）。也就是说，风险类真实存在，只是这一次的受害者是 DSH 目录。与既有讨论的关系
机制类已经有帖子，我明确引用而不是重复：#8287（in-box 包重复导致工具调用静默全坏）、#2252 / #3190 / #5249 / #5962 / #5902 / #8330（外部临时目录清理器删掉
%TEMP%\dsh-subprocess-*导致宿主崩溃或 spill 丢失）、#6483（沙箱私有临时目录消失后会话永久失效）。本条补充的是：受害者不只是临时目录，而是 profile / storages / sessions / 运行时目录本身，而且事故后既无法取证、也不会自愈。
诉求（按优先级）
%APPDATA%\@deepseek-ai\dsh-desktop\logs\（现在为空）。至少记录：进程启动/退出、profile 解析结果（实际读到的 bundles / dependencies 及来源路径）、插件注册摘要（成功 / 跳过 / 失败原因）、以及宿主内的未捕获异常。electron、python-engine、profiles\**\node_modules、storages、sessions、package.json的依赖清单）是否完整；发现被外部删除时给出明确提示与一键修复，而不是静默地重写成“空 profile”并继续运行。.zstd已有损坏）。FOF_ALLOWUNDO语义或移动到 quarantine 目录），并把“谁、何时、删了什么路径、退出码”写进与会话解耦的 append-only 审计日志（社区已有针对这一点的第三方尝试，例如mokuyoaxis/agent-guard，但把能力内置到 DSH 更可靠）。dsh doctor的命令，输出 profile 完整性、bundle 解析、插件注册失败清单、以及“检测到外部清理痕迹（目录缺失/回收站无记录/文件占用幸存模式）”。附：我们已做的止血与恢复（供其他用户参考）
C:\Users\Default\AppData\Roaming\Microsoft\Windows复制Start Menu/SendTo/Templates等）。package.json/pnpm-lock.yaml/pnpm-workspace.yaml/cordis.patch.yml，再pnpm install），重启后插件市场恢复。storages（正文无法恢复）。%DSH_HOME%、工作区目录加入安全套件白名单，关闭“自动清理/清理Pro”，并把sessions/storages/ profile 关键文件定期 robocopy 到另一个盘。以上均为终端用户侧只读取证（除“止血/恢复”外没有改动系统），需要原始日志片段或逐条命令输出我可以补。
All reactions