mars_nwe/mars-nwe
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases 2 Wiki Activity
Files
df3f9b3e3bc2d3fb9efc7b83dd403fd9df4bfcc7
mars-nwe/TODO.md
Mario Fetka df3f9b3e3b docs: audit SecretStore endpoint scope
2026-06-02 18:30:37 +02:00

1361 lines
73 KiB
Markdown
Raw Blame History

# TODO
This file collects follow-up work that is known but intentionally not part of the current patches. It is meant for project-level items that are too broad or too low-priority to keep as inline source TODO comments.
## Server / NCP compatibility
### Console privilege model
Current status:
- `NCP 23/200 Check Console Privileges` is implemented as a protocol-compatible status check.
- For now, console privileges are mapped to the existing supervisor-equivalence state computed for the connection.
- Callers with supervisor equivalence get success; other callers get `0xc6` (`No Console Rights`).
Follow-up:
- Add a real console-operator privilege model instead of treating console rights as identical to supervisor equivalence.
- Decide where the console privilege map should live:
- a bindery property,
- a server configuration option,
- or a small explicit internal list similar to queue operator handling.
- Check how NetWare 3.x tools such as `PCONSOLE`, `SYSCON`, and console utilities expect console operators to be represented.
- Keep `NCP 23/200` as a completion-code-only endpoint; only the privilege source should change.
### Queue spool path case handling
Current status:
- Queue job paths can still be rebuilt from DOS/bindery path spelling such as `SYS:SYSTEM/EPSON.QDR`.
- On a case-sensitive Unix filesystem this can differ from the existing directory, for example `system/epson.qdr`.
Follow-up:
- Resolve queue job file paths case-insensitively in the queue connection/path resolver, or use the queue object's already-resolved Unix spool directory instead of rebuilding it from the DOS path.
- Avoid creating duplicate directories that differ only by case.
### NCP 17/4C test coverage
Current status:
- `NCP 17/4C List Relations of an Object` is implemented server-side.
- Existing DOS and Linux tools do not reliably trigger it for all useful set properties such as `GROUP_MEMBERS` and `GROUPS_I'M_IN`.
Follow-up:
- Add a small direct test utility to `mars-dosutils` / `NWTESTS` that sends `NCP 17/4C` directly.
- Suggested test cases:
- `TESTGRP1` type `0x0002`, property `GROUP_MEMBERS`
- `TESTGRP2` type `0x0002`, property `GROUP_MEMBERS`
- `MARIO` type `0x0001`, property `GROUPS_I'M_IN`
- `NOPASSUSER` type `0x0001`, property `GROUPS_I'M_IN`
- `GUEST` type `0x0001`, property `GROUPS_I'M_IN`
### NCP endpoint SDK documentation / stub audit
Current status:
- Several legacy NCP endpoints in `src/nwconn.c` are implemented only as
disabled stubs, explicit `0xfb` unsupported replies, or success/no-op dummies.
- The known candidates now have inline SDK-context comments so future work can
start from the documented wire semantics instead of from guesswork.
Follow-up:
- Implement or deliberately reject remaining endpoint gaps after client
evidence or direct protocol tests.
- Keep SDK details close to the corresponding endpoint in `nwconn.c`, and keep
broader prioritization/status here in `TODO.md`.
### NCP endpoint audit tracking
Current status:
- `src/nwconn.c` contains a mix of implemented, forwarded, partial, dummy,
and intentionally unsupported NCP endpoints.
- Endpoint comments should be aligned with the Novell SDK Web documentation,
SDK headers, the Rust `nwserver` implementation, `lwared`, and the existing
mars_nwe admin/Pascal code where those sources cover the same call.
Follow-up:
- Keep inline `TODO:` comments only where endpoint behavior is incomplete,
approximate, intentionally dummy/no-op, or still needs SDK layout
verification.
- Mirror every real incomplete endpoint in this file so follow-up work remains
visible outside the source code.
- Do not treat every `return(-1)` in `nwconn.c` as incomplete: many of those
paths intentionally forward bindery/global-server work to `nwbind`.
- When an endpoint returns to `nwbind`, keep the audit paired: the dispatcher
comment in `nwconn.c` should name the handoff, and the concrete parser in
`nwbind.c` should carry the request/reply layout. This was rechecked for
the currently documented forwarded paths: message group `0x2222/21`, quota
prehandling in Directory Services `0x2222/22`, File Server Environment
`0x2222/23`, End of Job `0x2222/24`, Logout `0x2222/25`, and Semaphore
`0x2222/32`.
### NCP endpoint layout audit (version-bucketed compatibility)
Current status:
- The default NCP endpoint audit is scoped to compatibility calls through
NetWare 3.x. NetWare 1.x/2.x legacy calls are part of that compatibility
target when they are documented, but they should be kept in their own buckets
instead of being mixed into the 3.x/default list.
- Bucket endpoints by the oldest generation that documents or requires them:
1.x/2.x legacy first, then remaining through-3.x compatibility calls, then a
separate NetWare 4.x planning/stub bucket for later work.
- Keep SDK request/reply details close to the corresponding endpoint in the
source file that handles the call. If `nwconn.c` forwards a group to
`nwbind.c`, document the handoff in `nwconn.c` and the concrete subfunctions
in `nwbind.c`.
- Documentation-only audit patches should not change parsing or reply behavior;
record observed differences here for later implementation or compatibility
testing. Compare against the local NDK/Core Protocols PDF, the WebSDK HTML,
and the uploaded SDK include prototypes when those sources cover the call.
- `MARS_NWE_4` is hard-disabled in `include/config.h.cmake`. Do not move or
wrap already implemented code just because it is 4.x-era; only new,
unimplemented 4.x stubs should be guarded with `#if MARS_NWE_4`.
#### Version buckets for endpoints documented so far
NetWare 1.x/2.x legacy bucket:
- Old direct file/logical/physical synchronization calls: `0x2222/01` through
`0x2222/0e` where documented by the legacy SDK/PDF.
- Old direct utility/message handoff calls around `0x2222/12` through
`0x2222/15`, including the 1.x/2.x-compatible broadcast subfunctions handled
in `src/nwbind.c`.
- Older directory-handle compatibility calls that the local PDF marks as early
NetWare compatibility, especially `0x2222/22/17` and `0x2222/22/18`.
NetWare 3.x/default compatibility bucket:
- Remaining documented `0x2222/22` Directory Services calls through the
NetWare-3.x-compatible namespace/directory range ending at `22/48`, unless a
specific call is proven to belong to the older bucket above.
- Salvage compatibility is part of this default bucket where the old `22/27`,
`22/28`, `22/29` bridges map to the newer salvage backend.
NetWare 4.x planning/stub bucket:
- `0x2222/22/50 Get Object Effective Rights for Directory Entry` and
`0x2222/22/51 Get Extended Volume Information` are documented by the local
NDK/Core Protocols PDF as NetWare 4.x/5.x calls and are also visible through
the uploaded WebSDK/include material (`NWGetObjectEffectiveRights`,
`NWGetExtendedVolumeInfo`).
- MARS-NWE already has active compatibility implementations for these two calls;
leave that code in place. Track them in the 4.x bucket for future cleanup,
tests, and field mapping rather than moving them into the default 3.x TODO
list or hiding them behind `MARS_NWE_4`.
- Any additional not-yet-implemented NetWare 4.x endpoint discovered later
should be documented as a plan and, if a source stub is useful, guarded with
`#if MARS_NWE_4` while the macro remains `0`. Do not add source stubs
merely for NetWare 5.x/OES/MOAB/newer endpoints during the current audit.
#### SDK-listed 0x2222 blocks not yet endpoint-audited
Current status:
- The local NDK/Core-Protocols PDF and uploaded WebSDK/includes list several
`0x2222` endpoint families that are not yet covered by the detailed
per-endpoint audit above. This section is an index only; do not treat an
entry here as implemented, missing, or in-scope until the block is compared
against the real dispatcher and bucketed by the oldest documented NetWare
generation.
- Use SDK/PDF decimal numbers plus wire hex when drilling into a block. For
example, SDK group `0x2222/23` is the top-level wire `case 0x17`; SDK group
`0x2222/89` would be top-level wire `case 0x59`.
Present in the code but not yet fully endpoint-audited:
- SDK `0x2222/23` / wire `0x17` File Server Environment: the audit has started
with file-information, login/connection, and bindery-object calls. Remaining
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/34` / wire `0x22` TTS calls are present in `src/nwconn.c` and
have been endpoint-audited as an unsupported/no-rollback compatibility group.
- SDK `0x2222/35` / wire `0x23` AFP calls are present in `src/nwconn.c` and
have been endpoint-audited as the AFP/Mac namespace compatibility block.
AFP has separate smoke coverage under `tests/afp/`; future fixes should be
driven by those tests and client traces rather than a new parallel metadata
store.
- SDK `0x2222/65` through `77` / wire `0x41` through `0x4d` are old
direct file open/create/read/write/rename/time/copy calls present in
`src/nwconn.c`; they have been endpoint-audited as the old direct file-I/O
compatibility block. Follow-up fixes, if any, should be driven by client
traces, especially around the old six-byte file-handle layout and the 65
Open File (old) access-rights compatibility note.
- SDK `0x2222/86` / wire `0x56` Extended Attribute is endpoint-audited as
a compatibility shim block in `src/nwconn.c` and `src/namspace.c`; see the
Extended Attribute section below for the exact per-subfunction status.
- SDK `0x2222/87` / wire `0x57` Name Space is endpoint-audited for the
current 1.x/2.x/3.x plus planned-4.x scope. Later-generation high selectors
`87/44` and `87/64`..`87/69` are documented as out of current source-stub
scope.
- SDK `0x2222/97` / wire `0x61` Get Big Packet NCP Max Packet Size and SDK
`0x2222/101` / wire `0x65` Packet Burst Connection Request are present in
`src/nwconn.c` and endpoint-audited as the 4.x-era packet-burst negotiation
and setup paths. The follow-on `0x7777` packet-burst data-plane handler is
also documented, but it is not a normal `0x2222` endpoint.
- SDK `0x2222/104` / wire `0x68` NDS/NCP fragger is endpoint-audited as
planned NetWare-4.x/NDS work. The top-level source case remains active as
unsupported (`0xfb`), while the documented 104/01..104/08 selector slots are
recorded behind `#if MARS_NWE_4` in `src/nwconn.c`.
- SDK `0x2222/111` / wire `0x6f` Semaphore is source-stub-audited as
the newer NetWare 3.x/4.x paired semaphore family. The old `32/xx`
semaphore calls remain the active compatibility implementation; patch 0223
records `111/00`..`111/04` as disabled `#if 0` selector slots in
`src/nwconn.c` so the future semaphore provider can bridge both families.
- SDK `0x2222/90` / wire `0x5a` Data Migration / tree metadata is
source-stub-audited as planned 4.x filesystem/namespace work. Patch 0224
records the 4.x-era `90/00`, `90/10`, `90/11`, `90/12`, `90/128`..`90/136`,
and `90/150` selector slots behind `MARS_NWE_4` in `src/nwconn.c`. There is
no active data-migration support module, compression metadata backend, or
parse-tree provider yet; future ownership belongs to the filesystem/namespace
provider, not `nwnds`.
- SDK `0x2222/17` / wire `0x11` direct Print/Spool is source-stub-audited
as a NetWare 2.x/3.x/4.x compatibility family. There is no active
top-level handler for these legacy direct spool NCPs, so patch 0218 records
the documented selector slots `17/00`, `17/01`, `17/02`, `17/03`, `17/06`,
`17/09`, and `17/10` as a disabled `#if 0` stub in `src/nwconn.c`. This
is not a statement that all printing is absent: queue-based printing already
exists through print queues, `Q_UNIX_PRINT`, and queue-job close/service
paths. Any future direct-spool implementation should reuse that queue
printing machinery where possible, and it does not belong to `nwnds`.
- SDK `0x2222/36` and `0x2222/37` / wire `0x24` and `0x25` NCP Extension
are source-stub-audited as a NetWare 4.x extension-registration family.
Patch 0221 records the documented `36/00`..`36/06` information selectors and
direct `37` execute-extension call behind `MARS_NWE_4` in `src/nwconn.c`.
There is no active extension registry/provider yet, and `nwserv` must remain
a control-plane registry/supervisor rather than a data-plane broker for
extension payloads.
- SDK `0x2222/79`, `0x2222/84`, and `0x2222/85` / wire `0x4f`, `0x54`, and
`0x55` are source-stub-audited as old direct file-metadata/open-create and
sparse-data compatibility calls. Patch 0222 records disabled `#if 0` slots
in `src/nwconn.c`; future implementation belongs to the filesystem/namespace
provider and should not be confused with NDS directory-object attributes.
SDK-listed blocks that do not currently show a top-level handler in
`src/nwconn.c`:
- SDK `0x2222/92` / wire `0x5c` SecretStore is scope-audited as a
later-generation SecretStore/eDirectory single-sign-on family. The local NDK
PDF marks the family as NetWare Server 5.x and eDirectory 8.5 or later, with
subverbs `0` Query Server through `9` Get Service Information. There is no
active top-level handler in `src/nwconn.c`, no indirect provider path was
found in the audited source, and no source stub should be added under the
current 1.x/2.x/3.x plus planned-4.x rule. It remains prose-only/out of the
current compatibility target.
- SDK `0x2222/123` / wire `0x7b` service-address enumeration and SDK
`0x2222/131` / wire `0x83` RPC/NLM-control style calls appear in the
PDF/WebSDK index but do not currently show top-level handlers in
`src/nwconn.c`. These are likely later-generation buckets, but each must be
confirmed against the includes/WebSDK before adding guarded stubs. Only
endpoints bucketed as 1.x/2.x/3.x compatibility or planned 4.x work should
receive disabled source stubs.
Follow-up:
- When auditing one of these blocks, first check whether an existing handler is
reached through `nwconn.c`, `nwbind.c`, or a queue/salvage/helper prehandler.
Only add a missing-endpoint TODO or guarded stub after that handoff search.
- Do not add every later SDK-listed endpoint to the active TODO list. Put
NetWare 4.x items in the NetWare 4.x planning bucket, and only add a disabled
`#if MARS_NWE_4` stub when that 4.x planning marker is useful and no existing
implementation is present. NetWare 5.x/OES/MOAB/newer items should remain
prose-only/out-of-scope unless the target scope changes.
#### Old direct file/logical/physical synchronization calls
Current status:
- The old direct synchronization family in `src/nwconn.c` is annotated with
Novell SDK endpoint names and request-layout notes.
- `NCP 0x01 File Set Lock (old)` and `NCP 0x02 File Release Lock` are
documented in the SDK but are not implemented in MARS-NWE yet. Inline
documentation and commented case/break stubs are present in `src/nwconn.c`.
- `NCP 0x03 Log File (old)` is implemented, but still belongs on the audit
list because the original source already marked this old log/lock area as
not well tested.
- `NCP 0x04 Lock File Set (old)` and `NCP 0x6a Lock File Set` share the
current implementation. The SDK documents the old `0x04` timeout word as
Lo-Hi and the newer `0x6a` timeout word as Hi-Lo; MARS-NWE currently reads
the shared field with `GET_BE16()`. This is documented inline but not
changed yet.
- `NCP 0x05 Release File (old)` and `NCP 0x07 Clear File (old)` have request
parsing that matches the documented old header offsets.
- `NCP 0x06 Release File Set` and `NCP 0x08 Clear File 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 0x09 Log Logical Record (old)`, `NCP 0x0a Lock Logical Record Set
(old)`, `NCP 0x0b Clear Logical Record`, and `NCP 0x0c Release Logical
Record` have inline SDK request-layout documentation. The direct old
endpoints have been compared against the NDK/Core Protocols PDF request
offsets.
- `NCP 0x0d Release Logical Record Set` and `NCP 0x0e Clear Logical Record
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:
- Decide whether `NCP 0x01` and `NCP 0x02` should be implemented for real
old-client compatibility or should return a deliberate `0xfb` unsupported
completion with normalized endpoint logging.
- Verify `NCP 0x03 Log File (old)` against a real DOS requester or direct test
caller; the documented PDF/WebSDK request offsets already match the current
parser.
- Decide whether the shared `0x04`/`0x6a` parser should keep the current
big-endian timeout read for both functions or special-case old `0x04` as
documented Lo-Hi after direct requester evidence is available.
- Decide whether `0x06`, `0x08`, `0x0d`, and `0x0e` should consume or ignore
the documented `LockFlag` byte after direct requester evidence is available.
- Decide whether `0x0a` should keep the current big-endian timeout read or
special-case the documented old Lo-Hi byte order after direct requester
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
Current status:
- `NCP 0x12 Get Volume Info with Number`, `NCP 0x13 Get Station Number`,
`NCP 0x14 Get File Server Date And Time`, and the `NCP 0x15` message group
handoff have inline SDK request/reply layout documentation.
- The forwarded NetWare 1.x/2.x/3.x-compatible `NCP 0x15` message
subfunctions in `src/nwbind.c` have inline SDK request/reply layout
documentation for broadcast send/get, enable/disable, and console broadcast
calls. The missing-endpoint pass for this group found implemented SDK
`21/00`, `21/01`, `21/02`, `21/03`, `21/09`, `21/10`, and `21/11`; no
default-compatibility server NCPs were found for `21/04`..`21/08`.
- SDK `21/12` Connection Message Control is documented as NetWare 5.x, so it
remains outside the default through-3.x endpoint target. Do not add it
unless the later-generation feature work is explicitly enabled.
- `NCP 0x13 Get Station Number` is documented by the SDK as a three-byte
StationNumber reply; MARS-NWE currently returns only the low one-byte
connection number. This parser/reply difference is documented inline but not
changed yet.
Follow-up:
- Verify whether the current one-byte `0x13` reply is required by old clients
or whether the SDK three-byte StationNumber reply should be implemented.
- Verify `NCP 0x2222/21/10 Send Broadcast Message` with a real client before
changing the parser: the NDK/Core Protocols PDF page documents long
connection numbers and long completion flags, while the CLIB/WebSDK
`NWSendBroadcastMessage` prototype exposes a 16-bit connection list and
byte result list, matching the current compatibility parser.
#### Directory Services group 0x2222/22
Current status:
- `NCP 0x2222/22` is handled in `src/nwconn.c`, with selected quota-related
subfunctions forwarded to `src/nwbind.c` for bindery/ObjectID prehandling.
- The group header is documented inline as `SubFuncStrucLen` (Hi-Lo),
`SubFunctionCode`, and subfunction payload.
- Endpoint numbers in SDK/PDF/WebSDK prose are decimal unless the source
explicitly prefixes them with `0x`. The wire `case` byte is listed below
whenever decimal and hex notation can be confused.
- Already audited and inline-documented default-compatibility calls:
- SDK `22/00` / wire `0x00` Set Directory Handle
- SDK `22/01` / wire `0x01` Get Directory Path
- SDK `22/02` / wire `0x02` Scan Directory Information
- SDK `22/03` / wire `0x03` Get Effective Directory Rights
- SDK `22/04` / wire `0x04` Modify Maximum Rights Mask
- SDK `22/05` / wire `0x05` Get Volume Number
- SDK `22/06` / wire `0x06` Get Volume Name
- SDK `22/10` / wire `0x0a` Create Directory
- SDK `22/11` / wire `0x0b` Delete Directory
- SDK `22/13` / wire `0x0d` Add Trustee to Directory
- SDK `22/14` / wire `0x0e` Delete Trustee from Directory
- SDK `22/15` / wire `0x0f` Rename Directory
- SDK `22/18` / wire `0x12` Allocate Permanent Directory Handle
- SDK `22/19` / wire `0x13` Allocate Temporary Directory Handle
- SDK `22/20` / wire `0x14` Deallocate Directory Handle
- SDK `22/21` / wire `0x15` Get Volume Info with Handle
- SDK `22/22` / wire `0x16` Allocate Special Temporary Directory Handle
- SDK `22/23` / wire `0x17` Extract a Base Handle
- SDK `22/24` / wire `0x18` Restore an Extracted Base Handle
- SDK `22/25` / wire `0x19` Set Directory Information
- SDK `22/26` / wire `0x1a` Get Path Name of a Volume-Directory Number Pair
- SDK `22/27` / wire `0x1b` Scan Salvageable Files (old)
- SDK `22/28` / wire `0x1c` Recover Salvageable File (old)
- SDK `22/29` / wire `0x1d` Purge Salvageable File (old)
- SDK `22/30` / wire `0x1e` Scan a Directory
- SDK `22/31` / wire `0x1f` Get Directory Entry
- SDK `22/32` / wire `0x20` Scan Volume's User Disk Restrictions
- SDK `22/33` / wire `0x21` Add User Disk Space Restriction
- SDK `22/34` / wire `0x22` Remove User Disk Space Restrictions
- SDK `22/37` / wire `0x25` Set Directory Entry Information
- SDK `22/38` / wire `0x26` Scan File or Directory for Extended Trustees
- SDK `22/39` / wire `0x27` Add Extended Trustee to Directory or File
- SDK `22/40` / wire `0x28` Scan Directory Disk Space
- SDK `22/41` / wire `0x29` Get Object Disk Usage and Restrictions
- SDK `22/42` / wire `0x2a` Get Effective Rights for Directory Entry
- SDK `22/43` / wire `0x2b` Remove Extended Trustee from Dir or File
- SDK `22/44` / wire `0x2c` Get Volume and Purge Information
- SDK `22/45` / wire `0x2d` Get Directory Information
- SDK `22/46` / wire `0x2e` Rename Or Move (old)
- SDK `22/47` / wire `0x2f` Get Name Space Information
- SDK `22/48` / wire `0x30` Get Name Space Directory Entry
- Already audited NetWare 4.x planning-bucket calls with existing active
MARS-NWE implementations:
- SDK `22/50` / wire `0x32` Get Object Effective Rights for Directory Entry
- SDK `22/51` / wire `0x33` Get Extended Volume Information
These are not part of the default 1.x/2.x/3.x implementation TODO list, but
existing compatibility code remains active.
- The old SDK PDF table for SDK `22/00` repeats `TargetDirectoryHandle` for
the second payload byte, but the remarks describe a source handle; MARS-NWE
parses the byte as `SourceDirectoryHandle`. This is documented inline but
not changed.
- No NetWare 1.x/2.x/3.x SDK/PDF entries were found for direct SDK `22/07`,
`22/08`, or `22/09` during this audit. The next documented direct directory
calls continue at SDK `22/10` / wire `0x0a`.
- WebSDK/PDF recheck found SDK `22/12` / wire `0x0c` Scan Directory for
Trustees. Do not confuse this with the already implemented wire `case 0x12`
/ SDK `22/18` Allocate Permanent Directory Handle. Scan Directory for
Trustees has only a disabled inline stub for now.
- WebSDK/PDF also documents SDK `22/35` / wire `0x23` Get Directory Disk Space
Restriction and SDK `22/36` / wire `0x24` Set Directory Disk Space
Restriction as NetWare 3.x-compatible directory quota calls. They are not
active cases in this dispatcher yet; disabled inline stubs now sit at their
numeric wire slots between SDK `22/34` / wire `0x22` and SDK `22/37` / wire
`0x25`.
- SDK `22/13` / wire `0x0d` and SDK `22/14` / wire `0x0e` match the SDK/PDF
payload layouts. SDK `22/15` / wire `0x0f` matches the payload layout; the
old PDF labels this call's `SubFuncStrucLen` as Lo-Hi, but MARS-NWE
dispatches the group before using that length word and the surrounding NCP 22
group header is otherwise documented as Hi-Lo.
- SDK `22/10` / wire `0x0a` and SDK `22/11` / wire `0x0b` preserve the
documented offset of `DirectoryAccessMask`, but the current implementation
does not use that field when creating or deleting the directory.
- SDK `22/18`, `22/19`, `22/22`, `22/20`, and `22/21` request parsers match
the documented NetWare 1.x/2.x/3.x payload offsets.
- SDK `22/23` / wire `0x17` and SDK `22/24` / wire `0x18` now have inline
request/reply layout documentation. The current parsers match the actual
payload fields, but the local NDK/Core Protocols PDF tables for this older
NetWare 2.x save/restore pair contain header/length wording that does not
line up cleanly with the common `0x2222/22` group header. This is documented
inline and no behavior was changed.
- SDK `22/25`, `22/26`, `22/27`, and `22/29` match the documented request
payload offsets. SDK `22/26` uses the old 16-bit directory-entry-number
form; the WebSDK table does not spell out byte order for that word, while
MARS-NWE reads it as Hi-Lo.
- SDK `22/28` validates the documented old/new filename fields, but the current
backend call recovers by directory handle and sequence only and does not pass
the old/new names to the salvage backend.
- SDK `22/30` / wire `0x1e` matches the documented offsets, but the SDK
documents `Sequence` as Lo-Hi while the current parser reads it with
`GET_BE32()`.
- SDK `22/31` / wire `0x1f` consumes the documented `DirectoryHandle`; legacy
source comments expected two extra unknown bytes after it, but the SDK
request has no such fields and the helper ignores them.
- SDK `22/32` / wire `0x20` reads `VolumeNumber` in the normal NCP 22 payload
position, but the WebSDK/PDF table for this call shows `VolumeNumber` one
byte later than the common group-header alignment. The code also reads
`Sequence` with `GET_BE32()` although the SDK/PDF documents Lo-Hi; treat
both as audit items until verified with a direct test caller.
- SDK `22/33` and `22/34` are forwarded to `nwbind.c` for quota prehandling;
both layers are documented. The shared `nwbind` prehandler reads ObjectID
from the documented payload position. SDK `22/33` includes a documented
DiskSpaceLimit field, but the current shared prehandler does not consume it
before returning the uid/gid/permission tuple.
- SDK `22/38`, `22/39`, and `22/41` match the documented request payload
offsets.
- SDK `22/37` matches the documented payload field order, but the current
parser reads Sequence with `GET_BE32()` although the SDK/PDF documents Lo-Hi.
- SDK `22/40` matches the documented payload offsets, but the current parser
reads 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.
- SDK `22/42`, `22/43`, `22/45`, `22/46`, and `22/47` match the NetWare
1.x/2.x/3.x SDK/PDF payload offsets used by the current parser.
- SDK `22/44` / wire `0x2c` 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.
- SDK `22/48` / wire `0x30` matches the documented payload offsets; the PDF
does not label the `DOSSequence` byte order, and current code reads it with
`GET_32()`.
Follow-up:
- Implement or intentionally reject SDK `22/12` / wire `0x0c` Scan Directory
for Trustees. Do not confuse the SDK decimal subfunction number 12 with the
already implemented wire `case 0x12` / SDK `22/18` directory-handle call.
- Implement or intentionally reject SDK `22/35` / wire `0x23` Get Directory
Disk Space Restriction and SDK `22/36` / wire `0x24` Set Directory Disk
Space Restriction. Both are NetWare 3.x-compatible, not `MARS_NWE_4` work.
- Verify the documented SDK `22/00` source-handle interpretation against an
old requester or direct test caller before changing behavior.
- Decide whether SDK `22/10` / wire `0x0a` and SDK `22/11` / wire `0x0b`
should apply or validate the documented `DirectoryAccessMask` byte, or
whether ignoring it is required for old requester compatibility.
- Verify SDK `22/23` / wire `0x17` and SDK `22/24` / wire `0x18` against an
old requester or direct test caller before changing the conservative
connection-local implementation; the SDK/PDF tables for those two NetWare
2.x calls are less internally consistent than the surrounding
directory-handle calls.
- Verify SDK `22/26` directory-entry-number byte order against an old requester
or direct test caller before changing the current Hi-Lo interpretation.
- Decide whether SDK `22/28` should pass the documented old/new filename fields
to the salvage backend, or whether sequence-only recovery is sufficient for
old requester compatibility.
- Verify SDK `22/30` Sequence byte order; current code uses `GET_BE32()`
although the SDK/WebSDK documents Lo-Hi.
- Verify whether SDK `22/31` should continue accepting legacy callers that send
the two extra bytes described by the old source comment, even though the SDK
request only contains `DirectoryHandle`.
- Verify SDK `22/32` VolumeNumber offset and Sequence byte order against a
direct test caller; the WebSDK table appears shifted by one byte compared
with the normal NCP 22 group header, and current code uses `GET_BE32()`
although the SDK/PDF documents Lo-Hi.
- Decide whether SDK `22/33` should pass the documented DiskSpaceLimit through
the quota prehandling path or whether the current behavior is intentionally
handled later in the quota backend.
- Verify SDK `22/37` Sequence byte order; current code uses `GET_BE32()`
although the SDK/PDF documents Lo-Hi.
- Verify SDK `22/40` 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.
- Verify SDK `22/44` 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 SDK `22/48` 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
covered through the documented SDK `22/48` namespace call, with the newly
found SDK `22/12`, `22/35`, and `22/36` gaps tracked as disabled stubs/TODO
items. Continue with the next compatibility group after this block; 5.x/OES-only groups are not current stub targets.
#### Semaphore group 0x2222/32
Current status:
- Direct `NCP 0x2222/32` / wire `0x20` is forwarded unchanged from
`src/nwconn.c` to `src/nwbind.c`, which passes `requestdata[0]` as the
semaphore subfunction and `requestdata[1..]` to `handle_func_0x20()` in
`src/sema.c`.
- The NetWare 2.x/3.x-compatible old semaphore subfunctions are now documented
at their real parser/reply site in `src/sema.c`:
- SDK `32/00` / wire subfunction `0x00` Open Semaphore (old)
- SDK `32/01` / wire subfunction `0x01` Examine Semaphore (old)
- SDK `32/02` / wire subfunction `0x02` Wait On Semaphore (old)
- SDK `32/03` / wire subfunction `0x03` Signal Semaphore (old)
- SDK `32/04` / wire subfunction `0x04` Close Semaphore (old)
- Request and response payloads were compared against the NDK/Core Protocols
PDF, the extracted WebSDK semaphore pages, and `nwsync.h`. The old `32/00`
through `32/04` operations line up with the currently implemented operation
set.
Known differences / follow-up:
- The PDF/WebSDK tables label `SemaphoreHandle` as long Lo-Hi. The current
`src/sema.c` implementation parses and emits semaphore handles with
`GET_BE32()` / `U32_TO_BE32()` while parsing `SemaphoreTimeOut` as Hi-Lo with
`GET_BE16()`. Keep this documented as a compatibility detail until packet
traces or client tests prove the expected wire order for MARS-NWE clients.
- `Wait On Semaphore` currently does not sleep until `SemaphoreTimeOut`; the
simple emulator returns timeout immediately when the semaphore value is not
available.
- Newer SDK `0x2222/111` semaphore calls are the modern paired variants.
They are now source-stub-audited separately at the direct wire `0x6f`
dispatch slot; any future implementation should bridge to a shared
semaphore provider rather than duplicating the old `32/xx` implementation.
#### Direct semaphore group 0x2222/111
Current status:
- Direct `NCP 0x2222/111` / wire `0x6f` is source-stub-audited in
`src/nwconn.c`. There is no active top-level handler for this newer
NetWare 3.x/4.x paired semaphore family.
- The documented selector slots are recorded in a disabled `#if 0` block:
- `111/00` Open/Create a Semaphore
- `111/01` Examine Semaphore
- `111/02` Wait On (P) Semaphore
- `111/03` Signal (V) Semaphore
- `111/04` Close Semaphore
- The old `32/xx` semaphore group remains the active compatibility path.
Future implementation should decode the `111/xx` wrapper and share the
same semaphore provider/state rather than building a second semaphore table.
Known differences / follow-up:
- The NDK documents `SemaphoreHandle` as long Lo-Hi for both old `32/xx` and
newer `111/xx` families. The active old handler currently uses big-endian
helpers for handles; verify client traces before bridging the new family.
- This remains local semaphore/synchronization state. It does not belong to
`nwnds`, `nwdirectory`, or the future directory store.
#### Direct connection lifecycle and buffer-size calls
Current status:
- Direct `NCP 0x2222/24` / wire function `0x18` End Of Job is implemented as a
paired `nwconn.c`/`nwbind.c` handoff. The PDF/WebSDK request has no payload
after FunctionCode 24 and the reply has no payload. `nwconn.c` releases
task-local handles and jobs first; `nwbind.c` closes matching print jobs and
sends the final empty success reply.
- Direct `NCP 0x2222/25` / wire function `0x19` Logout is implemented as a
paired `nwconn.c`/`nwbind.c` handoff. The PDF/WebSDK request has no payload
after FunctionCode 25 and the reply has no payload. `nwconn.c` releases local
queue/file/user state; `nwbind.c` closes remaining print jobs, writes logout
accounting state, clears bindery identity fields, and sends the final empty
success reply.
- Direct `NCP 0x2222/33` / wire function `0x21` Negotiate Buffer Size is handled
entirely in `src/nwconn.c`. The request is `ProposedBufferSize` as a Hi-Lo
word and the reply is `AcceptedBufferSize` as a Hi-Lo word. The current
parser/reply match the documented order. MARS-NWE clamps valid proposals to
`LOC_RW_BUFFERSIZE`; proposals below 512 leave the existing/default negotiated
size in force and return that value.
Missing-endpoint check:
- These three are direct functions, not nested subfunction groups. No additional
subfunctions are listed under SDK `24`, SDK `25`, or SDK `33` in the local
NDK/Core-Protocols PDF/WebSDK material.
#### Retrospective endpoint coverage rule for audited blocks
Current status:
- From this point on, each endpoint-family patch should first list the
SDK/PDF/WebSDK endpoints in that family, then compare that list against the
real dispatcher cases and any forwarded target handlers before documenting
individual request/reply layouts.
- Apply the same rule retroactively when touching an already-audited family:
message `0x2222/21`, directory/quota `0x2222/22`, file-server environment
`0x2222/23`, direct lifecycle `0x2222/24` and `0x2222/25`, semaphore
`0x2222/32`, and buffer negotiation `0x2222/33` should each state whether
missing endpoints were checked, and whether the family has active code,
disabled future stubs, or no top-level handler.
- A disabled `#if 0` stub is only a documentation/slot marker. Do not assign
`return(-1)` forwarding semantics to such stubs in `nwbind.c`; that special
forwarding meaning belongs to `nwconn.c`'s `handle_ncp_serv()` path.
#### 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/forwarded subfunction cases audited so far are:
- SDK `23/00` / wire `0x00` Login User (old) -- disabled future stub
- SDK `23/01` / wire `0x01` Change User Password (old) -- hard failure stub
- SDK `23/02` / wire `0x02` Get User Connection List (old) -- disabled future stub
- SDK `23/05` / wire `0x05` Get Station's Logged Info (old) -- disabled future stub
- SDK `23/12` / wire `0x0c` Verify Serialization -- hard failure stub
- SDK `23/15` / wire `0x0f` Scan File Information
- SDK `23/16` / wire `0x10` Set File Information
- SDK `23/17` / wire `0x11` Get File Server Information
- SDK `23/18` / wire `0x12` Get Network Serial Number
- SDK `23/19` / wire `0x13` Get Internet Address (old)
- SDK `23/20` / wire `0x14` Login Object
- SDK `23/21` / wire `0x15` Get Object Connection List (old)
- SDK `23/22` / wire `0x16` Get Station's Logged Info (old)
- SDK `23/23` / wire `0x17` Get Login Key
- SDK `23/24` / wire `0x18` Keyed Object Login
- SDK `23/26` / wire `0x1a` Get Internet Address
- SDK `23/27` / wire `0x1b` Get Object Connection List
- SDK `23/28` / wire `0x1c` Get Station's Logged Info
- SDK `23/50` / wire `0x32` Create Bindery Object
- SDK `23/51` / wire `0x33` Delete Bindery Object
- SDK `23/52` / wire `0x34` Rename Object
- SDK `23/53` / wire `0x35` Get Bindery Object ID
- SDK `23/54` / wire `0x36` Get Bindery Object Name
- SDK `23/55` / wire `0x37` Scan Bindery Object
- SDK `23/56` / wire `0x38` Change Bindery Object Security
- SDK `23/57` / wire `0x39` Create Property
- SDK `23/58` / wire `0x3a` Delete Property
- SDK `23/59` / wire `0x3b` Change Property Security
- SDK `23/60` / wire `0x3c` Scan Property
- SDK `23/61` / wire `0x3d` Read Property Value
- SDK `23/62` / wire `0x3e` Write Property Value
- SDK `23/63` / wire `0x3f` Verify Bindery Object Password -- disabled future stub
- SDK `23/64` / wire `0x40` Change Bindery Object Password
- SDK `23/65` / wire `0x41` Add Bindery Object To Set
- SDK `23/66` / wire `0x42` Delete Bindery Object From Set
- SDK `23/67` / wire `0x43` Is Bindery Object In Set
- SDK `23/68` / wire `0x44` Close Bindery
- SDK `23/69` / wire `0x45` Open Bindery
- SDK `23/70` / wire `0x46` Get Bindery Access Level
- SDK `23/71` / wire `0x47` Scan Bindery Object Trustee Paths
- SDK `23/72` / wire `0x48` Get Bindery Object Access Level
- SDK `23/73` / wire `0x49` Is Calling Station A Manager
- SDK `23/74` / wire `0x4a` Keyed Verify Password
- SDK `23/75` / wire `0x4b` Keyed Change Password
- SDK `23/76` / wire `0x4c` List Relations Of An Object
- SDK `23/100` / wire `0x64` Create Queue
- SDK `23/101` / wire `0x65` Destroy Queue
- SDK `23/102` / wire `0x66` Read Queue Current Status (old)
- SDK `23/103` / wire `0x67` Set Queue Current Status (old)
- SDK `23/104` / wire `0x68` Create Queue Job And File (old)
- SDK `23/105` / wire `0x69` Close File And Start Queue Job (old)
- SDK `23/106` / wire `0x6a` Remove Job From Queue (old)
- SDK `23/107` / wire `0x6b` Get Queue Job List (old)
- SDK `23/108` / wire `0x6c` Read Queue Job Entry (old)
- SDK `23/109` / wire `0x6d` Change Queue Job Entry (old)
- SDK `23/110` / wire `0x6e` Change Queue Job Position -- disabled future stub
- SDK `23/111` / wire `0x6f` Attach Queue Server To Queue
- SDK `23/112` / wire `0x70` Detach Queue Server From Queue
- SDK `23/113` / wire `0x71` Service Queue Job (old)
- SDK `23/114` / wire `0x72` Finish Servicing Queue Job (old)
- SDK `23/115` / wire `0x73` Abort Servicing Queue Job (old)
- SDK `23/116` / wire `0x74` Change To Client Rights (old) -- disabled future stub
- SDK `23/117` / wire `0x75` Restore Queue Server Rights -- disabled future stub
- SDK `23/118` / wire `0x76` Read Queue Server Current Status (old) -- disabled future stub
- SDK `23/119` / wire `0x77` Set Queue Server Current Status -- disabled future stub
- SDK `23/120` / wire `0x78` Get Queue Job File Size (old)
- SDK `23/121` / wire `0x79` Create Queue Job And File
- SDK `23/122` / wire `0x7a` Read Queue Job Entry
- SDK `23/126` / wire `0x7e` Set Queue Current Status
- SDK `23/127` / wire `0x7f` Close File And Start Queue Job
- SDK `23/128` / wire `0x80` Remove Job From Queue
- SDK `23/129` / wire `0x81` Get Queue Job List
- SDK `23/130` / wire `0x82` Change Job Priority -- disabled future stub
- SDK `23/131` / wire `0x83` Finish Servicing Queue Job
- SDK `23/132` / wire `0x84` Abort Servicing Queue Job
- SDK `23/133` / wire `0x85` Change To Client Rights -- disabled future stub
- SDK `23/134` / wire `0x86` Read Queue Server Current Status -- disabled future stub
- SDK `23/135` / wire `0x87` Get Queue Job File Size
- SDK `23/200` / wire `0xc8` Check Console Privileges
- SDK `23/201` / wire `0xc9` Get File Server Description Strings
- SDK `23/202` / wire `0xca` Set File Server Date And Time -- disabled future stub
- SDK `23/203` / wire `0xcb` Disable File Server Login -- disabled future stub
- SDK `23/204` / wire `0xcc` Enable File Server Login -- disabled future stub
- SDK `23/205` / wire `0xcd` Get File Server Login Status
- SDK `23/207` / wire `0xcf` Disable Transaction Tracking -- disabled future stub
- SDK `23/208` / wire `0xd0` Enable Transaction Tracking -- disabled future stub
- SDK `23/209` / wire `0xd1` Send Console Broadcast (old)
- SDK `23/210` / wire `0xd2` Clear Connection Number (old)
- SDK `23/211` / wire `0xd3` Down File Server
- SDK `23/232` / wire `0xe8` Get File Server Misc Information -- disabled future stub
- SDK `23/235` / wire `0xeb` Get Connection's Open Files -- disabled future stub
- SDK `23/253` / wire `0xfd` Send Console Broadcast -- disabled future stub
- SDK `23/254` / wire `0xfe` Clear Connection Number -- disabled future stub
- 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. The server/connection calls cross-check against
`NWGetFileServerInformation()`, `NWGetNetworkSerialNumber()`,
`NWGetInternetAddress()`, `NWGetConnectionInformation()`,
`NWGetObjectConnectionNumbers()`, and related connection/server headers.
- Bindery object calls SDK `23/50` through SDK `23/56` were compared against
the NDK/Core-Protocols PDF, WebSDK API names, and `nwbindry.h` prototypes.
The current `nwbind.c` parsers match the documented request payload order and
Hi-Lo object type/object ID fields. Replies for SDK `23/53`, `23/54`, and
`23/55` match the documented fixed bindery object reply blocks.
- Bindery property calls SDK `23/57` through SDK `23/62` were compared against
the NDK/Core-Protocols PDF, WebSDK API names, and `nwbindry.h` prototypes.
The current `nwbind.c` parsers match the documented request payload order,
including Hi-Lo ObjectType and Hi-Lo LastInstance/SearchInstance for
SDK `23/60`. Replies for SDK `23/60` and SDK `23/61` match the documented
fixed property reply blocks. SDK `23/62` names the byte after SegmentNumber
`MoreFlag`; the current local variable is named `erase_segment`, but it
consumes that same byte.
- Bindery password/set/access calls SDK `23/63` through SDK `23/76` were
compared against the NDK/Core-Protocols PDF, WebSDK API names, and
`nwbindry.h` prototypes where available. SDK `23/65` through SDK `23/67`
share the documented object/property/member tuple and match the current
parsers. SDK `23/68` and SDK `23/69` have no payload and are implemented as
successful no-ops. SDK `23/70`, `23/72`, `23/73`, `23/74`, `23/75`, and
`23/76` match their documented request/reply layouts. SDK `23/71` is
handled locally in `src/nwconn.c` because it resolves directory trustee
paths; the disabled `nwbind.c` case comment now points back to that handler.
SDK `23/63` / wire `0x3f` is documented but not implemented, so a disabled
future stub was added next to the surrounding bindery password calls.
For SDK `23/64`, the local NDK/Core-Protocols PDF text appears to contain a
transposed set-member table; the WebSDK/include API shape matches the
existing ObjectName/OldPassword/NewPassword parser.
- Queue calls SDK `23/100` through SDK `23/108`, queue-server and service
calls SDK `23/109` through SDK `23/115`, the old job-size call SDK `23/120`,
and the paired newer variants SDK `23/121` through SDK `23/129`, SDK
`23/131`, SDK `23/132`, and SDK `23/135` were compared against the
`nwqms.h` prototypes and extracted WebSDK queue pages.
`src/nwconn.c` performs required prehandling for queue path rewriting,
queue-job file creation, queue job entry file-handle insertion, and close/start
file association before forwarding to `src/nwbind.c`. The target handlers in
`nwbind.c` now carry the concrete request/reply layout notes. The newer
queue job-control calls that document 32-bit job numbers are intentionally
noted where the current compatibility parser still consumes or emits old
16-bit job-number fields.
- Remaining queue rights/status/priority calls SDK `23/110`, SDK `23/116`
through SDK `23/119`, SDK `23/130`, SDK `23/133`, and SDK `23/134` were
compared against the NDK/Core-Protocols PDF and `nwqms.h`/`nwqueue.h`
prototypes. They are not implemented in the current queue backend. `nwbind.c`
now documents them as disabled future stubs rather than leaving the wire slots
implicit: job-position reorder, queue-server identity switch/restore, the
per-server 64-byte status record, and newer long-priority/client-rights forms.
- Console/server-management calls SDK `23/200` through SDK `23/211`, plus
SDK `23/232`, SDK `23/235`, SDK `23/253`, and SDK `23/254`, were compared
against the NDK/Core-Protocols PDF and server/connection/message include
prototypes (`nwserver.h`, `nwconnec.h`, `nwmsg.h`, and NLM `nwenvrn.h`).
Implemented calls now carry inline layout notes in `src/nwbind.c`: console
privilege check, description strings, login status, old console broadcast,
old clear connection, and down server. Missing or non-modelled management
calls are documented as disabled future stubs: set server date/time, enable
and disable logins, enable and disable TTS, misc server information, open-file
enumeration, new 32-bit console broadcast, and new 32-bit clear connection.
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.
- SDK `23/12` / wire `0x0c` Verify Serialization is currently a hard failure
stub; the PDF/WebSDK endpoint title is decimal `23/12`, while one table row
prints `SubFunctionCode (212)`, so do not add a wire `0xd4` case without a
packet trace or include-level confirmation.
- SDK `23/17` / wire `0x11` returns the legacy server-info block; later PDF
revisions name additional fields inside the current reserved tail. Keep the
current behaviour until a client requires those fields.
- SDK `23/18` / wire `0x12` documents the serial/application reply as Lo-Hi,
while the current code writes both fields with big-endian helpers.
- SDK `23/23` / wire `0x17` documents a TargetConnection byte, but the current
implementation ignores it and returns a login key for the active connection.
- SDK `23/27` / wire `0x1b` documents `SearchConnNumber` and returned
connection numbers as Lo-Hi long values; the current code reads the search
number with `GET_BE32()` and returns 16-bit connection numbers.
- Implement or deliberately hard-fail SDK `23/63` / wire `0x3f` Verify
Bindery Object Password; it is a NetWare 2.x/3.x compatibility call and is
currently only a disabled documented stub.
- Verify the shared queue handlers for newer queue calls that currently consume
old 16-bit fields: SDK `23/122` / wire `0x7a`, SDK `23/127` / wire `0x7f`,
SDK `23/128` / wire `0x80`, SDK `23/131` / wire `0x83`, SDK `23/132` / wire
`0x84`, and SDK `23/135` / wire `0x87` document long or Lo-Hi job-number
fields in the WebSDK/include material, while the current compatibility parser often reuses
the old 16-bit layout. SDK `23/126` / wire `0x7e` also documents a long
queue-status field but the shared parser consumes only one byte.
- Implement or deliberately hard-fail the disabled queue future stubs once the
queue backend can support their semantics: SDK `23/110` / wire `0x6e` Change
Queue Job Position, SDK `23/116` / wire `0x74` and SDK `23/133` / wire `0x85`
Change To Client Rights, SDK `23/117` / wire `0x75` Restore Queue Server
Rights, SDK `23/118` / wire `0x76` and SDK `23/134` / wire `0x86` Read Queue
Server Current Status, SDK `23/119` / wire `0x77` Set Queue Server Current
Status, and SDK `23/130` / wire `0x82` Change Job Priority.
- SDK `23/205` / wire `0xcd` Get File Server Login Status currently returns a
one-byte enabled flag. The PDF documents a long `UserLoginAllowed` reply,
while the CLIB/WebSDK prototype exposes a byte flag; verify expected wire
length with a real client before changing the compatibility reply.
- SDK `23/209` / wire `0xd1` Send Console Broadcast (old) is parsed as the old
byte station-list form. The PDF table labels `StationList` as long[], but
its own `SubFuncStrucLen = 3 + NumberOfStations + MessageLen` formula matches
the byte-list parser; keep the newer 32-bit list in SDK `23/253` / wire
`0xfd` separate.
- SDK `23/211` / wire `0xd3` Down File Server currently ignores the documented
ForceFlag and always calls the local server-down path after supervisor-rights
validation. Verify whether a non-forced request should fail when active files
are open before changing behavior.
- Implement or deliberately hard-fail the disabled management future stubs once
the corresponding server state exists: SDK `23/202`, SDK `23/203`, SDK
`23/204`, SDK `23/207`, SDK `23/208`, SDK `23/232`, SDK `23/235`, SDK
`23/253`, and SDK `23/254`.
- Audit the remaining forwarded `0x2222/23` 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:
- `NCP 0x16/0x33 Get Extended Volume Information` returns the documented
`NWVolExtendedInfo` reply and fills the core fields that can be derived from
generic Unix filesystem statistics.
- NetWare-specific fields that MARS-NWE does not currently model are returned
as zero for now instead of guessed values.
Follow-up:
- Fill additional `NWVolExtendedInfo` fields when reliable data is available
from the backing filesystem or from MARS-NWE metadata.
- Candidate fields include suballocation, deleted-file/limbo accounting,
compression counters, migration counters, EA counters, Directory Services
object id, and last-modified timestamp data.
- Treat compression-related fields as real follow-up work rather than permanent
zeroes; populate them only when the backing filesystem exposes trustworthy
compressed-file or compressed-block accounting.
### Object disk restriction fallback coverage
Current status:
- `NCP 0x16/0x29 Get Object Disk Usage And Restrictions` keeps the existing
`QUOTA_SUPPORT` split.
- With quota support enabled, the endpoint is routed through `nwbind` so the
bindery Object ID can be mapped to a Unix uid before querying the quota
backend.
- Without quota support, the endpoint returns the SDK-compatible fallback:
unrestricted (`0x40000000`) and no space in use.
Follow-up:
- Add direct tests for both build modes.
- Verify the quota-enabled path against a real Unix quota setup.
- Verify that the quota-disabled fallback remains compatible with requesters
and with the WebSDK rule for invalid object IDs.
### Server logging schema
Current status:
- Server logging is useful during protocol work, but output is still noisy and
not formatted consistently across NCP, namespace/path mapping, AFP, bindery,
file, queue, trustee, and salvage code.
- During salvage endpoint development, verbose logs are preferred over missing
diagnostic information, but the messages should become easier to grep and
compare across subsystems.
Follow-up:
- Normalize new server log lines toward this shape:
```text
<LVL4> <AREA> <DEC-CODE> <EVENT> key=value ...
```
- Use four-character levels so columns do not jump around:
- `INFO`
- `DBUG`
- `WARN`
- `ERRR`
- Put the level first, then the subsystem/function area, for example `NCP`,
`SALVAGE`, `AFP`, `MAP`, `BIND`, `TRUST`, `AUTH`, `CONN`, `FILE`, or `QUEUE`.
- Use decimal/protocol-facing endpoint identifiers near the front when they are
what the documentation uses, for example `87/16`, `87/17`, and `87/18`.
- Keep exact wire values as hex key/value fields later in the same line, for
example `fn=0x57 sub=0x10 ns=0x00 seq=0x00000000 vol=0x0000
base=0x00000004 result=0x89ff`.
- Mark missing or unimplemented endpoints with a stable `UNKNOWN` event, for
example:
```text
INFO NCP 87/18 UNKNOWN fn=0x57 sub=0x12 msg="not implemented"
INFO NCP 87/255 UNKNOWN fn=0x57 sub=0xff msg="unknown subfunction"
INFO NCP 136 UNKNOWN fn=0x88 msg="unknown function"
```
- Prefer existing mars_nwe logging functions/macros. Do not introduce a second
logging subsystem just to change the message format.
- Convert noisy areas gradually, starting with NCP function/subfunction dispatch
and the salvage endpoints.
## Printing / Queue backend
### Q_UNIX_PRINT backend status
Current status:
- Queue metadata handling and the `Q_UNIX_PRINT` backend are intentionally separate.
- The backend can already call `/usr/bin/lp`, `lpr`, or a custom script.
Follow-up:
- Improve logging around queue job submission to the Unix print command.
- Capture and expose backend exit status where possible.
- Consider direct CUPS integration only if MARS_NWE needs CUPS job IDs, cancellation, or status polling. Do not add a hard CUPS dependency for basic queue compatibility.
### Transaction Tracking System (TTS)
Current status:
- `NCP 0x2222/34` / wire `0x22` is endpoint-audited in `src/nwconn.c`.
- `34/00 TTS Is Available` reports the WebSDK/NDK-documented unavailable
status by returning completion `0x00` and no reply payload.
- The SDK-listed through-3.x TTS subfunctions are documented inline:
`34/01` Begin Transaction, `34/02` End Transaction, `34/03` Abort
Transaction, `34/04` Transaction Status, `34/05`/`34/06` application
thresholds, `34/07`/`34/08` workstation thresholds, and `34/09`/`34/10`
transaction bits.
- MARS-NWE does not currently implement TTS rollback semantics, transaction
files, transaction status tracking, threshold state, or begin/end/abort
transaction state. The non-availability subfunctions intentionally return
`0xfb` instead of pretending to succeed.
- No SDK-listed through-3.x TTS subfunctions beyond `34/10` were found in the
NDK/Core-Protocols TTS table during this audit.
Follow-up:
- Implement TTS only if a concrete client requires it.
- Treat this as a real transaction subsystem, not as a completion-code shim:
the SDK calls require transaction numbering/status, rollback/backout,
threshold state, control flags, and interaction with logical/physical locks.
- If TTS is ever implemented, add tests that prove `34/02` returns a real
TransactionNumber and that `34/04` reports status for that number.
### Old direct file commit/search calls
Current status:
- `NCP 0x2222/59` / wire `0x3b` Commit File and `0x2222/61` / wire
`0x3d` Commit File are endpoint-audited in `src/nwconn.c`. They share the
same old six-byte file-handle request layout and return no reply payload.
MARS-NWE commits the low four-byte handle via `GET_32()` and ignores the
reserved/extended high bytes, matching the existing host file-handle model.
- `NCP 0x2222/62` / wire `0x3e` File Search Initialize is endpoint-audited.
The request payload after `FunctionCode` is `DirectoryHandle`,
`DirectoryPathLen`, and `DirectoryPath`; the response returns volume,
directory id, search sequence, and directory rights.
- `NCP 0x2222/63` / wire `0x3f` File Search Continue is endpoint-audited.
The parser reads volume, directory id, search sequence, search attributes,
search path length, and search path in the documented old order. The reply
returns the new search sequence, directory id, and the project's
`NW_FILE_INFO`/`NW_DIR_INFO` compatibility body.
- `NCP 0x2222/64` / wire `0x40` Search for a File is endpoint-audited as the
old two-byte-sequence direct search variant. It is intentionally documented
separately from the newer `22/30` and `87/03` namespace search families.
Follow-up:
- Verify old direct search replies against a real requester or packet test,
especially the exact `NW_FILE_INFO`/`NW_DIR_INFO` packing and directory body.
- Decide later whether the ignored high/extended bytes in the old six-byte file
handle should remain compatibility padding or participate in a future handle
table expansion.
### Extended Attribute group 0x2222/86
Current status:
- `NCP 0x2222/86` / wire `0x56` is endpoint-audited as the old Extended
Attribute group. `src/nwconn.c` forwards requestdata starting at the EA
`SubFunction` byte to `handle_func_0x56()` in `src/namspace.c`, and maps the
handler's non-negative return value to `data_len` or its negative return value
to the NCP Completion code.
- The NDK/Core-Protocols EA table lists through-3.x subfunctions `86/01`
through `86/05`; all five source slots are present in `src/namspace.c`, so no
additional disabled source stubs are needed for this block.
- `86/01 Close Extended Attribute Handle` is a success shim: it ignores the
handle and returns no reply payload.
- `86/02 Write Extended Attribute` is a success shim: it does not persist EA
data and currently returns no reply payload, although the NDK reply format
includes `ErrorCode`, `BytesWritten`, and `NewEAHandle`.
- `86/03 Read Extended Attribute` returns a fixed body with `ErrorCode`
`0xc9` / `ERR_EA_NOT_FOUND` and zero lengths/handle fields, rather than
reading real EA storage.
- `86/04 Enumerate Extended Attribute` returns a fixed all-zero body and no
enumerated EA structures.
- `86/05 Duplicate Extended Attributes` has a source case but is intentionally
unimplemented and returns unknown request via `0xfb`.
Follow-up:
- Keep this block as a compatibility shim unless a concrete client needs real
Extended Attribute storage.
- If real EA support is added, decide whether to use the existing Unix xattr
layer, the future `libdirectory` store, or a filesystem-backed sidecar, and
add packet tests for the Lo-Hi EA handle structs, flag information levels,
and multi-action EA return values.
### Name Space group 0x2222/87 core block
Current status:
- `NCP 0x2222/87` / wire `0x57` is endpoint-audited for the core
namespace subfunctions `87/01` through `87/12`. `src/nwconn.c` forwards
requestdata starting at the Name Space `SubFunction` byte to
`handle_func_0x57()` in `src/namspace.c`, and maps a non-negative handler
return value to `data_len` or a negative value to the NCP Completion code.
- The audited source slots are present for `87/01` Open/Create File or
Subdirectory, `87/02` Initialize Search, `87/03` Search for File or
Subdirectory, `87/04` Rename Or Move, `87/05` Scan for Trustees, `87/06`
Obtain File/Subdirectory Information, `87/07` Modify DOS Information,
`87/08` Delete, `87/09` Set Short Directory Handle, `87/10` Add Trustee Set,
`87/11` Delete Trustee Set, and `87/12` Allocate Short Directory Handle.
- No new disabled source stubs were needed for this core block: the local
NDK/Core-Protocols table jumps from `87/12` to salvageable-file calls such as
`87/16`, and no default-compatibility `87/13`..`87/15` endpoints were found
during this pass.
- Current compatibility notes are documented inline per endpoint. Important
differences include `87/03` returning at most one entry and treating the data
stream as the same value as NameSpace, and `87/10`/`87/11` expecting trustee
entries after fixed legacy path-structure areas.
Follow-up:
- Continue the `0x2222/87` audit after the later salvage/metadata subset. Keep
the comments per endpoint rather than adding a large pre-block checklist.
### Name Space group 0x2222/87 salvage and metadata subset
Current status:
- `NCP 0x2222/87` / wire `0x57` is endpoint-audited for the later
salvage/metadata/namespace subfunctions `87/16` through `87/29` that are
present in the current source range.
- Active source cases are documented inline for `87/16` Scan Salvageable Files,
`87/17` Recover Salvageable File, `87/18` Purge Salvageable File, `87/20`
Search for File or Subdirectory Set, `87/21` Get Path String from Short
Directory Handle, `87/22` Generate Directory Base and Volume Number, `87/24`
Get Name Spaces Loaded List from Volume Number, `87/26` Get Huge NS
Information, `87/28` Get Full Path String, and `87/29` Get Effective Directory
Rights.
- Disabled source stubs were added for eligible 3.x/4.x metadata gaps that were
not active in the source: `87/19` Get NS Information, `87/23` Query NS
Information Format, `87/25` Set NS Information, and `87/27` Get Name Space
Directory Entry. These stubs are documentation-only and do not change runtime
behavior.
- `87/26` already had a source slot, but it is effectively unimplemented and
still returns the default `0xfb` unknown request completion.
### Name Space group 0x2222/87 open/create callback subset
Current status:
- `NCP 0x2222/87` / wire `0x57` is source-stub-audited for the next
documented namespace subfunctions `87/30` through `87/35`.
- The current source did not contain active handlers for this range, so disabled
`#if 0` stubs were added at the correct selector locations for:
`87/30` Open/Create File or Subdirectory with DataStream, `87/31` Get File
Information, `87/32` Open/Create File or Subdirectory with Callback, `87/33`
Open/Create File or Subdirectory II with Callback, `87/34` Open CallBack
Control, and `87/35` Modify DOS Attributes on a File or Subdirectory.
- These endpoints are eligible under the stub rule because they are 3.x/4.x
namespace/file-system compatibility calls, including planned 4.x callback and
DataStream variants. The stubs are documentation-only and leave runtime
behavior unchanged.
Follow-up:
- Continue the namespace audit with the remaining `87` subfunction ranges such
as `87/36`..`87/44`, `87/64`..`87/69`, or the matching `89` long-name-space
family. Keep future missing 1.x/2.x/3.x and planned 4.x endpoints as
disabled source stubs at the correct selector location, not as prose-only
notes.
### Name Space group 0x2222/87 lock/quota/search/salvage-rights subset
Current status:
- `NCP 0x2222/87` / wire `0x57` is source-stub-audited for the next
documented namespace/file subfunctions `87/36` through `87/43`.
- The active source had no handlers for this range, so disabled `#if 0` stubs
were added at the correct selector locations for:
`87/36` Log File, `87/37` Release File, `87/38` Clear File, `87/39` Get
Directory Disk Space Restriction, `87/40` Search for File or Subdirectory Set
(Extended Errors), `87/41` Scan Salvageable File List, `87/42` Purge
Salvageable File List, and `87/43` Revoke File Handle Rights.
- `87/44` Update File Handle Rights is documented as NetWare 5.x in the NDK
material, so it is intentionally not added as a source stub under the current
1.x/2.x/3.x plus planned-4.x scope.
- These stubs are documentation-only and leave runtime behavior unchanged.
### Name Space group 0x2222/87 later-generation high selectors
Current status:
- The remaining SDK-listed high selectors in the `0x2222/87` / wire `0x57`
family are explicitly reviewed for scope rather than implemented or stubbed:
`87/44` Update File Handle Rights, `87/64` Read File, `87/65` Write to a
File, `87/66` Get Current Size of File, `87/67` Log Physical Record, `87/68`
Release Physical Record, and `87/69` Clear Physical Record.
- These selectors are later-generation NDK additions and are outside the current
1.x/2.x/3.x plus planned-4.x source-stub rule. Do not add `#if 0` cases for
them during the current endpoint audit unless the project scope is explicitly
extended beyond NetWare 4.x.
- The older direct file-I/O calls (`65`..`77`) and old/new physical-record calls
already audited in `nwconn.c` remain the compatibility paths for the current
scope.
Follow-up:
- The `87` family is now closed for the current endpoint-audit scope. Continue
with the matching `89` Enhanced Name Space family as out-of-current-scope
documentation, AFP `35`, or another unaudited endpoint family requested by
the user.
### Enhanced Name Space group 0x2222/89
Current status:
- `NCP 0x2222/89` / wire `0x59` Enhanced Name Space has been reviewed for
generation scope. `src/nwconn.c` has no top-level `case 0x59`, and the local
NDK/Core-Protocols Enhanced NCP chapter lists the `89/xx` operations as a
later-generation family, with request pages such as `89/04` and `89/17`
marked for NetWare Servers 6.5 SP2.
- The documented `89` selectors are enhanced variants of namespace, trustee,
salvage, EA, and rights calls already represented for the current scope by the
`86` EA and `87` namespace audits. Examples include `89/01` Open/Create,
`89/02` Initialize Search, `89/03` Search, `89/04` Rename/Move, `89/05` Scan
Trustees, `89/06` Obtain Information, `89/07` Modify DOS Information,
`89/08` Delete, `89/09` Set Short Directory Handle, `89/10` Add Trustee Set,
`89/11` Delete Trustee Set, `89/12` Allocate Short Directory Handle, salvage
and metadata selectors `89/16`, `89/17`, `89/19`, `89/20`, `89/22`, `89/25`,
`89/28`, `89/29`, `89/35`, `89/39`, `89/40`, plus enhanced EA/rights
selectors `89/50`, `89/52`, `89/53`, `89/54`, and `89/71`.
- Under the current target rule, this block is out of source-stub scope because
it is later than the planned NetWare 4.x compatibility target. Do not add a
disabled top-level `case 0x59` or per-selector `#if 0` stubs unless the
project scope is explicitly extended beyond NetWare 4.x.
Follow-up:
- If the target is extended later, treat `89` as a filesystem/namespace provider
family, not NDS. Reuse the normalized selector-path audit style from `87`,
and map any real implementation onto the future filesystem/namespace provider
rather than `nwnds`.
### NDS/NCP Fragger group 0x2222/104
Current status:
- `NCP 0x2222/104` / wire `0x68` is planned NetWare-4.x/NDS work, not a
default NetWare-3.x server feature. `src/nwconn.c` already had a top-level
`case 0x68` that returns `0xfb`; patch 0217 keeps that runtime behavior and
adds disabled `MARS_NWE_4` source-stub selectors for the documented NDS
subfunctions.
- The documented selector slots are `104/01` Ping for NDS NCP, `104/02` Send
NDS Fragmented Request/Reply, `104/03` Fragment Close, `104/04` Return
Bindery Context, `104/05` Monitor NDS Connection, `104/06` Return NDS
Statistics, `104/07` Clear Statistics, and `104/08` Reload NDS Software.
- `104/02` is a nested-selector endpoint: after the NDS SubFunctionCode it
carries a 32-bit NDS `Verb` payload field. Document selector paths as
`0x2222/104/02 verb=<Verb>` when future nwnds work reaches this block; do
not flatten the verb into a one-byte NCP case.
- Future implementation belongs to `nwnds` and `libdirectory`, with `nwserv`
used only for control-plane actions such as reload/supervision. Normal NDS
request payloads must not be routed through `nwserv` as a data-plane broker.
Follow-up:
- Keep the `MARS_NWE_4` stubs disabled until a real `nwnds`/fragment-state
design exists. The next endpoint audit can continue with deeper `23`
bindery/property/admin coverage, `36`/`37` NCP Extension scope, print/spool
`17`, or another user-selected family.
### Retrospective source-stub coverage for already audited blocks
Current status:
- The endpoint-stub scope is source-level as well as documentation-level. When
an already audited family has a documented 1.x/2.x/3.x compatibility gap or a
planned 4.x gap, the dispatcher should contain a disabled `#if 0` slot marker
at the correct numeric case, unless that slot is already active.
- Retro-check of the already touched families found the known eligible stubs
already present in source:
- Directory Services `22/12` / wire `0x0c`, `22/35` / wire `0x23`, and
`22/36` / wire `0x24` are disabled source stubs in `src/nwconn.c`.
- File Server Environment `23` queue/server-management gaps that were
previously documented as disabled stubs are present in `src/nwbind.c`.
- No source stubs are needed for message `21/04`..`21/08` because they were not
default-compatibility server endpoints in the checked SDK/PDF/WebSDK material.
`21/12` remains later-generation only and should stay out of source under the
current through-4.x planning scope.
- Physical-record `26`..`31` plus `110`, TTS `34/00`..`34/10`, and direct file
commit/search/I/O `59`, `61`..`77` did not expose additional eligible missing
slots during the retro-check.
Follow-up:
- For each next endpoint-family patch, record the source outcome inline: active
case, already-present disabled stub, newly added disabled stub, no server
endpoint, or later-generation/out-of-scope.
- If a disabled stub already exists, do not churn its code merely to restyle it;
add or adjust prose only unless the user explicitly asks for cleanup or the
endpoint is being implemented.
### AFP / Mac namespace backend
Current status:
- The current AFP compatibility slice is implemented and covered by the smoke
tests under `tests/afp/`. Endpoint inventory, WebSDK audit notes, and AFP
implementation history live in that directory instead of this project-level
TODO file.
- AFP `0x13 Get Macintosh Info On Deleted File` is implemented as a
salvage/deleted-entry adapter and covered by the AFP smoke suite. It returns
FinderInfo, ProDOSInfo, resource fork size, and deleted filename from the
shared Salvage snapshot.
- ProDOSInfo is persisted through the existing `nwatalk` AFP metadata xattr
layer (`org.mars-nwe.afp.prodos-info`) and is captured/restored in Salvage as
`prodos_info_hex`; no parallel AFP metadata store was added.
- The verified AFP smoke suite covers live FinderInfo/ProDOSInfo xattrs, AFP
35/19 deleted-file metadata, and the readonly Modify-rights negative path.
- Keep future AFP deleted-file work on the shared salvage backend; do not expose
`.recycle` or `.salvage` through normal AFP/NCP path opens.
- Keep AFP metadata restore/lookup paths tied to the existing mars_nwe AFP and
nwatalk mechanisms, not a new side database.
- Keep the detailed AFP inventory and audit notes in `tests/afp/`.
- Patch `0214` also records the NCP-level AFP 35/01..35/19 coverage inline in
`src/nwconn.c`: all documented NDK/Core-Protocols AFP subfunctions in that
range are represented by the current dispatcher, so no new missing-endpoint
source stubs are needed for the current 1.x/2.x/3.x plus planned-4.x scope.
Follow-up:
- AFP endpoint coverage is now documented at the NCP dispatcher level. Continue
any remaining WebSDK/client-trace cleanup only where `tests/afp/` inventory
files still mark a behavioral or metadata-layout issue.
## Deferred / optional protocol work
* Basic Packet Burst file transfer support is implemented and verified with a
diagnostics-enabled DOS client test.
* Packet Burst support is built by default, but runtime use remains controlled
by `nwserv.conf`. Endpoint coverage for SDK `97` and `101` is now
documented; remaining Packet Burst work is behavioral/client-trace driven.
* Packet Burst/NDS fragmentation support remains out of scope unless a concrete
client requires it.
Reference in New Issue View Git Blame Copy Permalink