same-file

Fixes #55. takes the underlying out of and hands the 's ownership back to the caller instead of dropping it. When that value is later dropped by the caller, 's impl unconditionally unwrapped for std streams (), assuming it was still . But had already emptied it, so the panicked: The fix makes tolerate an already-empty instead of assuming it's always , using in place of the unconditional . Verification** Reproduced the panic on current with , matching the exact panic site/message from the issue. Added a regression test ( in ) that fails with the same panic against the old impl and passes with the fix. (10 unit tests + 8 doc-tests) and both pass. Manually exercised all three std streams: called on , , and in a standalone binary — no panic — and additionally wrote through the fd recovered from to confirm it's still a live, usable descriptor and not just a non-panicking value. Left the pre-existing / clippy no-ops in // untouched since #67 already covers those.

On (and the other targets) compiles into the module, so and always return The effect that reaches users is through . With , calls for its symlink loop check, so on WASI every directory symlink errors and the whole subtree behind it is dropped. We hit this in rolldown, whose wasm build walks a project tree for : the native binding matches the files behind a directory symlink, the wasm binding matches none (rolldown/rolldown#10609). WASI's file API has the same shape as the unix one, and is stable on WASI, so can serve both. The one piece std does not provide is /: is still unstable (, rust-lang/rust#71213) as of Rust 1.97.1. Proposal Read the two numbers through on WASI, and let WASI share the existing module. The rest is only: becomes for the selection, the declarations and the / accessors, loses WASI, and the two imports in gain WASI counterparts. calls instead of reading the metadata inline. About 30 lines in total, and nothing changes for unix or windows. is a new dependency, which is why I am opening an issue first. Windows already pulls , so a target-gated dependency has precedent here, and this one only covers . Alternative without a new dependency preview1 exposes , and and are the first two s of , so the same values can be read through a small block and no dependency at all. That version only covers , so would keep falling back to . I have it working as well and can send it instead if you would rather not take . What I verified Builds: , , , and the host target. and are unchanged on the host. Runtime: a probe built for and run under Node 24's , over a tree containing a directory symlink and a symlink loop. Two paths to the same directory compare equal, different directories compare unequal, and a directory symlink compares equal to its target. with then yields exactly the entries and the error that the same tree yields natively. Without the change the same probe drops both symlinked subtrees. Same probe under , the WASI shim npm packages use in the browser, with the same result. MSRV: on WASI this needs a newer Rust than the declared 1.60, because of . Other targets are unaffected. I have not pinned the exact floor yet, and can do that or use a different import if you want to keep a single MSRV. Unrelated but adjacent no longer compiles on unsupported platforms at all: uses , which edition 2021 rejects with "format argument must be a string literal". 1.0.6 is edition 2018 so it still builds; a release cut from today would turn and friends from a runtime error into a build failure. fixes it. I can fold that into the same PR or keep it separate. Happy to send a PR — just say which of the two implementations you would rather take.

Replace and with / — the temporary returned by makes a no-op.