From ae4cb39790affeb992167a018ba035276c18af30 Mon Sep 17 00:00:00 2001 From: Mario Fetka Date: Fri, 29 May 2026 20:39:48 +0200 Subject: [PATCH] docs: annotate remaining NCP endpoint stubs Add SDK/protocol context comments for the remaining known nwconn.c endpoint stubs and partial implementations. Document the intended behavior and follow-up work for Lock File Set, Release Logical Record, Restore Directory Handle, Get Extended Volume Information, and Clear Physical Record Set. Also add matching TODO.md entries so these compatibility gaps are tracked outside inline source comments. This is documentation-only and does not change NCP behavior. --- TODO.md | 28 ++++++++++++++++++ src/nwconn.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 100 insertions(+), 9 deletions(-) diff --git a/TODO.md b/TODO.md index 3564839..03f97ea 100644 --- a/TODO.md +++ b/TODO.md @@ -51,6 +51,34 @@ Follow-up: - `NOPASSUSER` type `0x0001`, property `GROUPS_I'M_IN` - `GUEST` type `0x0001`, property `GROUPS_I'M_IN` + +### NCP endpoint SDK documentation / stub audit + +Current status: + +- Several legacy NCP endpoints in `src/nwconn.c` are implemented only as + disabled stubs, explicit `0xfb` unsupported replies, or success/no-op dummies. +- The known candidates now have inline SDK-context comments so future work can + start from the documented wire semantics instead of from guesswork. + +Follow-up: + +- Implement or deliberately reject the following endpoints after client evidence + or direct protocol tests: + - `NCP 0x04 Lock File Set`: lock the current task's logged file set; related + release/clear set calls already use `share_handle_lock_sets()`. + - `NCP 0x0c Release Logical Record`: re-enable and test the release-only + logical-record path, distinct from `0x0b` clear/unlog. + - `NCP 0x16/0x18 Restore Directory Handle`: verify the exact SDK + request/reply layout, then implement the documented function 22 / + subfunction 24 directory-handle semantics. + - `NCP 0x16/0x33 Get Extended Volume Information`: return the documented + extended `VolumeInfo` structure and volume name instead of `0xfb`. + - `NCP 0x1f Clear Physical Record Set`: replace the current dummy with a real + task-level physical-record set clear/unlock operation. +- Keep SDK details close to the corresponding endpoint in `nwconn.c`, and keep + broader prioritization/status here in `TODO.md`. + ## Printing / Queue backend ### Q_UNIX_PRINT backend status diff --git a/src/nwconn.c b/src/nwconn.c index 978d84a..da4c455 100644 --- a/src/nwconn.c +++ b/src/nwconn.c @@ -440,9 +440,20 @@ static int handle_ncp_serv(void) break; #if 0 - case 0x4 : { /* Lock File Set */ + case 0x4 : { /* Lock File Set */ + /* + * TODO(ncp-compat): Implement NCP 0x04 Lock File Set. + * + * SDK context: locks every file previously entered in this task's + * file log table by Log File (0x03). This is the set-oriented + * companion of Release File Set (0x06) and Clear File Set (0x08), + * which are already wired through share_handle_lock_sets(). + * + * Compatibility note: preserve NetWare's logged-set semantics; this + * is not the same as locking one pathname supplied by the request. + */ - } + } break; #endif @@ -513,8 +524,15 @@ static int handle_ncp_serv(void) } break; - case 0xb : /* Clear Logical Record ?? */ - /* case 0xc :*/ { /* Release Logical Record ?? */ + case 0xb : /* Clear Logical Record */ + /* case 0xc :*/ { /* Release Logical Record */ + /* + * TODO(ncp-compat): Re-enable and test NCP 0x0c Release Logical + * Record. The implementation below already has the intended + * distinction: 0x0b clears a logical record (unlock + unlog), while + * 0x0c should only release/unlock it and leave it logged for later + * Lock Logical Record Set calls. + */ struct INPUT { uint8 header[7]; /* Requestheader */ uint8 len; /* synch name len */ @@ -979,8 +997,25 @@ static int handle_ncp_serv(void) break; #if 0 - case 0x18 : { /* restore directory handle */ - ????????? + case 0x18 : { /* Restore Directory Handle */ + /* + * TODO(ncp-compat): Implement NCP 0x16/0x18 + * Restore Directory Handle. + * + * SDK context: this is function 22 (0x16), subfunction 24 + * (0x18). It belongs to the old directory-handle family + * and should be implemented only after the exact SDK + * request/reply layout and handle-lifetime semantics are + * verified. It is related to the directory-handle table + * calls implemented nearby: + * 0x12 Alloc Permanent Directory Handle + * 0x13 Alloc Temporary Directory Handle + * 0x14 Deallocate Directory Handle + * 0x16 Alloc Special Temporary Directory Handle + * + * Do not guess here: old DOS clients may depend on exact + * permanent-vs-temporary handle lifetime semantics. + */ } break; #endif @@ -1591,10 +1626,27 @@ static int handle_ncp_serv(void) case 0x33 : { /* Get Extended Volume Information */ -#if 0 + /* + * TODO(ncp-compat): Implement NCP 0x16/0x33 + * Get Extended Volume Information. + * + * SDK context: function 22 (0x16), subfunction 51 (0x33) takes + * a VolumeNumber and returns VolInfoReplyLen, a VolumeInfo + * structure, and the volume name. The documented VolumeInfo + * structure contains fields such as VolumeType, StatusFlagBits, + * SectorSize, SectorsPerCluster, VolumeSizeInClusters, + * FreedClusters, directory-entry counters, EA counters, a + * DirectoryServicesObjectID, and VolumeLastModifiedDateAndTime. + * + * The existing older volume-info calls return only the small + * NetWare 2.x/3.x style subset, so filling this reply needs a + * deliberate mapping from Unix filesystem data to the extended + * SDK structure. + */ +#if 0 int volume = (int) *(p+1); /* next 3 byte are low bytes of volume */ -#endif +#endif completition = 0xfb; /* not known yet */ } break; @@ -1947,7 +1999,18 @@ static int handle_ncp_serv(void) } break; - case 0x1f : /* Clear Physical Record Set, DUMMY */ + case 0x1f : /* Clear Physical Record Set, DUMMY */ + /* + * TODO(ncp-compat): Implement full NCP 0x1f Clear Physical + * Record Set semantics instead of this success/no-op dummy. + * + * SDK context: this removes all byte ranges in the calling + * task's physical-record log set; if a range is locked, it + * must be unlocked as part of clearing. The individual + * physical-record calls 0x1a/0x1c already use + * nw_log_physical_record(), but this set operation should + * walk and clear the task's logged physical-record table. + */ XDPRINTF((1,0,"Clear Physical Record Set called, still DUMMY")); break;