mars-nwe/tests/afp/AFP_ENDPOINT_INVENTORY.md

AFP endpoint inventory before final audit

This file records the current mars_nwe AFP endpoint inventory before the final WebSDK / Novell NWAFP header audit. The generated helper output should remain the source of truth for fresh checks:

tests/afp/afp_endpoint_inventory.py

Current endpoint coverage

Subfn	Name	Status	Backend discipline
0x01	AFP Create Directory	implemented	mars_nwe path/namespace and object lifecycle
0x02	AFP Create File	implemented	mars_nwe path/namespace and object lifecycle; AFP xattr only for file entry-id metadata
0x03	AFP Delete	implemented	mars_nwe path/namespace and object lifecycle
0x04	AFP Get Entry ID From Name	implemented / validating	mars_nwe path/namespace; entry-id-relative bases are directory entry IDs only
0x05	AFP Get File Information	implemented	mars_nwe path/namespace plus mars_nwe attributes/rights; AFP xattrs only for FinderInfo / entry-id
0x06	AFP Get Entry ID From NetWare Handle	implemented	mars_nwe file-handle lookup, then AFP entry-id metadata
0x07	AFP Rename	implemented	mars_nwe path/namespace and object lifecycle; AFP entry-id metadata follows renamed files
0x08	AFP Open File Fork	implemented for data fork	mars_nwe file handles; resource fork remains unsupported
0x09	AFP Set File Information	implemented	mars_nwe attributes/archive/fileinfo/trustee; AFP xattrs only for FinderInfo / AFP-only bits
0x0a	AFP Scan File Information	implemented for path and directory entry-id starts	mars_nwe path/namespace; entry IDs must resolve to directories
0x0b	AFP Alloc Temporary Dir Handle	implemented	mars_nwe path/namespace and directory handles
0x0c	AFP Get Entry ID From Path Name	implemented / validating	mars_nwe path/namespace; AFP entry-id metadata for files
0x0d	AFP 2.0 Create Directory	implemented	mars_nwe path/namespace and object lifecycle
0x0e	AFP 2.0 Create File	implemented	mars_nwe path/namespace and object lifecycle; AFP xattr only for file entry-id metadata
0x0f	AFP 2.0 Get File Information	implemented	same backend discipline as 0x05
0x10	AFP 2.0 Set File Information	implemented	same backend discipline as 0x09
0x11	AFP 2.0 Scan File Information	implemented for path and directory entry-id starts	same backend discipline as 0x0a
0x12	AFP Get DOS Name From Entry ID	implemented	mars_nwe path/namespace and AFP entry-id reverse lookup
0x13	AFP Get Macintosh Info On Deleted Files	unsupported / backend-dependent	requires mars_nwe salvage/deleted-entry backend first

Backend rules for the final audit

AFP handlers must not grow independent filesystem semantics. The final audit must verify that each endpoint continues to use the mars_nwe core backend:

• Create, delete, rename, and directory operations go through mars_nwe path/namespace and object lifecycle helpers.
• Data-fork open/read/write/close uses mars_nwe file handles and the normal NetWare file I/O path. AFP 0x08 opens the data fork; subsequent I/O and close use normal NetWare handle semantics.
• Rights checks use mars_nwe trustee/effective-rights logic.
• Hidden, system, archive, timestamps, creator/modifier, and backup/archive metadata use mars_nwe attribute/archive/fileinfo paths.
• AFP-only xattrs are limited to:
  • user.org.mars-nwe.afp.entry-id
  • user.org.mars-nwe.afp.finder-info
  • user.org.mars-nwe.afp.attributes only for future AFP-only bits
• Resource forks remain unsupported and should return the documented completion code instead of inventing a parallel storage backend.
• Deleted-file Macintosh metadata (0x13) must wait for the mars_nwe salvage backend and must not perform an AFP-local deleted-file scan.

Known final-audit items

One unsupported item should stay visible until the WebSDK / Novell header comparison is completed:

1. 0x13 is intentionally unsupported because the salvage/deleted-entry backend is not part of the current AFP slice.

Resolved WebSDK compatibility item:

• 0x0a / 0x11 entry-id-only scan requests are supported when the base entry ID resolves to a directory through mars_nwe namespace/basehandle logic.

Final comparison checklist

When doing the final WebSDK / Novell NWAFP header pass, compare:

• AFP subfunction numbers and names.
• Request field order, sizes, and byte order.
• Reply field order, sizes, and byte order.
• Bitmap meanings for get/set/scan information calls.
• Legacy vs AFP 2.0 layout variants.
• Completion codes for unsupported resource forks, insufficient rights, bad handles, missing entries, bad paths, and unsupported deleted-file metadata.
• Whether each implemented endpoint still routes NetWare semantics through mars_nwe functions rather than AFP-local shortcuts.