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 | implemented / salvage-backend adapter |
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:
0x04Get 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.0x05and0x0fGet File Information use volume, AFP entry ID, request bitmap, path length, and AFP-style path, then return the AFP information record.0x09and0x10Set 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.0x0aand0x11Scan 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.0x0bAlloc 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.0x0cGet Entry ID From Path Name is the older NetWare-directory-handle based lookup and returns a 32-bit AFP entry ID.0x08Open 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.0x13Get 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:
- Entry-id scan bases must resolve to directories through mars_nwe namespace/basehandle logic.
- The existing mars_nwe directory scan path is reused after resolution.
- File AFP xattr entry IDs are not valid scan bases.
AFP 0x13 is salvage-backed in 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 is implemented only after the verified mars_nwe
salvage/deleted-entry backend. It must remain a backend adapter, not 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:
- Keep
0x13documented as salvage-backed; do not add a second AFP deleted-file store. - Re-run
tests/afp/afp_endpoint_inventory.pyand the AFP smoke suite. - Fill the final audit table with these WebSDK source paths and results.