Route NCP 0x23/0x0f AFP 2.0 Get File Information through the existing read-only AFP file-information helper.
The WebSDK and nwafp.h list both AFP Get File Information and AFP 2.0 Get File Information as path/file-information queries that return the AFP file-information record used by Mac namespace clients. The already implemented 0x05 path handles SYS:-style path requests and fills the safe read-only fields from Unix stat data plus the optional libatalk Finder Info and resource-fork helpers.
Use the same conservative path-backed reply for 0x0f for now. This gives Linux smoke-test coverage for the AFP 2.0 subfunction without adding entry-id-only lookup, persistent CNID mapping, write-side metadata updates, or fuller resource-fork semantics.
Extend afp_file_info_smoke with --afp20 so the same SYS:, SYS:PUBLIC, SYS:SYSTEM, and SYS:BURST cases can exercise the AFP 2.0 subfunction. Update the Linux test README and TODO tracking to record that AFP 2.0 file information is covered by the same temporary fallback model.
This implements only the read-only path-based subset; richer AFP 2.0 behavior remains future Mac-namespace work.
Do not include the AFP Get File Information subfunction byte in the NWRequestSimple payload when the request is already sent through NCPC_SFN().
libncp's subfunction request helper supplies the NCP 0x23 AFP subfunction on the wire. The smoke test also placed 0x05 as the first byte of its local payload, so mars_nwe received a duplicated subfunction byte. The server then decoded the low byte of the request mask as the path length, producing a boundary-check failure with path_len=255 before the path could be resolved.
Build the smoke-test payload as the data following the subfunction byte: Volume Number, AFP Entry ID, Request Bit Map, Path String Length, and Path String. This matches the server-side decoder, which sees the subfunction byte at afp_req[0].
This changes only the Linux smoke test; server AFP protocol behavior is unchanged.
Wire NCP 0x23/0x05 AFP Get File Information to a conservative read-only reply
for SYS:-style paths.
The WebSDK documents NCP 0x2222/35/05 as taking a Volume Number, AFP Entry ID,
request bit map, and AFP path modifier string, and returning an AFP file
information record with entry id, parent id, attributes, data and resource fork
lengths, offspring count, NetWare dates, Finder Info, long and short names,
owner id, access privileges, and ProDOS information. The SDK headers expose the
same call as AFPGetFileInformation() and NWAFPGetFileInformation(), with the
wire reply matching RECPKT_AFPFILEINFO.
Resolve the supplied path through the existing mars_nwe path machinery, require
the optional Netatalk/libatalk backend as for the entry-id probe, and fill the
fields that can be derived safely from Unix stat data and the existing libatalk
helpers. Finder Info and resource fork length are read through nwatalk when
present; entry ids fall back to the existing stat-derived AFP id until
persistent CNID/AppleDouble ids are implemented. Parent id and ProDOS-specific
data remain zero for now.
Add a Linux afp_file_info_smoke test using ncpfs/libncp so the new call can be
exercised without an AppleTalk client. The test sends raw SYS:-style paths with
directory handle 0, matching the verified AFP Entry ID smoke-test path.
This implements only the read-only AFP file information query for path-based
requests; entry-id-only lookup, persistent CNID mapping, and write-side AFP
semantics remain future work.
