Summary

On the wasm32-hwjs runtime, the file-attribute syscalls fchmod/fchown/utimes and unlink return ENOSYS ("Function not implemented"). This breaks bzip2's default (named-file) compress/decompress mode and rm.

Evidence

Machine: dmitry/bzip2-glibc; observed on the fra2 hardwarejs run-machine.mjs harness as root with a writable /tmp (so this is not a permissions issue).

bzip2 named-file mode:

$ echo the-quick-brown-fox-bzip2 > /tmp/b.txt
$ bzip2 -kf /tmp/b.txt
bzip2: I/O or other error, bailing out.  Possible reason follows.
bzip2: Function not implemented
        Input file = /tmp/b.txt, output file = /tmp/b.txt.bz2
bzip2: Deleting output file /tmp/b.txt.bz2, if it exists.
bzip2: WARNING: deletion of output file (apparently) failed.

bzip2 compresses the data (a valid 68-byte .bz2 is written) but then bails at the post-write attribute restoration — applySavedFileAttrToOutputFile() does fchmod()/fchown() on the output fd (and utime() after close), and one of those returns ENOSYS, so bzip2 reports an I/O error and tries to delete the output.

unlink:

$ rm -f /tmp/somefile
rm: can't remove '/tmp/somefile': Function not implemented

Not affected

The bzip2 -c stream form does no attribute restoration and exits clean:

$ bzip2 -c /tmp/b.txt > /tmp/b.bz2 && echo RC=$?   -> RC=0
$ bzip2 -t /tmp/b.bz2 && echo OK                    -> OK
$ bunzip2 -c /tmp/b.bz2 ; bzcat /tmp/b.bz2          -> recover the original

Suggested fix

Implement these syscalls on wasm32-hwjs — even as accept-and-succeed no-ops for fchmod/fchown/utimes (the wasm image has no meaningful ownership/mode semantics), and a working unlink/unlinkat — so bzip2's default file mode and rm succeed instead of failing with ENOSYS.

Fixed on joel-dev together with #5 (kernel 790070a9c31e + hardwarejs 0d86fea — see #5 for the full two-layer story). Specifically for this ticket's shapes: fchmod is wired real (FATTR_MODE round-trips through stat), fchown/chown-family is wired with the sanctioned accept-and-succeed uid/gid no-op on virtio-fs, utime()/utimes() resolve via utimensat (mtime now actually persists on virtio-fs instead of silently dropping), and unlink/rm were already wired by the earlier #34/#71 lineage (live machines just run an older kernel). The verification gate includes exactly bzip2's post-write sequence — fchmod + fchown on the output fd + fsync → all rc=0 — on both tmpfs and virtio-fs. Lands on the machines at the next deploy; please re-run bzip2 -kf and rm then, and reopen if anything still errors. — agent for joel, 2026-07-14