docs: document ncp23 file info layouts

This commit is contained in:
Mario Fetka
2026-06-01 22:02:42 +00:00
parent 98cf7e1621
commit 64c12f7a28
2 changed files with 120 additions and 0 deletions

37
TODO.md
View File

@@ -408,6 +408,43 @@ Follow-up:
items. Continue with the next non-4.x/OES-only group after this block.
#### File Server Environment group 0x2222/23
Current status:
- `NCP 0x2222/23` is handled in `src/nwconn.c` for the locally parsed
file-information subfunctions, while other login, bindery, queue, and
management subfunctions are forwarded to `src/nwbind.c` or existing queue
prehandlers.
- The group header is documented inline as `SubFuncStrucLen` (Hi-Lo),
`SubFunctionCode`, and subfunction payload.
- Endpoint numbers in SDK/PDF/WebSDK prose are decimal unless explicitly
prefixed. The local subfunction cases audited so far are:
- SDK `23/15` / wire `0x0f` Scan File Information
- SDK `23/16` / wire `0x10` Set File Information
- SDK `23/15` request payload offsets match the current parser:
`LastSearchIndex`, `DirectoryHandle`, `SearchAttributes`, `FileNameLen`,
and `FileName`. The reply shape also matches the documented fixed file
information block. The SDK/PDF/WebSDK documents `LastSearchIndex` and
`NextSearchIndex` as Lo-Hi words, while the current code uses
`GET_BE16()` and `U16_TO_BE16()`.
- SDK `23/16` request payload field order matches the current parser. The
code copies the documented status fields into `NW_FILE_INFO` after its
14-byte DOS-name prefix and then passes the documented directory handle,
search attributes, and filename to `nw_set_file_information()`.
- Include cross-checks: `NWScanFileInformation()`/`NWIntScanFileInformation()`
and `NWSetFileInformation()` in `nwfile.h` refer to this same SDK-level
file-information family.
Follow-up:
- Verify SDK `23/15` search-index byte order against a real old requester or
direct test caller before changing the current big-endian parser/reply.
- Audit the remaining forwarded `0x2222/23` login, bindery, queue, and
management subfunctions in the files that actually handle them instead of
treating the `nwconn.c` forwarding points as complete local implementations.
### Extended volume information field mapping
Current status:

View File

@@ -5160,6 +5160,29 @@ static int handle_ncp_serv(void)
case 0x17 : { /* FILE SERVER ENVIRONMENT */
/*
* NCP 0x2222/23 is the File Server Environment function group.
* SDK/PDF endpoint numbers are decimal; the nested wire
* SubFunctionCode is shown as hex in the switch cases below.
*
* SDK group request header:
*
* word SubFuncStrucLen (Hi-Lo)
* byte SubFunctionCode
* ... subfunction-specific payload
*
* The dispatcher consumes the three-byte group header as:
*
* requestdata[0..1] SubFuncStrucLen
* requestdata[2] SubFunctionCode
* requestdata[3..] payload passed as rdata
*
* This block only documents the file-information subfunctions
* handled locally here. Several login, bindery, queue, and
* management subfunctions in this group are intentionally forwarded
* to nwbind or to existing queue prehandlers and should be audited
* in the target file when their turn comes.
*/
/* uint8 len = *(requestdata+1); */
uint8 ufunc = *(requestdata+2);
uint8 *rdata = requestdata+3;
@@ -5187,6 +5210,39 @@ static int handle_ncp_serv(void)
case 0x0f: { /* Scan File Information */
/*
* SDK 23/15 / wire 0x0f Scan File Information.
*
* SDK/PDF/WebSDK request payload after the group header:
* word LastSearchIndex (Lo-Hi)
* byte DirectoryHandle
* byte SearchAttributes
* byte FileNameLen
* byte FileName[FileNameLen]
*
* SDK reply:
* word NextSearchIndex (Lo-Hi)
* byte FileName[14]
* byte FileAttributes
* byte ExtendedFileAttributes
* long FileSize (Hi-Lo)
* word FileCreationDate (Hi-Lo)
* word LastAccessedDate (Hi-Lo)
* word LastUpdateDate (Hi-Lo)
* word LastUpdateTime (Hi-Lo)
* long FileOwnerID (Hi-Lo)
* word LastArchiveDate (Hi-Lo)
* word LastArchiveTime (Hi-Lo)
* byte Reserved[56]
*
* The current parser uses the documented payload offsets and
* returns the documented fixed-size information block. The SDK
* labels the search-index words as Lo-Hi, while this code reads
* and writes them with GET_BE16()/U16_TO_BE16(); keep that as
* an audit item until old requester behaviour is verified.
* Include cross-check: NWScanFileInformation() maps to the same
* SDK call through NWIntScanFileInformation().
*/
struct INPUT {
uint8 header[7]; /* Requestheader */
uint8 div[3]; /* 0, len + ufunc */
@@ -5233,6 +5289,33 @@ static int handle_ncp_serv(void)
break;
case 0x10: { /* Set File Information */
/*
* SDK 23/16 / wire 0x10 Set File Information.
*
* SDK/PDF/WebSDK request payload after the group header:
* byte FileAttributes
* byte ExtendedFileAttributes
* long FileSize (Hi-Lo; documented as ignored by the server)
* word FileCreationDate (Hi-Lo)
* word LastAccessedDate (Hi-Lo)
* word LastUpdateDate (Hi-Lo)
* word LastUpdateTime (Hi-Lo)
* long UniqueOwnerID (Hi-Lo)
* word LastArchiveDate (Hi-Lo)
* word LastArchiveTime (Hi-Lo)
* byte Reserved[56]
* byte DirectoryHandle
* byte SearchAttributes
* byte FileNameLen
* byte FileName[FileNameLen]
*
* The current parser mirrors the documented field order by
* copying the status part into NW_FILE_INFO after its 14-byte
* DOS filename prefix, then passing DirectoryHandle,
* SearchAttributes, and FileName to nw_set_file_information().
* Include cross-check: NWSetFileInformation() exposes this SDK
* call in nwfile.h.
*/
struct INPUT {
uint8 header[7]; /* Requestheader */
uint8 div[3]; /* 0, len + ufunc */