# DF-2764 — VERDICT

**Status: not reproduced / not testable on this guest — static proof
of mechanism (certain), feature absent at runtime.**

## Why not testable
The broken record is only emitted when the underlying VOP_SETEXTATTR
returns 0 (`if (error == 0)` in journal_setextattr, vfs_jops.c:1028).
- No in-tree DragonFly filesystem implements vop_setextattr (only
  smbfs, commented out: sys/vfs/smbfs/smbfs_vnops.c:121); every FS
  returns EOPNOTSUPP through the default vector, so the shim always
  aborts its jrecord (jreclist_done(error)) and journals nothing.
- The guest also lacks extattr userland (`setextattr` not found;
  fs_check.log).

## Static proof (certain)
1. journal_setextattr journals `ap->a_uio` AFTER the op
   (vfs_jops.c:1039 `jrecord_write_uio(jrec, JLEAF_FILEDATA, ap->a_uio)`).
2. VFS uio consumers mutate the iovec array in place
   (sys/kern/kern_subr.c:151 `iov->iov_len -= cnt`, :150-ish
   `iov_base += cnt`; uiomove). After a successful op all iov_len == 0.
3. jrecord_leaf_uio skips zero-length iovecs
   (sys/kern/vfs_journal.c:964-965 `if (iov->iov_len == 0) continue;`).
=> The JLEAF_FILEDATA leaf carrying the attribute value is never
   emitted; only JLEAF_ATTRNAME and a post-op SEEKPOS are recorded.
   journal_write() demonstrates the required pattern (uio copied
   BEFORE the op, vfs_jops.c:859-868, with the exact comment
   "UIO's don't retain sufficient information to be reused once
   they've gone through the VOP chain").

The defect is latent: it activates the moment any filesystem
implements vop_setextattr (e.g. smbfs uncommenting it).

## Fix
fix.diff (uio snapshot before the op, mirroring journal_write);
authored but not kernel-validated — the code path cannot return
success on the stock guest.