This describes version 0.2.3. See thesupport record for measured option combinationsand backend limits; accepted options do not establish full compatibility.
Move files and directories with the policy-checked atomic rename operation.Declining an interactive overwrite, including EOF, returns status 1 and leavesboth paths unchanged; other operands are still processed. A no-clobber skipremains a successful no-op.
Supports force/no-clobber/interactive selection (-f/-n/-i), update modes(-u/--update), backup controls (-b/--backup, -S), explicit targetpaths (-T), directory destinations, and verbose output. Cross-filesystemcopy-and-delete fallback is excluded because public APIs cannot preserve allrequired mode/link/time semantics. POSIX EXDEV can now be classified usingasync 0.22.4 host-platform information. The source remains intact when renameor backup commit fails.Classification of EXDEV does not add a cross-device fallback. Windows renameerror classification and the remaining interactive/backup/update combinationsstill need independent validation.
The async 0.22.5 Native implementation opens Windows symlinks and junctions asreparse points when renaming them. Wasm imports rename from the installed host,so the dependency update does not establish that the host contains this fix.Windows Wasm therefore rejects moving a symlink/junction or backing up adestination link before prompting or changing paths. No-clobber and update-noneskips still preserve both paths. This does not establish -u timestamp-basedskips for links: Windows Wasm rejects those guarded operations before checkingtimestamps. Reopen these operations only after a fixed hostis identified and Windows Native/Wasm regressions separately verify the linkand its referent. The file and directory symlink fixtures force real symlinks;the Windows junction fixture deliberately permits junction creation. MissingWindows link privileges or observer support are verification failures, notevidence that the rename behavior works.
Source and destination timestamps describe the directory entries themselves,so replacing or backing up an existing target also accepts a dangling sourcelink on verified backends. The Windows scenarios separately exercise Nativelink moves and Wasm rejection, comparing link type/target and referent bytesbefore and after each operation. Backup-creation failure preserves the fixtureand permits a later valid retry. Restoration after a completed backup is coveredby package-level rename fault injection, including Windows link and junctionbackups, their targets and referent bytes. Wasm interactive refusal is checkedwith stdin kept open and no bytes sent: it must exit within the observer deadline,emit no overwrite prompt, and preserve the complete fixture. Replacing adestination link with a regular source without backup remains allowed on bothbackends and has separate Windows command rounds awaiting CI evidence. A realCLI post-backup failure remains unverified by these fixtures.
Same-path moves fail before prompting or making backups, except an explicitno-clobber/update-none skip. After rename, the source entry must have disappeared;a same-inode hard-link no-op reports failure and preserves both names. Publicidentity metadata is unavailable before the operation. Equal-time targets with-i or -u therefore reject explicitly: equal timestamps cannot distinguishan alias from a separate file. This includes separate files whose mtimes happento match. Other processes recreating the source during rename also cause apostcondition error; no second deletion is attempted.
Standalone --version prints exactly mv 0.2.3 followed by onenewline. Standalone --help starts with Usage: mv, lists bothmetadata options, and ends with a newline. Both write to stdout, leave stdinunread, and exit with status 0. Exact-version publication and verificationremain recorded separately in the support record.