docs: audit physical record sync endpoints
This commit is contained in:
OpenAI
Mario Fetka
25
TODO.md
25
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
|
||||
|
||||
|
||||
56
src/nwconn.c
56
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 */
|
||||
|
||||
Reference in New Issue
Block a user