tests: fix AFP FinderInfo smoke payload alignment
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.
This commit is contained in:
OpenAI
2026-05-30 10:42:03 +00:00
committed by Mario Fetka
parent 3fa06b4c15
commit 6fcd5c294e

View File

@@ -235,6 +235,14 @@ int main(int argc, char **argv)
cpu_to_be16(request_mask, request + 5);
request[7] = (uint8_t)path_len;
memcpy(request + 8, path, path_len);
/*
* The server-side AFP request buffer includes the NCP AFP subfunction byte
* at offset 0. This smoke helper passes only the subfunction payload to
* NWRequestSimple(), so every server offset after the leading function byte
* maps to request_offset - 1 here. Align once in AFP/server coordinates,
* then subtract one; do not align the payload offset again or FinderInfo-only
* requests with an even path length get a leading zero byte persisted.
*/
afp_data_off = 1 + 8 + path_len;
if (afp_data_off & 1)
afp_data_off++;
@@ -243,7 +251,8 @@ int main(int argc, char **argv)
cpu_to_be16(attr_request, request + data_off);
data_off += 2;
}
if ((request_mask & AFP_FINDER_INFO_MASK) && (data_off & 1))
if ((request_mask & AFP_FINDER_INFO_MASK) && (request_mask & AFP_ATTRIBUTES_MASK) &&
((data_off + 1) & 1))
data_off++;
if (request_mask & AFP_FINDER_INFO_MASK) {
memcpy(request + data_off, finder_info, sizeof(finder_info));