docs: audit direct file metadata stubs

AI.md

@@ -11,7 +11,7 @@ When the user says this is a new chat or asks to continue mars-nwe work, first
 read this file before proposing patches or making assumptions.  Then ask for, or
 use, the current project status that the user pasted into the chat.
 
-## Current handoff status after patch 0221
+## Current handoff status after patch 0222
 
 The current accepted patch line in this chat is expected to include:
 
@@ -20,12 +20,13 @@ The current accepted patch line in this chat is expected to include:
 - endpoint-audit/documentation patches `0199` through `0219`;
 - redesign clarification patch `0220-docs-record-print-queue-redesign-link.patch`;
 - endpoint-audit patch `0221-docs-audit-ncp-extension-stubs.patch`;
-- latest expected patch name: `0221-docs-audit-ncp-extension-stubs.patch`.
+- endpoint-audit patch `0222-docs-audit-direct-file-metadata-stubs.patch`;
+- latest expected patch name: `0222-docs-audit-direct-file-metadata-stubs.patch`.
 
 When continuing in a new chat, first ask the user which patch was actually last
-applied.  If they confirm `0221`, build the next patch as `0222-...` against a
-tree that already contains `0221`.  If they only applied through `0220`, apply or
-rebuild `0221` before continuing endpoint work.  If any patch failed or was skipped, rebuild
+applied.  If they confirm `0222`, build the next patch as `0223-...` against a
+tree that already contains `0222`.  If they only applied through `0221`, apply or
+rebuild `0222` before continuing endpoint work.  If any patch failed or was skipped, rebuild
 against the last confirmed applied patch instead of assuming the file in
 `/mnt/data` was accepted.
 
@@ -74,7 +75,12 @@ NCP Extension note from patch `0221`:
 - Future owner is an extension registry/provider.  Do not route extension
   payloads through `nwserv` as a data-plane broker; `nwserv` remains only
   control-plane/supervision/registry.
-- The next patch number should be `0222` if `0221` was applied.
+- Patch `0222` audits the remaining old direct file-metadata/open-create
+  compatibility slots SDK `0x2222/79`, `0x2222/84`, and `0x2222/85` / wire
+  `0x4f`, `0x54`, and `0x55`.  No active top-level handlers existed; the patch
+  records disabled `#if 0` stubs in `src/nwconn.c`.  Future owner is the
+  filesystem/namespace provider, not NDS.
+- The next patch number should be `0223` if `0222` was applied.
 
 Print/queue redesign note from patch `0220`:
 
@@ -235,10 +241,15 @@ Latest endpoint audit note:
 - Future implementation needs an extension registry/provider.  `nwserv` may
   supervise/register providers but must not become the data-plane broker for
   extension payloads.
+- Patch `0222` audits SDK `0x2222/79`, `0x2222/84`, and `0x2222/85` / wire
+  `0x4f`, `0x54`, and `0x55` as old direct file-metadata/open-create and
+  sparse-data compatibility gaps.  It adds disabled `#if 0` stubs next to the
+  old direct file-I/O switch in `src/nwconn.c`; future owner is the
+  filesystem/namespace provider.
 - Previous print note still applies: direct `17/xx` spool NCPs are only the
   old direct-spool compatibility surface; queue-backed printing already exists.
 
-The next patch number should be `0222` if `0221` was applied.  Likely next
+The next patch number should be `0223` if `0222` was applied.  Likely next
 blocks are deeper `0x2222/23` bindery/property/admin subfunction coverage,
 SDK `0x2222/90` scope, or another user-selected endpoint family.
 

TODO.md

@@ -222,13 +222,15 @@ Present in the code but not yet fully endpoint-audited:
   There is no active extension registry/provider yet, and `nwserv` must remain
   a control-plane registry/supervisor rather than a data-plane broker for
   extension payloads.
+- SDK `0x2222/79`, `0x2222/84`, and `0x2222/85` / wire `0x4f`, `0x54`, and
+  `0x55` are source-stub-audited as old direct file-metadata/open-create and
+  sparse-data compatibility calls.  Patch 0222 records disabled `#if 0` slots
+  in `src/nwconn.c`; future implementation belongs to the filesystem/namespace
+  provider and should not be confused with NDS directory-object attributes.
 
 SDK-listed blocks that do not currently show a top-level handler in
 `src/nwconn.c`:
 
-- SDK `0x2222/79`, `0x2222/84`, and `0x2222/85` / wire `0x4f`, `0x54`, and
-  `0x55` are listed by the SDK/PDF for later file/extended-data functions, but
-  no top-level handlers have been identified yet.
 - SDK `0x2222/90` / wire `0x5a` Data Migration/Compression/Parse Tree,
   SDK `0x2222/92` / wire `0x5c` SecretStore, SDK `0x2222/123` / wire `0x7b`
   service-address enumeration, and SDK `0x2222/131` / wire `0x83`

src/nwconn.c

@@ -6893,6 +6893,59 @@ static int handle_ncp_serv(void)
                   }
                   break;
 
+#if 0
+      case 0x4f : /* 79 Set File Extended Attributes / wire 0x4f.
+                   * Source outcome: no active top-level handler exists.
+                   * Stub scope: NetWare 2.x/3.x/4.x compatibility, so this
+                   * eligible missing direct file-metadata endpoint is recorded
+                   * here instead of being left only in TODO.md.
+                   *
+                   * Request: FunctionCode 79, NewFileAttributes,
+                   * DirectoryHandle, SearchAttributes, FileNameLen, FileName.
+                   * Reply: no payload; Completion reports privilege, in-use,
+                   * memory, disk-map, or success status.
+                   * Future owner: filesystem/namespace provider.  This is file
+                   * metadata, not NDS directory-object metadata.
+                   */
+                  completition = 0xfb;
+                  break;
+
+      case 0x54 : /* 84 Open/Create File (old) / wire 0x54.
+                   * Source outcome: no active top-level handler exists.
+                   * Stub scope: old direct file compatibility.  The active
+                   * 67/76/77 and 87/01 paths cover adjacent open/create
+                   * compatibility, but not this exact ActionFlag-style old
+                   * direct NCP.
+                   *
+                   * Request: old DirectoryHandle/SearchAttributes/ActionFlag
+                   * open-create layout with file attributes/path fields.
+                   * Reply: old six-byte FileHandle slot plus file information.
+                   * Difference to nearby implemented paths: 84 carries the
+                   * explicit ActionFlag values ACTION_OPEN, ACTION_REPLACE,
+                   * and ACTION_CREATE, while current MARS-NWE compatibility
+                   * paths use separate function numbers and create modes.
+                   * Future owner: filesystem/namespace provider.
+                   */
+                  completition = 0xfb;
+                  break;
+
+      case 0x55 : /* 85 Get Sparse File Data Block Bit Map / wire 0x55.
+                   * Source outcome: no active top-level handler exists.
+                   * Stub scope: NetWare 3.x/4.x file metadata/extended-data
+                   * compatibility.
+                   *
+                   * Request: SubFuncStrucLen 10, old six-byte FileHandle,
+                   * StartingOffset Lo-Hi.
+                   * Reply: AllocationBlockSize Lo-Hi, four reserved bytes,
+                   * then a 512-byte sparse-data bitmap.
+                   * Future owner: filesystem/namespace provider; requires
+                   * sparse-file awareness in the underlying host filesystem
+                   * layer before it can return meaningful data.
+                   */
+                  completition = 0xfb;
+                  break;
+#endif
+
 #if WITH_NAME_SPACE_CALLS
       case 0x56 : /* SDK 86 Extended Attribute group / wire 0x56.
                    * Coverage: forwarded to handle_func_0x56() in namspace.c.