@openclaw/fs-safe 0.8.5 → 0.8.6

package/CHANGELOG.md

@@ -1,6 +1,11 @@
 # Changelog
 
-## Unreleased
+## 0.8.6 - 2026-09-07
+
+**Highlights:** Clearer guidance for atomic writes on Windows exFAT, with a repeatable filesystem compatibility probe.
+
+- Document the existing opt-in locked rename policy for Windows exFAT/FAT32 and add a built-package probe for identity drift, substitution handling, and temporary-prefix isolation; require a trusted, quiescent probe parent and verify its cleanup identity. Thanks @dongsheng123132.
+- Refresh the native zstd decoder to 0.14.0 and compatible Rust and JavaScript development dependencies, and update the pnpm setup action to 6.1.0.
 
 ## 0.8.5 - 2026-09-07
 

package/docs/atomic.md

@@ -75,12 +75,37 @@ If `beforeRename` throws, the rename is skipped and the owned temp file is remov
 
 Identity checks and pathname rename/unlink remain separate syscalls, not atomic conditional mutations. Use an approved writable parent plus cooperative locking or OS isolation when arbitrary concurrent namespace mutation is in scope.
 
-### FUSE mounts and unstable rename identity
+### FUSE, Windows exFAT/FAT32, and unstable rename identity
 
 Strict source-to-destination identity is the default. Some FUSE mounts assign a different inode to the destination during rename even without concurrency. Set `renameIdentity: "verify-content-with-lock"` to accept that boundary only when the re-opened no-follow destination has the exact requested SHA-256 content under an exclusive hashed sidecar lock in the destination parent. The newly accepted descriptor and identity remain pinned through parent sync and final verification. The synchronous helper provides the same policy with the synchronous lock implementation.
 
 This is the same explicit weaker contract available on `Root` writes: cooperating writers are serialized, stale locks fail closed, and mismatched content is rejected after publication without rollback. A same-authority actor that ignores the advisory lock can still substitute another file with identical bytes, so do not use this compatibility policy in directories writable by untrusted same-UID processes.
 
+Windows exFAT/FAT32 volumes can also change file identity during rename, depending
+on the source and destination names. The destination may already contain the
+requested bytes when strict verification reports `path-mismatch`. A short
+temporary name alone does not guarantee stable identity for a longer destination.
+For an application-controlled directory on such a volume, callers can explicitly
+select `renameIdentity: "verify-content-with-lock"` on `replaceFileAtomic` or
+`replaceFileAtomicSync`. Keep strict mode for directories that require the
+stronger identity contract; do not automatically retry every `path-mismatch`
+with the weaker policy. Staging names remain random, including custom prefixes.
+
+To verify the built package against an actual volume, run
+`node scripts/atomic-rename-compat-proof.mjs EXISTING_PARENT` after `pnpm build`.
+Use a trusted parent directory that no other process can rename or modify during
+the entire run, including cleanup; do not point the probe at a shared writable
+volume root. Cleanup checks the created directory's identity before recursive
+removal, but the check and removal are not atomic. The probe does not test safety
+against hostile concurrent namespace mutation.
+The probe creates and cleans up its own child directory and emits JSON without
+local paths. It compares default, strict, and locked policies in both async and
+sync calls, checks real rename identities and file contents, injects different-
+and identical-content substitutions, checks lock cleanup, and exercises custom
+prefix isolation and validation. Callback staging remains strict and can still
+report identity drift; the probe records that result separately. Filesystem type
+must be recorded independently; the probe does not infer it from a drive letter.
+
 ### `EPERM` and copy fallback
 
 On systems where `rename` fails with `EPERM`/`EEXIST`, pass

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openclaw/fs-safe",
-  "version": "0.8.5",
+  "version": "0.8.6",
   "description": "Capability-style filesystem roots for Node.js apps that handle untrusted relative paths.",
   "keywords": [
     "filesystem",
@@ -156,13 +156,13 @@
     "archive:producer-smoke": "node scripts/archive-producer-smoke.mjs"
   },
   "optionalDependencies": {
-    "@openclaw/fs-safe-darwin-arm64": "0.8.5",
-    "@openclaw/fs-safe-darwin-x64": "0.8.5",
-    "@openclaw/fs-safe-linux-arm64-gnu": "0.8.5",
-    "@openclaw/fs-safe-linux-arm64-musl": "0.8.5",
-    "@openclaw/fs-safe-linux-x64-gnu": "0.8.5",
-    "@openclaw/fs-safe-linux-x64-musl": "0.8.5",
-    "@openclaw/fs-safe-win32-x64-msvc": "0.8.5",
+    "@openclaw/fs-safe-darwin-arm64": "0.8.6",
+    "@openclaw/fs-safe-darwin-x64": "0.8.6",
+    "@openclaw/fs-safe-linux-arm64-gnu": "0.8.6",
+    "@openclaw/fs-safe-linux-arm64-musl": "0.8.6",
+    "@openclaw/fs-safe-linux-x64-gnu": "0.8.6",
+    "@openclaw/fs-safe-linux-x64-musl": "0.8.6",
+    "@openclaw/fs-safe-win32-x64-msvc": "0.8.6",
     "jszip": "^3.10.1"
   },
   "devDependencies": {