6fcd5c294e
All checks were successful
Source release / source-package (push) Successful in 47s
The AFP Set File Information smoke helper builds the NCP 0x23/0x10 payload without the leading AFP subfunction byte that nwconn sees in its server-side request buffer. The helper already aligned the FinderInfo data offset in server coordinates and then translated it back to the client payload buffer by subtracting that byte. A second alignment check after the translation shifted FinderInfo-only requests with even-length paths by one byte. The server then persisted the padding byte as the first FinderInfo byte, which produced xattrs such as 0x00544558544d415253... and verification output with got_creator=TMAR instead of TEXT/MARS. Keep the WebSDK/header bitmap semantics unchanged: bitmap 0x0020 still carries exactly a 32-byte FinderInfo block after the path and padding, and bitmap 0x0001 still carries the two-byte AFP attribute word. Only the Linux smoke helper's payload construction is corrected so it matches the server's subfunction-prefixed AFP request layout. Tests: - git diff --check - gcc -Iinclude -I/mnt/data/stubs -fsyntax-only tests/linux/afp_set_file_info_smoke.c TODO: - Re-run afp_smoke_suite.sh and confirm FinderInfo xattr starts with 0x544558544d415253 and the suite reports failures=0.