docs: audit file commit search endpoints

This commit is contained in:
Test
2026-06-02 13:43:57 +00:00
committed by Mario Fetka
parent 1ca5d66432
commit 4597a0ee85
3 changed files with 159 additions and 10 deletions

View File

@@ -6022,6 +6022,28 @@ static int handle_ncp_serv(void)
case 0x3b : /* commit file to disk */
case 0x3d : /* commit file */
{
/*
* NCP 0x2222/59 Commit File and 0x2222/61 Commit
* File are old direct file-cache synchronization
* calls. Both requests carry the same six-byte
* NetWare file handle layout used by several old file
* calls:
*
* byte Reserved
* byte ExtendedFileHandle[2]
* byte FileHandle[4]
*
* SDK reply: no reply data. Completion reports the
* result of committing the handle to disk.
*
* Compared against the SDK/PDF and current parser:
* MARS-NWE ignores the reserved/extended high bytes and
* commits only the low four-byte handle via GET_32(),
* which matches the project's existing 32-bit host file
* handle model rather than preserving the full six-byte
* wire value. Both function numbers share this parser
* and response path.
*/
struct INPUT {
uint8 header[7]; /* Requestheader */
uint8 reserve;
@@ -6036,6 +6058,28 @@ static int handle_ncp_serv(void)
break;
case 0x3e : { /* FILE SEARCH INIT */
/*
* NCP 0x2222/62 File Search Initialize starts the old
* DOS directory-file search sequence.
*
* SDK request:
*
* byte DirectoryHandle
* byte DirectoryPathLen
* bytes DirectoryPath
*
* SDK reply:
*
* byte VolumeNumber
* word DirectoryID, Hi-Lo
* word SearchSequence, Hi-Lo
* byte DirectoryAccessRights
*
* Compared against the SDK/PDF and current parser: the
* request payload is read directly from requestdata[]
* after the FunctionCode byte, and the reply is encoded
* as the documented six-byte structure.
*/
/* returns dhandle for searchings */
int dir_handle = (int)*requestdata;
int len = (int)*(requestdata+1); /* pathlen */
@@ -6061,6 +6105,33 @@ static int handle_ncp_serv(void)
} break;
case 0x3f : { /* file search continue */
/*
* NCP 0x2222/63 File Search Continue scans the old
* directory file after 0x2222/62 has returned a
* DirectoryID and SearchSequence.
*
* SDK request:
*
* byte VolumeNumber
* word DirectoryID, Hi-Lo
* word SearchSequence, Hi-Lo
* byte SearchAttributes
* byte SearchPathLen
* bytes SearchPath
*
* SDK reply is the old internal file-header copy:
*
* word SearchSequence, Hi-Lo
* word DirectoryID, Hi-Lo
* union NW_FILE_INFO/NW_DIR_INFO
*
* Compared against the SDK/PDF and current parser:
* MARS-NWE reads all fixed request fields in the
* documented order and returns the documented sequence
* plus directory id prefix. The file/directory body is
* provided by nw_dir_search() using the project's
* NW_FILE_INFO/NW_DIR_INFO compatibility structures.
*/
/* Dir_id is from file search init */
struct INPUT {
uint8 header[7]; /* Requestheader */
@@ -6105,6 +6176,31 @@ static int handle_ncp_serv(void)
case 0x40 : /* Search for a File */
{
/*
* NCP 0x2222/64 Search for a File is the older
* one-call search variant.
*
* SDK request:
*
* word Sequence, Hi-Lo in this old direct call
* byte DirectoryHandle
* byte SearchAttributes
* byte FileNameLen
* bytes FileName
*
* SDK reply:
*
* word Sequence, Hi-Lo
* word Reserved
* union NW_FILE_INFO/NW_DIR_INFO
*
* Compared against the SDK/PDF and current parser:
* current code preserves this old two-byte sequence
* layout and returns the old 2+2+info reply body. This
* differs from the newer 0x2222/22/30 and 0x2222/87/03
* namespace search families, which use deeper selector
* paths and different 32-bit sequence layouts.
*/
struct INPUT {
uint8 header[7]; /* Requestheader */
uint8 sequence[2]; /* z.B. 0xff, 0xff */