dofs: writeFile to a path whose final component is a symlink writes onto the symlink inode: data silently lost, schema invariant broken

[rajpreetcodes]

Describe the bug

writeFile/writeFileSync in @cloudflare/dofs do not follow a trailing symlink. When the final path component is a symlink, the write lands on the symlink inode itself: chunk rows are attached to a type='symlink' node and its size is stamped with the written byte length, while link_target remains. The written bytes are unreachable through any path afterwards, because reads DO follow the link (packages/dofs/src/fs/readFile.ts:52) and return the old target content.

Locations:

• packages/dofs/src/fs/writeFile.ts:941-959: writeFileSync takes existing.child_inode from the final dirent as the write target; the type guard at :952-958 only rejects "dir", so "symlink" slips through.
• Same unguarded shape in writeFileStreaming (:227-239) and writeFileRangesSync (:1015-1031).
• :962-992: chunks are deleted/inserted for the symlink inode and UPDATE vfs_nodes SET ... size = ? stamps it, violating the documented invariant "Always 0 for directories and symlinks" (resolve.ts:12-14).

The sync layer already works around this hazard internally (removeReplaceableFinalEntry, packages/dofs/src/sync/apply.ts:84-94), but the public Filesystem.writeFile (fs/filesystem.ts:99-105) has no such guard.

Consequences beyond the lost write: the orphaned chunk rows hang off a symlink-typed node forever (gc()'s orphan gate keys off vfs_chunks references, so the blobs are pinned), and read/write of the same path address different inodes, which is incoherent for any workload that writes through a symlinked config or output path. Node's fs.writeFileSync follows trailing symlinks, so this diverges from the semantics the package mirrors elsewhere.

Expected behavior

POSIX open(2)/Node semantics: a write through /link -> /target writes /target; both readFile("/link") and readFile("/target") then return the new content. Writing through a dangling symlink creates the target (like open(O_CREAT)).

Steps to reproduce

Test against packages/dofs (existing withDB harness), run with npm test --workspace @cloudflare/dofs -- <file>:

await writeFile(db, "/target", "old-content", {}, () => 0);
symlink(db, "/target", "/link", () => 0);
await writeFile(db, "/link", "NEW-CONTENT", {}, () => 0); // POSIX: writes /target

await readFile(db, "/link", "utf8");   // expected "NEW-CONTENT"
await readFile(db, "/target", "utf8"); // expected "NEW-CONTENT"

Actual output:

AssertionError: expected 'old-content' to be 'NEW-CONTENT'   // both reads return "old-content"

Corruption proof (chunk rows now hang off a symlink-typed node):

SELECT COUNT(*) FROM vfs_chunks c JOIN vfs_nodes n ON n.inode = c.inode WHERE n.type = 'symlink'
-- expected 0, received 1

Proposed fix

In each final-dirent write path (writeFileSync, writeFileStreaming's commit transaction, writeFileRangesSync, plus the EEXIST probes in createFileSync/openWriteBufferForCreateSync): widen the node-type read to include "symlink" and, on hitting one, re-resolve the path with resolveInode (follow mode) and direct the write at the resolved file inode, creating the target when the link dangles. A minimal safe stopgap is to throw (O_NOFOLLOW-style rejection) rather than mutate the symlink inode. Related same-family issue observed in source (not separately reproduced): the write paths' private resolveParent (writeFile.ts:43-72) doesn't follow intermediate symlinks either, so writeFile("/link-to-dir/file") throws spurious ENOTDIR; intermediate-segment following should ride along so the write surface matches the read surface.

Environment

• cloudflare/computer at 76d9e75 (current main), local checkout
• npm test --workspace @cloudflare/dofs baseline: 436/436 pass before adding the repro
• Node v22.18.0, npm 11.8.0, Windows 11 (platform-independent; pure SQLite/TS logic)

[rajpreetcodes]

No Docker in the loop here. The repro runs in plain vitest against the dofs harness: drop the snippet into packages/dofs as a test file and run npm test --workspace @cloudflare/dofs. The write lands on the symlink inode inside the SQLite layer before any container or sync machinery gets involved. If you want the container path anyway, script/shell in this repo boots a debian-slim image with computerd, but you don't need it to see this bug.

[3x3xX3N0N]

Confirmed at 76d9e75, with a patch and failing-first tests — though one design decision in it is a maintainer's call, flagged below.

Reproduced, including the schema-invariant half:

readFile(/link)   = old-content     <- expected NEW-CONTENT
readFile(/target) = old-content     <- expected NEW-CONTENT
readlink(/link)   = /target
chunks hanging off symlink-typed nodes: 1
vfs_nodes.size of the symlink node: 11   <- must be 0 for symlinks

That last one contradicts the invariant documented at packages/dofs/src/fs/resolve.ts:12-16 ("Always 0 for directories and symlinks").

Root cause. The three write paths address the write by the final dirent's child_inode and only special-case type === "dir" — writeFileSync (writeFile.ts:941-962), writeFileStreaming's commit transaction (:221-239), writeFileRangesSync (:1015-1031). The db.one<{ type: "file" | "dir" }> union not including "symlink" reads like the case simply wasn't considered. Reads do follow (readFile.ts:52), which is why the bytes are unreachable through both the link and its target.

Fix adds resolveWritePathParts to resolve.ts, which walks the leaf to its target (creating it when the link dangles, as O_CREAT does) and reuses #54's linkTargetParts so relative targets work. O_EXCL keeps the unresolved path so it still reports EEXIST on the link itself — POSIX open() fails EEXIST when the final component is a symlink, dangling or not.

The decision I'd like a maintainer's view on. Following the link means assertNotReadOnly would naturally run against the resolved path — which quietly loosens the mount guard, since a link inside a read-only mount pointing out would become writable. I did not want a bug fix to relax a guard as a side effect, so the patch checks both the link path and the resolved path. That is strictly more conservative than today's behavior. If you would rather have exact POSIX semantics (resolved path only), it is a one-line change.

parentAndNameForResolvedPath (writeFile.ts:412) matches the same code shape but is deliberately untouched — it takes an already-resolved path, so following again there would be wrong.

Seven tests added. Six fail at this sha; the seventh — the O_EXCL case — passes at both shas on purpose, as a guard against over-following. Full dofs suite: 449 passing.

Branch: https://github.com/3x3xX3N0N/computer/tree/fix/dofs-write-follows-symlink (stacks on #54's branch) — not opening a PR, per CONTRIBUTING.md.

Still open, out of scope here: resolveParent rejects a symlink-to-directory intermediate with ENOTDIR — filed as #65.