test(nfs): run the conformance special-files cases over both NFS wires - #18
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
pi0
marked this pull request as ready for review
August 1, 2026 09:07
MKNOD (§3.3.11) and CREATE (§18.4) are operations an NFS client can call by name, so `nfsDriver` and `nfs4Driver` now offer `mountx.mknod` and the two columns declare the extension. Four of the six special-files cases run over the wire against the memory targets: the FIFO and socket type predicates off `ftype3`/`nfs_ftype4`, `rdev` surviving the 8-bit split through `specdata3`/`specdata4` and back out of `fattr3.rdev`/`rawdev`, a special file behaving as an ordinary name under rename and unlink, and the `EEXIST`/`ENOENT` refusals — every one of them the far side's answer arriving as an `nfsstat3`/`nfsstat4`. The other two stay skipped, because neither wire carries the file type in the *mode*: `sattr3.mode` is masked to `0o7777` at both ends and `fattr4`'s `mode` is permission bits, so a mode naming a regular file, a directory or no type at all is a question that cannot be asked. Both targets declare `carries: []` for it. The adapters refuse those types with a plain, deliberately non-errno-shaped `Error` naming the wire's limit rather than deciding `EPERM` locally — that refusal belongs to the driver on the far side, and inventing it here is exactly what invariant 5 forbids. A case per column pins that the refusal has no `code` and no `errno`, so un-gating one fails loudly instead of passing for the wrong reason. The node-fs targets keep `extensions: []`: that driver implements no `mountx.mknod`, so the sessions answer `NFS3ERR_NOTSUPP`/`NFS4ERR_BADTYPE` as they should, and the column carrying an extension is not the same claim as a target having one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on #17 (
feat/driver-mknode, which carriesConformanceTarget.carriesand themknod.anyTypegate) — its commits are in this branch's history, so review only the last commit. Together the two close #14.What
nfsDriverandnfs4Drivernow offermountx.mknod, routed to the MKNOD (RFC 1813 §3.3.11) and CREATE (RFC 8881 §18.4) methods the clients already had, andTHROUGH_NFS/THROUGH_NFS4declareextensions: ["mknod"]. Four of the six special-files cases now run over the wire against the memory targets in both columns:ftype3/nfs_ftype4in the wire's own attributesrdevsurviving the 8-bit split intospecdata3/specdata4and rejoining out offattr3.rdev/rawdevrenameandunlinkEEXISTandENOENTrefusals, each the far side's answer arriving as annfsstat3/nfsstat4What stays skipped, and why that is the point
Neither wire carries the file type in the mode:
sattr3.modeis masked to0o7777at both ends, andfattr4'smodeis permission bits. Somknod(path, S_IFREG | …),mknod(path, 0)andmknod(path, S_IFDIR | …)are questions these wires cannot ask — over v4.1NF4REGisNFS4ERR_BADTYPEby §15.1.4.1 andNF4DIRismkdir. Both memory targets declarecarries: [], and the two cases gated onmknod.anyTypeskip.The adapters refuse those types with a plain
Errornaming the wire's limit, deliberately not errno-shaped — nocode, noerrno, nothingrejects()could match. DecidingEPERMin the client would be inventing the refusal the driver on the far side owes, which is the fake invariant 5 names. One case per column pins that property, so un-gating a case fails loudly instead of passing for the wrong reason.The node-fs targets keep
extensions: []: that driver implements nomountx.mknod, so the sessions correctly answerNFS3ERR_NOTSUPP/NFS4ERR_BADTYPE. Same wording as the 9P column's oracle override.Also
test/matrix.ts's "Capability loss" preamble and.agents/testing.mdsaid the loopback and 9P columns were the only ones offering the extension by name and that NFS could not offer the whole thing; both now say what the run shows, and.agents/testing.mdgains a paragraph oncarries/mknod.anyType..agents/conformance-matrix.mdis regenerated: NFSv3 and NFSv4.1 go from 124 passed / 18 skipped to 128 / 14.pnpm testis green (2998 passed, 315 skipped).🤖 Generated with Claude Code