From a5a5d5b9e4960849505133dcb0996874e14bf286 Mon Sep 17 00:00:00 2001 From: OpenAI Date: Tue, 2 Jun 2026 13:32:23 +0000 Subject: [PATCH] docs: audit physical record sync endpoints --- TODO.md | 25 ++++++++++++++++++++--- src/nwconn.c | 56 ++++++++++++++++++++++++++++++++++++---------------- 2 files changed, 61 insertions(+), 20 deletions(-) diff --git a/TODO.md b/TODO.md index b70c178..9b581d6 100644 --- a/TODO.md +++ b/TODO.md @@ -176,9 +176,6 @@ Present in the code but not yet fully endpoint-audited: property, set, password, queue, and management/admin subfunctions still need the same PDF/WebSDK/include comparison in `src/nwbind.c` and the related queue prehandlers. -- SDK `0x2222/26` through `0x2222/31` / wire `0x1a` through `0x1f` physical - record synchronization calls are implemented in `src/nwconn.c` but have not - yet received the detailed request-layout audit. - SDK `0x2222/34` / wire `0x22` TTS calls are present in `src/nwconn.c`; their remaining state-changing layouts still need source comparisons beyond the current availability/no-op note. @@ -259,6 +256,22 @@ Current status: Set` are implemented, but the SDK request contains a `LockFlag` byte that the current code does not read. This parser difference is documented inline but not changed yet. +- `NCP 0x1a Log Physical Record (old)`, `0x1c Release Physical Record`, and + `0x1e Clear Physical Record` are implemented and now have inline request + layout documentation. The parser matches the documented 6-byte handle + position by ignoring the high/reserved two bytes and using the low 4-byte + handle; offsets, lengths, and the Log Physical Record timeout are read as + Hi-Lo. +- `NCP 0x1b Lock Physical Record Set (old)` and the newer `0x6e Lock Physical + Record Set` share one handler. The SDK/PDF documents old `0x1b` + LockTimeout as Lo-Hi and newer `0x6e` as Hi-Lo, while MARS-NWE currently + reads the shared field with `GET_BE16()`. The current LockFlag mapping also + treats bit 1 as shareable/read-only and the unset case as + exclusive/read-write, which is the inverse of the NDK/Core-Protocols text. +- `NCP 0x1d Release Physical Record Set` and `0x1f Clear Physical Record Set` + are implemented, but both SDK requests contain a `LockFlags` byte that the + current code does not read. The reply has no payload and completion reports + the set-operation result. Follow-up: @@ -278,6 +291,12 @@ Follow-up: evidence is available. - Continue direct requester or NWTESTS coverage for the file, logical-record, and physical-record synchronization calls that are now wired. +- Decide whether the shared `0x1b`/`0x6e` physical-record-set parser should + special-case old `0x1b` LockTimeout as documented Lo-Hi, and whether the + LockFlag bit-1 mapping should follow the PDF text or preserve current + compatibility behavior. +- Decide whether `0x1d` and `0x1f` should consume or continue ignoring the + documented `LockFlags` byte after direct requester evidence is available. #### Legacy utility and message/broadcast calls diff --git a/src/nwconn.c b/src/nwconn.c index a82627b..143b0f1 100644 --- a/src/nwconn.c +++ b/src/nwconn.c @@ -5611,23 +5611,33 @@ static int handle_ncp_serv(void) case 0x1e : /* Clear Physical Record */ { /* - * SDK: NCP 0x2222/26 Log Physical Record records one - * byte range in the caller's logged data block table. - * Lock Flag 0 logs for future locking, 1 locks - * exclusive, and 3 locks shareable/read-only. + * SDK: NCP 0x2222/26 Log Physical Record (old) records + * one byte range in the caller's logged data block table. + * The request is LockFlag, a 6-byte NetWare file handle, + * LockAreaStartOffset (Hi-Lo), LockAreaLen (Hi-Lo), and + * LockTimeout (Hi-Lo). LockFlag 0 logs for future use, + * 1 locks exclusive/read-write, and 3 locks + * shareable/read-only. * * SDK: NCP 0x2222/28 Release Physical Record releases * one locked byte range but leaves it in the logged * table so a later Lock Physical Record Set can relock * it. The request carries a reserved byte, a 6-byte - * NetWare file handle, Start Offset, and Record Length; - * it returns no reply data and reports Unlock Error - * through the completion code. + * NetWare file handle, Start Offset (Hi-Lo), and Record + * Length (Hi-Lo); it returns no reply data and reports + * Unlock Error through the completion code. * - * SDK: NCP 0x2222/30 Clear Physical Record releases the - * range if it is locked and removes it from the logged + * SDK: NCP 0x2222/30 Clear Physical Record has the same + * request layout as Release Physical Record. It releases + * the range if it is locked and removes it from the logged * table. * + * Parser comparison: current code matches the documented + * 6-byte handle position by ignoring the two high/reserved + * bytes and using the low 4-byte handle. It reads offsets, + * lengths, and Log Physical Record timeout as Hi-Lo, and + * all three calls return only the normal NCP completion. + * * The physical-record set table is maintained alongside * the existing low-level byte-range lock implementation: * log/lock records are added on successful 0x1a calls, @@ -5692,11 +5702,19 @@ static int handle_ncp_serv(void) * and NCP 0x2222/110 Lock Physical Record Set lock all * byte ranges logged by the calling client. * - * SDK request: one-byte Lock Flag followed by a 2-byte - * Lock Timeout in 1/18 second units. Lock Flag bit 1 - * selects shareable/read-only locks; otherwise the set is - * locked exclusive/read-write. The reply carries no data - * and completion reports success, timeout, or lock error. + * SDK request: one-byte LockFlag followed by a 2-byte + * LockTimeout in 1/18 second units. The old 27 form is + * documented as Lo-Hi, while the newer 110 form is + * documented as Hi-Lo. The reply carries no data and + * completion reports success, timeout, or lock error. + * + * Parser comparison: both wire functions currently share + * this handler and read LockTimeout as Hi-Lo. The current + * LockFlag mapping also treats bit 1 as shareable/read-only + * and the unset case as exclusive/read-write, which is the + * inverse of the NDK/Core-Protocols text. This is kept as + * an audit item until direct requester traces prove whether + * old clients depend on the code behavior or the PDF text. * * MARS-NWE stores physical-record set entries from Log * Physical Record and routes the set lock through the @@ -5726,9 +5744,13 @@ static int handle_ncp_serv(void) * * SDK: NCP 0x2222/31 Clear Physical Record Set releases * all locked ranges and clears the caller's data byte - * range table. Both calls have no reply data; Clear - * carries a one-byte Lock Flags field documented as - * 0 = Not Locked. + * range table. Both requests contain a one-byte LockFlags + * field and have no reply data. + * + * Parser comparison: current code intentionally ignores + * LockFlags for both set operations and selects release or + * clear solely from the FunctionCode. Keep that as a + * compatibility audit item before changing behavior. */ int result = share_handle_lock_sets( 4, /* Physical Record Set */