docs: document ncp22 directory mutation layouts

This commit is contained in:
OpenAI
2026-06-01 19:46:10 +00:00
committed by Mario Fetka
parent 492befda0d
commit 8ccc4cbea2
2 changed files with 103 additions and 3 deletions

21
TODO.md
View File

@@ -196,13 +196,30 @@ Current status:
second payload byte, but the remarks describe a source handle; MARS-NWE
parses the byte as `SourceDirectoryHandle`. This is documented inline but
not changed.
- No NetWare 3.x SDK/PDF entries were found for direct `22/07`, `22/08`, or
`22/09` during this audit. The next documented direct directory calls
continue at `22/0a`.
- `22/0a` Create Directory, `22/0b` Delete Directory, `22/0d` Add Trustee to
Directory, `22/0e` Delete Trustee from Directory, and `22/0f` Rename
Directory now have inline request-layout documentation.
- `22/0d` and `22/0e` match the SDK/PDF payload layouts. `22/0f` matches the
payload layout; the old PDF labels this call's `SubFuncStrucLen` as Lo-Hi,
but MARS-NWE dispatches the group before using that length word and the
surrounding NCP 22 group header is otherwise documented as Hi-Lo.
- `22/0a` and `22/0b` preserve the documented offset of
`DirectoryAccessMask`, but the current implementation does not use that
field when creating or deleting the directory.
Follow-up:
- Continue the `0x2222/22` audit from `22/0a` Create Directory onward, keeping
each patch to a small logical endpoint block.
- Verify the documented `22/00` source-handle interpretation against an old
requester or direct test caller before changing behavior.
- Decide whether `22/0a` and `22/0b` should apply or validate the documented
`DirectoryAccessMask` byte, or whether ignoring it is required for old
requester compatibility.
- Continue the `0x2222/22` audit from the directory-handle allocation block
(`22/12`, `22/13`, `22/16`, `22/14`, `22/15`) onward, keeping each patch to
a small logical endpoint block.
### Extended volume information field mapping

View File

@@ -3275,6 +3275,10 @@ static int handle_ncp_serv(void)
* 22/05 Get Volume Number
* 22/06 Get Volume Name
*
* No NetWare 3.x SDK/PDF entries were found for direct 22/07,
* 22/08, or 22/09 in this group during this audit. The next
* documented direct directory calls continue at 22/0a.
*
* Layout notes below document the current parser; this patch does not
* change wire behavior.
*/
@@ -3512,6 +3516,21 @@ static int handle_ncp_serv(void)
case 0xa : { /* create directory */
/******** Create Dir *********************/
/*
* NCP 0x2222/22/10 Create Directory.
*
* SDK request payload:
* byte DirectoryHandle
* byte DirectoryAccessMask
* byte DirectoryPathLen
* byte DirectoryPath[DirectoryPathLen]
*
* SDK reply: completion code only.
*
* Parser comparison: the current parser reads the documented
* handle/path fields. It does not currently consume the
* DirectoryAccessMask field beyond preserving its offset.
*/
int dir_handle = (int) *(p+1);
#if 0
int rightmask = (int) *(p+2);
@@ -3525,9 +3544,25 @@ static int handle_ncp_serv(void)
case 0xb : { /* delete dirrctory */
/******** Delete DIR *********************/
/*
* NCP 0x2222/22/11 Delete Directory.
*
* SDK request payload:
* byte DirectoryHandle
* byte DirectoryAccessMask
* byte DirectoryPathLen
* byte DirectoryPath[DirectoryPathLen]
*
* SDK reply: completion code only.
*
* Parser comparison: the current parser reads the documented
* handle/path fields. Older source comments called the
* second byte reserved, but the SDK names it
* DirectoryAccessMask; the current code ignores it.
*/
int dir_handle = (int) *(p+1);
#if 0
int reserved = (int) *(p+2); /* Res. by NOVELL */
int reserved = (int) *(p+2); /* DirectoryAccessMask */
#endif
int pathlen = (int) *(p+3);
uint8 *path = p+4;
@@ -3538,6 +3573,21 @@ static int handle_ncp_serv(void)
case 0xd : { /* Add Trustees to DIR */
/******** AddTrustesstoDir ***************/
/*
* NCP 0x2222/22/13 Add Trustee to Directory.
*
* SDK request payload:
* byte DirectoryHandle
* long TrusteeID (Hi-Lo)
* byte TrusteeAccessMask
* byte DirectoryPathLen
* byte DirectoryPath[DirectoryPathLen]
*
* SDK reply: completion code only.
*
* Parser comparison: current INPUT layout matches the
* documented NetWare 3.x request layout.
*/
struct INPUT {
uint8 header[7]; /* Requestheader */
uint8 div[3]; /* 0x0, dlen, ufunc */
@@ -3577,6 +3627,21 @@ static int handle_ncp_serv(void)
break;
case 0xe : { /* remove trustees */
/*
* NCP 0x2222/22/14 Delete Trustee from Directory.
*
* SDK request payload:
* byte DirectoryHandle
* long TrusteeID (Hi-Lo)
* byte Reserved
* byte DirectoryPathLen
* byte DirectoryPath[DirectoryPathLen]
*
* SDK reply: completion code only.
*
* Parser comparison: current INPUT layout matches the
* documented NetWare 3.x request layout.
*/
struct INPUT {
uint8 header[7]; /* Requestheader */
uint8 div[3]; /* 0x0, dlen, ufunc */
@@ -3614,6 +3679,24 @@ static int handle_ncp_serv(void)
case 0xf : { /* rename dir */
/******** Rename DIR *********************/
/*
* NCP 0x2222/22/15 Rename Directory.
*
* SDK request payload:
* byte DirectoryHandle
* byte DirectoryPathLen
* byte DirectoryPath[DirectoryPathLen]
* byte NewDirectoryPathLen
* byte NewDirectoryPath[NewDirectoryPathLen]
*
* SDK reply: completion code only.
*
* Parser comparison: current parser matches the payload
* order. The old PDF table labels SubFuncStrucLen for
* this call as Lo-Hi even though the NCP 22 group header is
* otherwise documented and parsed as Hi-Lo; MARS-NWE does
* not use that length word after dispatch.
*/
int dir_handle = (int) *(p+1);
int oldpathlen = (int) *(p+2);
uint8 *oldpath = p+3;