docs: document remaining ncp22 legacy directory layouts

This commit is contained in:
Mario Fetka
2026-06-01 20:44:35 +00:00
parent cb4d9c8a9e
commit 969eb5f4e7
2 changed files with 142 additions and 11 deletions

27
TODO.md
View File

@@ -265,6 +265,22 @@ Current status:
Sequence with `GET_BE32()` although the SDK/PDF documents Lo-Hi; it also
returns the normal directory scan structure from `nw_scan_a_directory()`
rather than the full documented Scan Directory Disk Space reply.
- `22/2a` Get Effective Rights for Directory Entry, `22/2b` Remove Extended
Trustee from Dir or File, `22/2d` Get Directory Information, `22/2e` Rename
Or Move (old), and `22/2f` Get Name Space Information now have inline
request/reply layout documentation and match the NetWare 1.x/2.x/3.x SDK/PDF
payload offsets used by the current parser.
- `22/2c` Get Volume and Purge Information matches the documented request
offset, but the PDF marks `TotalBlocks` as Hi-Lo while the remaining 32-bit
counters are Lo-Hi; current code uses `U32_TO_32()` for all counters.
- `22/30` Get Name Space Directory Entry matches the documented payload offsets;
the PDF does not label the `DOSSequence` byte order, and current code reads it
with `GET_32()`.
- `22/32` Get Object Effective Rights for Directory Entry and `22/33` Get
Extended Volume Information are documented by the local NDK/Core Protocols PDF
as NetWare 4.x/5.x calls. They are intentionally not added as TODO work for
the NetWare 1.x/2.x/3.x compatibility audit slice, even though MARS-NWE has
compatibility code for some newer clients.
Follow-up:
@@ -299,8 +315,15 @@ Follow-up:
- Verify `22/28` Sequence byte order and reply shape; current code uses
`GET_BE32()` and delegates to the normal directory scan reply rather than the
documented Scan Directory Disk Space reply.
- Continue the `0x2222/22` audit from `22/30` Get Name Space Directory Entry
onward, keeping each patch to a small logical endpoint block.
- Verify `22/2c` Volume and Purge Information reply byte order for
`TotalBlocks`; the SDK/PDF marks only that field as Hi-Lo, while current code
emits all 32-bit counters with `U32_TO_32()`.
- Verify `22/30` DOSSequence byte order against an old requester or direct test
caller; current code uses `GET_32()` and the PDF table does not spell out the
order for that field.
- The NetWare 1.x/2.x/3.x-compatible `0x2222/22` endpoint layout pass is now
complete through the documented `22/48` namespace call. Continue with the
next non-4.x/OES-only group after this block.
### Extended volume information field mapping

View File

@@ -4542,6 +4542,21 @@ static int handle_ncp_serv(void)
break;
case 0x2a : { /* Get Eff. Rights of DIR's and Files */
/*
* NCP 0x2222/22/42 Get Effective Rights for Directory Entry.
*
* SDK request payload after the group header:
* byte DirHandle
* byte PathLen
* byte Path[PathLen]
*
* Reply:
* word AccessRights (Lo-Hi)
*
* Parser comparison: current code reads the documented
* payload offsets and returns the documented Lo-Hi rights
* word.
*/
struct XDATA {
uint8 eff_rights[2]; /* LO-HI */
} *xdata = (struct XDATA*) responsedata;
@@ -4574,6 +4589,22 @@ static int handle_ncp_serv(void)
break;
case 0x2b : { /* remove ext trustees */
/*
* NCP 0x2222/22/43 Remove Extended Trustee from Dir or File.
*
* SDK request payload after the group header:
* byte DirHandle
* long ObjectID (Hi-Lo)
* byte Unused
* byte PathLen
* byte Path[PathLen]
*
* No reply data.
*
* Parser comparison: current code reads DirHandle,
* ObjectID, the reserved byte, PathLen, and Path at the
* documented offsets.
*/
struct INPUT {
uint8 header[7]; /* Requestheader */
uint8 div[3]; /* 0x0, dlen, ufunc */
@@ -4610,6 +4641,29 @@ static int handle_ncp_serv(void)
break;
case 0x2c : { /* Get Volume and Purge Information */
/*
* NCP 0x2222/22/44 Get Volume and Purge Information.
*
* SDK request payload after the group header:
* byte VolumeNumber
*
* Reply:
* long TotalBlocks (Hi-Lo in the PDF)
* long FreeBlocks (Lo-Hi)
* long PurgeableBlocks (Lo-Hi)
* long NotYetPurgeableBlocks (Lo-Hi)
* long TotalDirEntries (Lo-Hi)
* long AvailableDirEntries (Lo-Hi)
* byte Reserved[4]
* byte SectorsPerBlock
* byte VolumeNameLen
* byte VolumeName[VolumeNameLen]
*
* Parser comparison: request offset matches. The current
* reply maps Unix filesystem totals to the legacy shape and
* uses U32_TO_32() for all 32-bit counters; the PDF marks
* only TotalBlocks as Hi-Lo while the rest are Lo-Hi.
*/
/* new Call since V3.11 */
/* ncpfs need this call */
int volume = (int) *(p+1);
@@ -4645,6 +4699,25 @@ static int handle_ncp_serv(void)
break;
case 0x2d : { /* Get Direktory Information */
/*
* NCP 0x2222/22/45 Get Directory Information.
*
* SDK request payload after the group header:
* byte DirHandle
*
* Reply:
* long TotalBlocks (Lo-Hi)
* long AvailableBlocks (Lo-Hi)
* long TotalDirEntries (Lo-Hi)
* long AvailableDirEntries (Lo-Hi)
* byte Reserved[4]
* byte SectorsPerBlock
* byte VolumeNameLen
* byte VolumeName[VolumeNameLen]
*
* Parser comparison: request offset and reply byte order
* match the documented legacy directory-information shape.
*/
int dir_handle = (int) *(p+1);
struct XDATA {
uint8 total_blocks[4];
@@ -4679,19 +4752,23 @@ static int handle_ncp_serv(void)
case 0x2e : { /* Rename or Move (old) */
/*
* NCP 22 / subfunction 46 (0x2e): Rename Or Move (old)
* NCP 0x2222/22/46 Rename Or Move (old).
*
* Request:
* byte source directory handle
* byte search attributes
* byte source path component count
* source path components: byte len + bytes, repeated
* byte destination directory handle
* byte destination path component count
* destination path components: byte len + bytes, repeated
* SDK request payload after the group header:
* byte SourceDirHandle
* byte SearchAttribute
* byte SourcePathComponentCount
* byte SourcePath[SourcePathLen]
* byte DestDirHandle
* byte DestPathComponentCount
* byte DestPath[DestPathLen]
*
* No reply data. This old call uses component-counted
* paths, unlike the plain length-prefixed NCP 69 rename.
*
* Parser comparison: current code decodes both component
* path lists in the documented order and supports different
* source/destination handles.
*/
uint8 srcpath[256];
uint8 dstpath[256];
@@ -4755,6 +4832,22 @@ static int handle_ncp_serv(void)
#if WITH_NAME_SPACE_CALLS
case 0x2f : { /* Fill namespace buffer */
/*
* NCP 0x2222/22/47 Get Name Space Information.
*
* SDK request payload after the group header:
* byte VolumeNumber
*
* Reply is a variable-length namespace/datastream inventory:
* DefinedNameSpaces, namespace names, DefinedDataStreams,
* stream-to-namespace mappings, loaded namespaces, volume
* namespaces, and volume data streams.
*
* Parser comparison: request offset matches. Reply is built
* by fill_namespace_buffer(); it reports MARS-NWE's known
* DOS/MAC/NFS/FTAM/OS2 namespace table and loaded/volume
* namespace lists in the documented variable layout.
*/
/* ncopy use this call */
int volume = (int) *(p+1);
/* (p+2) == 0xe4 or 0xe2 sometimes ???? */
@@ -4767,6 +4860,21 @@ static int handle_ncp_serv(void)
break;
case 0x30 : { /* Get Name Space Directory Entry */
/*
* NCP 0x2222/22/48 Get Name Space Directory Entry.
*
* SDK request payload after the group header:
* byte VolumeNumber
* long DOSSequence
* byte NameSpace
*
* Reply is the namespace-specific directory-entry record.
*
* Parser comparison: request offset matches. The PDF does
* not label DOSSequence byte order; current code reads it
* with GET_32() and get_namespace_dir_entry() returns the
* DOS NW_SCAN_DIR_INFO-shaped entry for the resolved base.
*/
int volume = (int) *(p+1);
uint32 basehandle = GET_32(p+2);
int namespace = (int) *(p+6);