【BUG反馈】8,325个临时目录差点把我的C盘干爆炸了（附修法，官方看一眼啊）

[See-Sol-Lab]

%TEMP%把C盘干爆

每个 dsh 进程启动后都会在系统临时目录里建一个自己的小目录(dsh-subprocess-* 等),但从来不删。Windows 的 %TEMP% 系统也从来不会自动清。于是它只增不减,我这边高强度用下来就把C盘撑炸了:8,325 个目录,20+GB,微信弹磁盘警告,系统差点起不来。清理干净之后,只是正常用了几个小时,又攒出 20 个。

问题情况

packages/subprocess/subprocess-local/src/spawn.ts — privateSpillDir():

let defaultSpillDir: string | undefined
function privateSpillDir(): string {
  defaultSpillDir ??= mkdtempSync(join(tmpdir(), 'dsh-subprocess-'))
  return defaultSpillDir
}

这个目录是每进程懒创建的,里面的 spill 文件用完会删,但目录本身没有任何代码负责删。全仓搜不到对 defaultSpillDir 的清理。同族还有 spill-local 的 dsh-spill-* 和 sandbox-local 的 dsh-*(后者正常 dispose 会清,但崩溃/强杀路径会留下,里面还可能有内容——20GB 的大头应该来自这类非正常退出留下的带内容目录)。其实同类问题codex也有,就算定时清也还是没法根治。奇怪的是居然没看到其他同类案例报错,难道其他人用dsh都没有遇见类似的情况吗?我记得codex之前经常干爆用户的C盘,导致不得不搬到别的盘去,还得定时清。

这个BUG不处理还是会坑更多用户

因为 dsh 如果自己不加一个打扫自己的功能,Windows 用户磁盘告急后自然会跑系统「存储感知」或第三方清理工具——然后清理工具删掉正在运行的 dsh 的 spill 目录,dsh 直接 ENOENT 崩溃。这正是 #2252、#1961、#3190、#5250、#758 那一批帖子。两件事是同一个根因:临时目录没有生命周期管理。修堆积,顺便就把那批崩溃的诱因削掉一大半。

建议官方修的思路

1. 进程正常退出时删掉自己的 spill 目录。落点——LocalSubprocessRuntime 构造函数里已经注册了 teardown effect 和 process.on('exit') 监听(subprocess-local/src/index.ts),专门负责 host 退出时终止子进程;在 disposeManagedProcesses() 之后和 exit 监听里各加一句 rmSync(spillDir, { recursive: true, force: true }) 就行(exit 回调只能同步,rmSync 正好合规)。更干净的做法是把 spill 目录的所有权从模块级变量挪进 Runtime 实例,生命周期跟 ctx 走。spill-local 的 defaultRoot 同理,挂它自己的 service dispose。

2. host 启动时清扫残留目录。关键是怎么判断「目录的主人死没死」——建议用锁文件而不是 PID:每个进程建目录后立刻在里面放一个 owner.lock 并保持句柄打开(Windows 独占 share mode,POSIX flock);清扫者对每个候选目录尝试独占打开这个锁,打得开=主人已死可删,打不开=活进程跳过。PID 文件不可靠(PID 会被系统回收重用),锁不会误判。没有锁文件的目录(老版本留的)用 mtime 年龄阈值兜底(比如超过 24 小时)。清扫本身 best-effort + 限流(单次最多扫 N 个),删不掉的(EBUSY/EPERM)留给下次。

3. 所有每进程目录统一放进 join(tmpdir(), 'dsh') 这个固定父目录。清扫范围从「全 %TEMP% 按前缀猜」变成「只扫自家院子」,永远碰不到别人的文件;用户也一眼能看懂这堆是谁的,想手动删只用删一个目录。

顺带,给这个父目录做一个「不存在就重建」的 ensure 函数,OutputCollector 写 spill 文件遇到 ENOENT 时走同一个函数重建重试——正好把 #2252 那批「外部清理删目录→崩溃」的帖子一起修了。

[See-Sol-Lab]

English translation for non-Chinese readers:

Title: 8,325 temp directories nearly blew up my C: drive

%TEMP% filled up my C: drive

Every dsh process creates its own little directory under the OS temp dir (dsh-subprocess-* and friends) and never deletes it. Windows never auto-cleans %TEMP% either, so it only ever grows. After months of heavy use it blew up my C: drive: 8,325 directories, 20+GB, WeChat throwing low-disk warnings, the system barely able to boot. After a full cleanup, just a few hours of normal use produced 20 new ones.

What's going on

packages/subprocess/subprocess-local/src/spawn.ts — privateSpillDir():

let defaultSpillDir: string | undefined
function privateSpillDir(): string {
  defaultSpillDir ??= mkdtempSync(join(tmpdir(), 'dsh-subprocess-'))
  return defaultSpillDir
}

The dir is created lazily per process; the spill files inside do get removed, but no code anywhere is responsible for removing the directory itself — a repo-wide search finds no cleanup of defaultSpillDir. Same family: dsh-spill-* from spill-local, and dsh-* from sandbox-local (the latter is cleaned on graceful dispose, but crash/kill paths leave it behind, sometimes with content — which is probably where most of the 20GB came from). codex has the same kind of problem by the way, and even scheduled cleanup never really cures it. What surprises me is that I couldn't find anyone else reporting this — has nobody using dsh run into it? I remember codex used to blow up users' C: drives all the time, forcing people to move it to another drive and still clean it on a schedule.

Left unfixed, this bug will keep biting more users

As long as dsh doesn't ship a way to clean up after itself, Windows users whose disk fills up will naturally reach for Storage Sense or a third-party temp cleaner — which then deletes the spill dir of a running dsh, and dsh crashes with ENOENT. That's exactly the #2252 / #1961 / #3190 / #5250 / #758 family of threads. Two symptoms, one root cause: the temp dirs have no lifecycle management. Fix the accumulation and you also remove most of the reason people run cleaners against %TEMP% in the first place.

Suggested fix

1. Remove the process's own spill dir on graceful exit. The seam already exists — LocalSubprocessRuntime's constructor registers a teardown effect and a process.on('exit') listener (subprocess-local/src/index.ts) that already terminate child processes on host exit; add one rmSync(spillDir, { recursive: true, force: true }) after disposeManagedProcesses() and in the exit listener (the exit callback must be synchronous, and rmSync is). Cleaner still: move spill-dir ownership from the module-level variable into the Runtime instance so its lifetime follows the ctx. Same for spill-local's defaultRoot, tied to its own service dispose.

2. Sweep stale leftovers on host startup. The hard part is telling "owner dead" from "owner alive", and the reliable answer is a lock file, not a PID: each process drops an owner.lock in its dir and keeps the handle open (exclusive share mode on Windows, flock on POSIX); the sweeper tries to open each candidate's lock exclusively — success means the owner is dead and the dir is safe to delete, failure means a live process, skip. PID files can't do this safely (PIDs get recycled); locks can't false-positive. Dirs with no lock file (left by older versions) fall back to an mtime age threshold (say 24h). Keep the sweep best-effort and rate-limited (at most N dirs per startup), and leave EBUSY/EPERM failures for next time.

3. Put all per-process dirs under a single fixed parent, join(tmpdir(), 'dsh'). The sweep then only ever touches dsh's own yard instead of pattern-matching across all of %TEMP%, users can see at a glance what the pile is, and manual cleanup is deleting one directory.

As a bonus, give that parent an "ensure it exists, recreate if missing" helper and route OutputCollector's spill writes through it on ENOENT — that fixes the whole #2252 family (external cleaner deletes the dir → crash) along the way.

[argszero]

Verified your source analysis against alpha.2 (0a53fb55be) — the core finding holds, with two precision points that change the sweep scope.

Confirmed — the real gap is subprocess-local's privateSpillDir()

packages/subprocess/subprocess-local/src/spawn.ts:90:

let defaultSpillDir: string | undefined
function privateSpillDir(): string {
  defaultSpillDir ??= mkdtempSync(join(tmpdir(), 'dsh-subprocess-'))
  return defaultSpillDir
}

Created lazily per process; the spill files inside get unlinked, but nothing ever removes the directory itself — no rmSync/rmdir of defaultSpillDir anywhere in the package. On a system where %TEMP% is never auto-cleaned, that's one orphan directory per process run, which matches your 8,325 count.

Precision 1 — spill-local already has a startup sweep (mtime-based)

packages/spill/spill-local/src/cleanup.ts ships sweepSpillRoots() with an mtime cutoff, wired in index.ts to the cleanupPeriodDays config (default 30, 0 disables; one best-effort sweep on activation). So dsh-spill-* roots are not unconditionally orphaned on alpha.2 — but note it's mtime-age based, which is exactly the weaker alternative to your lock-file idea (it can only prove "old", not "owner dead"), and it sweeps files, reclaiming a root only when empty.

Precision 2 — sandbox-local cleans on dispose

Matches your read: the private temp directory is removed at provider dispose (rmSync import in packages/sandbox/sandbox-local/src/index.ts), so its leftovers are limited to crash/kill paths — which is also where the content-bearing 20GB likely came from, as you suspected.

Your "two symptoms, one root cause" framing is right — and the crash side still needs its own guard

This is the same family as #3190 / #3203 / #5175, which I've analyzed before. OutputCollector.spillAll() (spawn.ts:150-177) still does openSync/writeSync with no try/catch: when a cleaner or Storage Sense deletes the spill dir of a running dsh, the next spill chunk hits ENOENT inside the stdout data listener → uncaughtException → whole process dies. Fixing accumulation removes the incentive to run cleaners, but the crash guard is worth landing independently — cleaners will always exist, and one stray sweep mid-session shouldn't be fatal. A catch → discardSpill() degradation (stop spilling, keep the stream alive) at the spillAll boundary covers both the external-deletion (#3190) and the quota-full (#5175) triggers from one choke point.

On your three proposals:

1. Exit-time rmSync + moving dir ownership into the Runtime instance — agree, and the seam already exists: LocalSubprocessRuntime registers the teardown effect and the process.on('exit') listener (index.ts:51-56) that terminate child trees; adding rmSync(spillDir, { recursive: true, force: true }) after disposeManagedProcesses() and in the exit listener is sync-safe (exit callbacks can't await, rmSync is synchronous).
2. Lock-file sweep — agree it beats PID files (PIDs get recycled). One Node nuance: "keep the handle open" means opening with 'wx' and holding the fd referenced for the process lifetime; a sweeper's successful exclusive open then means the owner is dead. On Windows the share-mode semantics map to this cleanly.
3. Unified join(tmpdir(), 'dsh') parent — agree; it also mirrors how spill-local already scopes its sweep via the exact-shape DEFAULT_ROOT_RE instead of pattern-matching across all of %TEMP%. One shared yard is both a safer sweep boundary and a single manual-cleanup target.

The recreate-on-miss at the OutputCollector boundary (your "不存在就重建" ensure) is the right complement: it turns the ENOENT class from a crash into a self-heal — exactly the direction the #3190 family fix should take.

[See-Sol-Lab]

Thanks for the verification — especially Precision 1. Our read came from an older embedded snapshot, so we missed that alpha.2 already ships sweepSpillRoots() with the cleanupPeriodDays mtime cutoff; good to know the dsh-spill-* side is partially covered on current builds. As you note, though, an mtime cutoff can only prove "old", never "owner dead" — which is exactly why we would still like the lock-file handshake as the primary sweep criterion, keeping the mtime threshold as the fallback for pre-lock leftovers.

Fully agree the crash guard deserves to land independently of the accumulation fix: cleaners will always exist, and a catch → degrade-to-discard at the spillAll boundary turns the ENOENT class from fatal into self-heal, covering the #3190/#5175 triggers from one choke point. Between that guard, the exit-time rmSync, and one shared %TEMP%\dsh parent, this whole area closes cleanly.