Files
mars-nwe/tests/afp/AFP_WEBSK_AUDIT_FINDINGS.md
OpenAI ac79fa9d22
All checks were successful
Source release / source-package (push) Successful in 47s
nwconn: support AFP scan from directory entry IDs
2026-05-31 09:03:43 +02:00

7.1 KiB

AFP WebSDK audit findings

This records the concrete WebSDK pass done against the uploaded SDK tree before turning the final audit checklist into implementation decisions.

Sources inspected

The available uploaded WebSDK tree contained AFP reference HTML pages rather than a standalone nwafp.h header. The checked source paths were:

/mnt/data/websdk_full/websdk/htmldoc/nwhtm/TOCMap.txt
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/projmap.txt
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R001.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R002.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R003.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R004.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R005.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R006.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R007.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R008.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R009.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R010.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R011.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R012.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R013.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R014.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R015.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R016.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R017.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0002R018.htm

The deleted-file dependency check also inspected the normal salvage reference pages:

/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0010R024.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0010R027.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0010R038.htm
/mnt/data/websdk_full/websdk/htmldoc/nwhtm/redleg14/a_apiref/0010R039.htm

AFP subfunction numbers

The WebSDK AFP reference pages confirm this NCP 0x2222 / function 35 subfunction map:

Subfn WebSDK page Name mars_nwe inventory status
0x01 0002R006.htm AFP Create Directory implemented
0x02 0002R007.htm AFP Create File implemented
0x03 0002R008.htm AFP Delete implemented
0x04 0002R010.htm AFP Get Entry ID From Name implemented / validating
0x05 0002R013.htm AFP Get File Information implemented
0x06 0002R011.htm AFP Get Entry ID From NetWare Handle implemented
0x07 0002R016.htm AFP Rename implemented
0x08 0002R015.htm AFP Open File Fork implemented for data fork
0x09 0002R018.htm AFP Set File Information implemented
0x0a 0002R017.htm AFP Scan File Information implemented for path and directory entry-id starts
0x0b 0002R005.htm AFP Alloc Temporary Directory Handle implemented
0x0c 0002R012.htm AFP Get Entry ID From Path Name implemented
0x0d 0002R001.htm AFP 2.0 Create Directory implemented
0x0e 0002R002.htm AFP 2.0 Create File implemented
0x0f 0002R013.htm AFP 2.0 Get File Information implemented through shared handler
0x10 0002R004.htm AFP 2.0 Set File Information implemented through shared semantics
0x11 0002R003.htm AFP 2.0 Scan File Information implemented for path and directory entry-id starts
0x12 0002R009.htm AFP Get DOS Name From Entry ID implemented
0x13 0002R014.htm AFP Get Macintosh Info On Deleted Files unsupported / salvage-backend dependent

No extra AFP subfunction beyond 0x13 appeared in the WebSDK AFP reference TOC.

Layout findings

The current mars_nwe request/reply layouts match the WebSDK direction for the implemented compatibility slice:

  • 0x04 Get Entry ID From Name uses volume, AFP entry ID, path length, and an AFP-style path relative to the entry ID, then returns a 32-bit AFP entry ID.
  • 0x05 and 0x0f Get File Information use volume, AFP entry ID, request bitmap, path length, and AFP-style path, then return the AFP information record.
  • 0x09 and 0x10 Set File Information use volume, AFP entry ID, request bitmap, attributes, date/time fields, FinderInfo, ProDOS info, and relative AFP path. The server intentionally implements only the safe subset that maps to mars_nwe metadata and AFP-only xattrs.
  • 0x0a and 0x11 Scan File Information use volume, AFP entry ID, last-seen ID, desired response count, search bitmap, request bitmap, path length, and an AFP-style path relative to the entry ID.
  • 0x0b Alloc Temporary Directory Handle uses volume, AFP entry ID, path length, and an AFP-style path relative to the entry ID, then returns a NetWare directory handle and access-rights byte.
  • 0x0c Get Entry ID From Path Name is the older NetWare-directory-handle based lookup and returns a 32-bit AFP entry ID.
  • 0x08 Open File Fork returns AFP entry ID, fork length, and a NetWare access handle. The WebSDK page confirms the data/resource fork indicator and access mode bits. mars_nwe currently supports the data fork and rejects resource fork requests until a real backend exists.
  • 0x13 Get Macintosh Info On Deleted Files is not a live path lookup. Its request is volume number plus DOS directory entry, and its reply is FinderInfo, ProDOS info, resource fork size, and deleted file name.

Important implementation decisions

Entry-id-only Scan File Information

The WebSDK Scan File Information pages describe the path string as relative to AFP Entry ID. mars_nwe supports the compatible directory case: a request with a directory AFP entry ID and an empty path scans that directory.

The implementation remains intentionally narrow:

  1. Entry-id scan bases must resolve to directories through mars_nwe namespace/basehandle logic.
  2. The existing mars_nwe directory scan path is reused after resolution.
  3. File AFP xattr entry IDs are not valid scan bases.

AFP 0x13 should remain unsupported for this slice

The WebSDK 0x13 page makes this call dependent on deleted-file state: the request is keyed by volume and DOS directory entry, and the reply describes a deleted Macintosh directory entry. The WebSDK file services chapter also contains the normal salvage family:

  • Scan Salvageable Files
  • Recover Salvageable File
  • Purge Salvageable File
  • Scan Salvageable File (old)

Therefore 0x13 should stay unsupported until mars_nwe has a verified salvage/deleted-entry backend. It must not be implemented as an AFP-local scan of live paths or filesystem trash.

Result

The WebSDK pass does not require renaming the AFP endpoint map again. The remaining concrete work before closing the current AFP slice is:

  1. Keep 0x13 documented unsupported until salvage exists.
  2. Re-run tests/afp/afp_endpoint_inventory.py and the AFP smoke suite.
  3. Fill the final audit table with these WebSDK source paths and results.