# AI working notes for mars-nwe This file is for future ChatGPT sessions. It records general working rules and local build/test notes only. It should not be used as the current project status log; the current patch stack and task context should be pasted into a new chat separately. ## Start of a new chat When the user says this is a new chat or asks to continue mars-nwe work, first read this file before proposing patches or making assumptions. Then ask for, or use, the current project status that the user pasted into the chat. ## Current handoff status after patch 0222 The current accepted patch line in this chat is expected to include: - endpoint-audit/documentation patches through `0176-docs-audit-direct-lifecycle-buffer-endpoints.patch`; - redesign documentation patches `0177` through `0198`; - endpoint-audit/documentation patches `0199` through `0219`; - redesign clarification patch `0220-docs-record-print-queue-redesign-link.patch`; - endpoint-audit patch `0221-docs-audit-ncp-extension-stubs.patch`; - endpoint-audit patch `0222-docs-audit-direct-file-metadata-stubs.patch`; - latest expected patch name: `0222-docs-audit-direct-file-metadata-stubs.patch`. When continuing in a new chat, first ask the user which patch was actually last applied. If they confirm `0222`, build the next patch as `0223-...` against a tree that already contains `0222`. If they only applied through `0221`, apply or rebuild `0222` before continuing endpoint work. If any patch failed or was skipped, rebuild against the last confirmed applied patch instead of assuming the file in `/mnt/data` was accepted. Known numbering/patch-history notes from this chat: - `0190-docs-clarify-imported-nwlog-backend-layout.patch` was superseded because patch number `0189` was accidentally skipped and the old `0190` failed after `0188`. Do not reuse that old file. - Use `0189-docs-clarify-imported-nwlog-backend-layout.patch` instead. - Then use `0190-docs-clarify-simple-syslog-nwlog-backends.patch`, followed by `0191` ... `0203`. The user prefers patch verification snippets to contain only: ```sh git am patchname.patch ``` Do not include `git diff --check HEAD^..HEAD` in the final summary unless the user asks for it. ## Current redesign decisions to preserve `REDESIGN.md` is now the place for broad architecture notes. Do not keep growing `TODO.md` with long-term redesign material. `TODO.md` should remain for concrete endpoint/test/fix follow-ups. High-level NCP architecture direction: - Add a small internal NCP dispatch/handoff layer over time; avoid a large message-bus rewrite. - Provider boundary is not the same as process boundary. - `nwbind` remains legacy bindery provider/service. - Queue is a strong candidate for a future `nwqueue` provider/process, but first split it logically from bindery. NCP Extension note from patch `0221`: - SDK `0x2222/36` / wire `0x24` NCP Extension information and SDK `0x2222/37` / wire `0x25` Execute NCP Extension are source-stub-audited as planned NetWare 4.x extension-registration work. - `src/nwconn.c` now contains disabled `MARS_NWE_4` stubs for `36/00` through `36/06` and direct `37`. They intentionally return `0xfb` if ever enabled without a real extension registry/provider. - Future owner is an extension registry/provider. Do not route extension payloads through `nwserv` as a data-plane broker; `nwserv` remains only control-plane/supervision/registry. - Patch `0222` audits the remaining old direct file-metadata/open-create compatibility slots SDK `0x2222/79`, `0x2222/84`, and `0x2222/85` / wire `0x4f`, `0x54`, and `0x55`. No active top-level handlers existed; the patch records disabled `#if 0` stubs in `src/nwconn.c`. Future owner is the filesystem/namespace provider, not NDS. - The next patch number should be `0223` if `0222` was applied. Print/queue redesign note from patch `0220`: - Do not describe printing as entirely absent. Queue-backed printing already exists in the project through the queue/job printing paths. - The old direct `0x2222/17` Print/Spool NCP family is a separate compatibility surface and currently remains documented as disabled stubs. - Future direct `17/xx` implementation should bridge to existing queue printing mechanics rather than creating a separate print subsystem. - Logical owner: queue/print-spool provider area, possible future `nwqueue`; not `nwnds`, not `nwdirectory`. - Filesystem/volume/namespace should become a provider/module boundary first; a separate process would be risky and later only. - Semaphore, server-management, and most small call families should remain modules/providers, not separate processes. - `nwserv` is the control plane/supervisor/provider registry, not a data-plane payload router. Normal requests should flow `client -> nwconn -> provider -> nwconn -> client`, not through `nwserv` as broker. - Provider processes must always return one formal internal handoff reply. `NO_REPLY` is an explicit reply kind, not silence. `nwconn` owns the final client NCP reply envelope and send. Transport direction: - TCP/IP support is a transport split below `nwconn`/`nwserv`, not a new daemon. - Planned code layout: `src/nwtransport.c`, `src/nwipx.c`, `src/nwtcp.c`. - `nwtransport` is a code/library boundary, not a process. - Higher providers must not depend on raw `ipxAddr_t` long-term. - IPX SAP/RIP/watchdog/broadcast behavior remains isolated as IPX-specific. Secure IPC/TLS direction: - Client-facing NetWare 4.x/NCP/NDS compatibility must not require TLS by default. Keep historical clients compatible. - LDAP/LDAPS/StartTLS for `nwdirectory` should use the `nwtls` facade with the selected GPL-2.0-compatible backend; MatrixSSL is the current preferred candidate. - Internal provider IPC over TCP, if added later, must always use backend-backed TLS with mutual authentication through `nwtls`. MatrixSSL is the current preferred candidate; no plaintext fallback for TCP provider IPC. - Local IPC may remain Unix-domain sockets, pipes, socketpairs, or inherited FDs with strict permissions; still avoid logging decoded secrets. - Add `nwtls` as the internal TLS facade if/when TLS is wired into runtime: `include/nwtls.h`, `src/nwtls.c`, `src/nwtls_matrixssl.c`. Directory/NetWare 4.x direction: - `libdirectory` is the shared internal C API/library used by `nwbind`, future `nwnds`, `nwdirectory`, and `nwsetup`. These components should not talk LDAP internally just to reach the directory store. - `libflaim` is the planned persistent store under `libdirectory`. FLAIM is C++; keep its C++ API behind `libdirectory` so old mars-nwe C code does not include FLAIM C++ headers directly. - `nwdirectory` is the mars-nwe integration name for the tinyldap-derived LDAP/LDAPS service. Standalone/upstream identity remains `tinyldap`; inside mars-nwe it builds the `nwdirectory` service. - Future `nwnds` is the NetWare 4.x/NDS compatibility layer and should use `libdirectory`, not LDAP protocol calls, as its internal backend path. - `nwbind` should eventually become a legacy bindery adapter over `libdirectory`/`libflaim`, not maintain a second persistent truth. - Do not mention or design Kerberos for the current NetWare 4.x target. Configuration and setup direction: - Move toward a real typed, documented INI format. Do not use JSON as the admin config format. - The generated INI is also user documentation. Writers must preserve comments where possible or regenerate from a full documented template; never rewrite it into an undocumented minimal key/value dump. - `nwsetup` is the provisioning/setup tool. It should initialize the `libdirectory`/`libflaim` store, create initial schema/tree/admin/server objects, migrate bindery data later, and edit config atomically. - No reusable Admin/Supervisor/NDS/LDAP plaintext passwords in the new typed INI. Initial passwords and recovery resets belong to explicit `nwsetup` commands and only hashes/verifiers go into the store. - Legacy bindery config-password reset may remain only as deprecated compatibility behavior; Directory/NDS mode uses `nwsetup` recovery commands. Logging direction: - Add a small internal `nwlog` facade instead of direct zlog/log.c calls in handlers/providers. Project layout: `include/nwlog.h`, `src/nwlog.c`. - Category wrappers should exist for normal code: `nwlog_ncp()`, `nwlog_handoff()`, `nwlog_bindery()`, `nwlog_queue()`, `nwlog_directory()`, `nwlog_nds()`, `nwlog_ldap()`, `nwlog_auth()`, `nwlog_acl()`, `nwlog_recovery()`, `nwlog_security()`. They populate an internal `nwlog_event` and call `nwlog_emit()`. - `rxi/log.c` may be vendored/adapted as `nwlog_simple`, not exposed directly: `include/nwlog_simple.h`, `src/nwlog_simple.c`. It is a simple stderr/stdout/file/callback basis and is a good default for systemd/journald. - `nwlog_syslog` may later be derived/cloned from the simple backend for classic `syslog(3)` explicitly: `src/nwlog_syslog.c`. - `zlog` is the preferred optional advanced routing backend behind the facade: `src/nwlog_zlog.c`. It may live as a `third_party/zlog` submodule. - Never route raw decoded NCP/handoff/auth payloads to remote loggers. Only redacted structured events should leave the host. Third-party/fork policy: - Fixed third-party libraries live under `third_party/`, such as existing `yyjson`, planned `matrixssl`, planned `libflaim`, and optional `zlog`. - `MatrixSSL` is the preferred GPL-2.0-compatible crypto/TLS candidate and should be imported as a maintained fork with a native CMake build if selected. Do not design a first-pass OpenSSL/LibreSSL backend matrix. - `libflaim` should live under `third_party/libflaim` as a mars-nwe-maintained import/fork/mirror. Source may come from SourceForge/SVN and/or a distro source package such as openSUSE `libflaim-4.9.1046`. Document exact import, revision/version, license files, distro patches, and local patches in `third_party/libflaim/README.mars-nwe.md`. - FLAIM r1112 has Autotools (`configure.ac`, `Makefile.am`, libtool, `config.h`, subprojects `ftk`, `flaim`, `sql`, `xflaim`). Do not wrap Autotools from CMake; replace it with a real CMake build. First required targets are `FLAIM::ftk` and `FLAIM::flaim`; SQL/XFLAIM/tools/tests/docs can come later. - FLAIM source license observed by the user: library sources LGPL-2.1; helper files like `svn2cl.xsl` may have separate licenses such as BSD-3-Clause. Keep these separated in import docs. - Forked/integrated mars components that become project services live in the repository root, matching existing style such as `mail`, `admin`, and `dosutils`. `mars-tinyldap` belongs in the root, not `third_party`, because it will be heavily adapted into `nwdirectory`. - tinyldap currently has a hand-written Makefile and flat-file/mmap storage. It needs a real CMake build, not a Makefile wrapper. Standalone remains `tinyldap`; mars-nwe integration builds `nwdirectory`. - For tinyldap/nwdirectory, first CMake split can expose internal targets such as `tinyldap::asn1`, `tinyldap::ldap`, `tinyldap::ldif`, `tinyldap::auth`, `tinyldap::storage`, and `tinyldap::server`. Replace flat-file storage with `libdirectory -> libflaim` later. - Old tinyldap TLS code can remain reference/legacy/standalone-only; mars-nwe `nwdirectory` TLS should go through `nwtls`/MatrixSSL once the backend is selected. Schema/import direction: - Do not invent NetWare 4.11 schema by hand if a real source can be obtained. The user expects the complete schema to be hidden in NetWare 4.11 installation material such as `install.dat`; a real 4.11 install may be needed to extract it. - `.SCH` files such as uploaded `NLS.SCH` are useful format examples/fragments. They contain readable ASN.1-like `ATTRIBUTE` and `OBJECT-CLASS` blocks, but are not the full schema truth. - `nwsetup` should eventually support native NetWare 4.11 schema import, `.SCH` fragment import, and LDIF import/export. LDIF remains human-readable, diffable, and testable, but the canonical runtime representation is `libdirectory` schema objects stored in `libflaim`. - tinyldap has useful ASN.1 BER/DER and LDIF code (`scan_asn1*`, `fmt_asn1*`, `asn1dump`, `ldif_parse.c`), but it does not appear to be an NDS `.SCH` or NetWare schema importer. Reuse ideas/code carefully through the `nwdirectory` fork, but plan a dedicated schema import layer. - Samba `source4/dsdb/schema` and setup schema conversion code are useful references for OID/prefixMap/schema-loading ideas, but Samba is GPL-family; do not blindly copy code into mars-nwe. Use as a reference and implement a mars-nwe-native importer/OID module. Latest endpoint audit note: - Patch `0221` audits SDK `0x2222/36` / wire `0x24` NCP Extension information and SDK `0x2222/37` / wire `0x25` Execute NCP Extension as planned NetWare 4.x extension-registration work. - `src/nwconn.c` contains disabled `MARS_NWE_4` stubs for `36/00` through `36/06` and direct `37`; they are documentation/source markers only and do not change the default runtime. - Future implementation needs an extension registry/provider. `nwserv` may supervise/register providers but must not become the data-plane broker for extension payloads. - Patch `0222` audits SDK `0x2222/79`, `0x2222/84`, and `0x2222/85` / wire `0x4f`, `0x54`, and `0x55` as old direct file-metadata/open-create and sparse-data compatibility gaps. It adds disabled `#if 0` stubs next to the old direct file-I/O switch in `src/nwconn.c`; future owner is the filesystem/namespace provider. - Previous print note still applies: direct `17/xx` spool NCPs are only the old direct-spool compatibility surface; queue-backed printing already exists. The next patch number should be `0223` if `0222` was applied. Likely next blocks are deeper `0x2222/23` bindery/property/admin subfunction coverage, SDK `0x2222/90` scope, or another user-selected endpoint family. ## Patch workflow - Produce patches that apply with exactly: ```sh git am patchname.patch ``` - Assume the user has already applied and committed accepted earlier patches. Build every new patch against the current tree the user provides. - Do not ask the user to apply a long patch chain unless they explicitly say earlier patches were not committed. - Keep follow-up patches small and reviewable. Do not mix functional changes, cleanup, and logging refactors unless the user asks for that. - If a patch is only documentation or test cleanup, keep it that way. ## Current protocol audit scope - The current endpoint documentation/audit pass is scoped to compatibility NCPs through NetWare 3.x by default, including NetWare 1.x/2.x legacy calls where they are documented. Bucket endpoints by the oldest NetWare generation that documents them: put 1.x/2.x legacy calls in their own sections, keep the remaining through-3.x compatibility calls in the 3.x/default section, and put endpoints introduced in NetWare 4.x in a separate planning/stub section. Do not create stub work merely for NetWare 5.x/OES/MOAB/newer endpoints. - NetWare 4.x-only endpoints are not part of the default implementation target yet, but they are the current forward-planning target. Already implemented compatibility code must not be removed or wrapped just because it is 4.x-era; only new, not-yet-implemented 4.x stubs should be placed behind `#if MARS_NWE_4`. Do not add disabled stubs for 5.x/OES/MOAB/newer calls unless the user explicitly changes the target scope later. `MARS_NWE_4` is currently hard-disabled in `include/config.h.cmake` and should stay `0` unless the user explicitly asks to start that work. - When a `0x2222` group or subfunction is forwarded out of `nwconn.c`, follow the handoff before declaring the endpoint documented. `nwconn.c` should document the handoff and the exact header/payload bytes that are preserved or rewritten before forwarding; the destination file (for example `nwbind.c`) must document the concrete subfunction request/reply layout at the real handler. Do not stop at a comment such as `nwbind must do prehandling`, `nwbind must do the rest`, or `handled by nwbind`. - For forwarded paths, document any nwconn-side payload mutation as part of the audit. Examples in the current tree include queue create path expansion, queue job file-handle insertion, quota bindery prehandling, and semaphore/message group forwarding. If a forwarded subfunction is not audited yet, record it as a target-file follow-up rather than only documenting the nwconn dispatcher. - For documentation-only endpoint patches, do not change parser offsets, byte order, reply layout, or completion behavior. Always compare the code parser/reply layout against the applicable SDK/WebSDK/PDF request format and, when available, the uploaded SDK include prototypes. If the code differs from the SDK layout, document the concrete difference inline and mirror it in `TODO.md` for later testing. If it matches, say so in the patch summary so the audit trail is clear. - When an SDK/WebSDK/PDF endpoint number is written in decimal notation, convert it carefully to the wire `case` value before adding inline documentation. Example: Directory Services `0x2222/22/12` in the PDF means SubFunctionCode decimal 12, i.e. wire `case 0x0c`; it is not the existing `case 0x12` / decimal 18 Allocate Permanent Directory Handle. Place disabled stubs directly at the correct numeric slot inside the dispatcher, never appended at the end of the function. For implemented endpoints, keep the detailed documentation inside the relevant `case` block, immediately after the `case` label/opening brace, matching the local style; do not leave a large endpoint block before the `case` label. - If a PDF/WebSDK page title and an internal table row disagree, prefer the endpoint title plus include/WebSDK cross-checks and record the mismatch instead of inventing a new wire case. Example: `0x2222/23 Verify Serialization` is titled SDK decimal `23/12` / wire `0x0c`, even though one PDF table row prints `SubFunctionCode (212)`; do not add a wire `0xd4` case without a packet trace or include-level confirmation. - In `TODO.md` and endpoint summaries, avoid ambiguous mixed notation for grouped subfunctions. Write SDK/PDF numbers as decimal and include the wire byte explicitly when it differs or could be confused, for example `SDK 22/18 / wire 0x12` or `SDK 22/12 / wire 0x0c`. Do not write `22/12` for a wire `case 0x12` unless the SDK number is actually decimal 12. - Do not assume every `0x2222` endpoint key is only `request_type/function/subfunction`. Some SDK/PDF/WebSDK families have deeper selectors inside the subfunction payload, such as NDS `0x2222/104/02` with a 32-bit NDS `Verb`, statistical `0x2222/123/34` with `InfoLevelNumber`, NCP extension `0x2222/36`/`37` with dynamic extension numbers, or reply layouts selected by an information type. When auditing such a family, document the selector path explicitly, for example `0x2222/104/02 verb=` or `0x2222/123/34 level=`, and distinguish true wire dispatch bytes from payload fields that merely select a structure or backend operation. - Keep `TODO.md` endpoint audit notes grouped by endpoint family and NetWare generation instead of as one long flat list. - Before starting the next detailed endpoint block, maintain a coverage index for SDK/WebSDK-listed `0x2222` groups that are not yet audited. Classify each group as present in code but not audited, missing a top-level handler, or likely later-generation/unclear. This index is only a planning aid: do not add active TODO work or source stubs until the specific block has been checked for handoffs and bucketed by oldest documented NetWare generation. - Before every new endpoint-family patch, first do a missing-endpoint pass for that family: enumerate the SDK/PDF/WebSDK/include endpoint list, compare it against actual `case` labels and forwarded destination handlers, then document implemented, disabled-stub, and absent slots separately. Do this retroactively for already documented families when touching them again. - Always document both the request handoff/parser and the reply builder. For forwarded calls, the `nwconn.c` comment should explain exactly why `return(-1)` or `return(-2)` is used; the destination handler should explain the concrete request bytes and response payload. Do not treat `return(-1)` inside disabled `#if 0` snippets in `nwbind.c` as a forwarding mechanism. - For SDK-listed groups that appear missing from `nwconn.c`, also search destination files such as `nwbind.c`, queue helpers, salvage helpers, AFP/name-space dispatchers, and any prehandler path before declaring the endpoint absent. - The rejected `0152-docs-note-message-control-subfunction.patch` must not be applied: it documented `0x2222/21/0x0c Connection Message Control`, which is outside the default NetWare 1.x/2.x/3.x MARS-NWE target scope. ## mars-nwe coding style rules - Prefer existing mars_nwe / NetWare functions over new helper code. - Before adding a helper, search the tree for an existing equivalent. - Do not introduce parallel mechanisms for paths, trustees, xattrs, AFP metadata, copy/write/restore, u16/u32 packing, or logging. - Use existing integer and wire-format macros such as `GET_16`, `GET_32`, `U16_TO_16`, `U32_TO_32`, and related mars_nwe helpers instead of open-coded byte parsing/serialization. - Use existing namespace/path conversion and basehandle logic instead of parsing NetWare paths by hand. - For file restore/copy/write behavior, prefer the existing Novell/mars_nwe file functions over direct POSIX operations. Use POSIX only where there is no suitable internal mechanism, and keep it clearly isolated. - Do not add a new trustee or xattr database. Salvage JSON is a snapshot; real restore should feed existing mars_nwe trustee/xattr/AFP mechanisms. ## NCP path and hidden repository notes - Normal NCP path resolution intentionally treats Unix dot path components as hidden/special. In the classic path resolver (`build_dir_name()` in `connect.c`), a component beginning with `.` is accepted only for `.`/`..` semantics; a component such as `.recycle` or `.salvage` returns invalid path (`0x899c`). - `nwattrib.c` also marks Unix dot files/directories hidden by default when no explicit NetWare attributes are stored. - Therefore `.recycle` and `.salvage` are backend repositories, not user-visible NCP paths. Tests must not expect `SYS:.recycle/...` or `SYS:.salvage/...` to open through ordinary NCP file calls. - Use the official salvage endpoints (`87/16` scan, `87/17` recover, `87/18` purge, and old `22/27`-`22/29`) to observe or operate on salvage entries. Verify recovered payload content by reading the restored live file through NCP, not by opening backend repository paths through NCP. ## Salvage endpoint rules - `NCP 0x2222 / 87 / 16` is decimal 87/16, implemented as function `0x57`, subfunction `0x10`. - `NCP 0x2222 / 87 / 17` is decimal 87/17, function `0x57`, subfunction `0x11`. - `NCP 0x2222 / 87 / 18` is decimal 87/18, function `0x57`, subfunction `0x12`. - Legacy salvage endpoints are old function `22` decimal / `0x16`: `22/27` scan, `22/28` recover, and `22/29` purge. They should remain thin adapters over the same shared salvage backend, not a second implementation. - Keep `0x57` subfunction dispatch in `handle_func_0x57()` / namespace code, not as a second subfunction switch in `nwconn.c`. - Old `0x16` calls need a minimal bridge in namespace code because short directory handles must be resolved through existing `build_base()` / `dir_base[]` internals before reaching the shared backend. - Versioned backend payload names follow Samba `vfs_recycle` literally: `Copy #1 of NAME`, `Copy #2 of NAME`, ... . Do not localize this string and do not run it through gettext; the NCP scan reply still reports the original deleted filename for every version. - Versioned salvage entries may have different `.recycle`/`.salvage` names but `87/16` returns the original deleted filename for every version. Do not match recover/purge by display name alone. - Scan must treat `.salvage` JSON as a sidecar for the matching `.recycle` payload. If an external tool such as Samba or an administrator removes the payload, `87/16` must not return the stale sidecar and should remove the JSON. The server log should contain a greppable line like `WARN SALVAGE 87/16 STALE ...` for this cleanup. - Scan, recover, and purge should share the same scan/sequence/basehandle view so that a sequence returned by scan identifies the exact sidecar used later. - The combined salvage smoke suite now covers NCP write/read payloads, 87/18 purge pre-clean, hidden backend repository behavior, stale sidecar cleanup with a manual payload-removal pause, three version captures, and recovering the oldest version via sequence 0. - Append salvage endpoint tests to `tests/salvage/salvage_smoke_suite.sh` rather than creating unrelated top-level scripts, unless a helper binary is needed and then started by the suite. ## AFP 0x13 deleted-file info notes - AFP `0x13 Get Macintosh Info On Deleted File` is NCP `0x2222 / 35 / 19` (wire subfunction byte `0x13`). The Micro Focus / Novell WebSDK request is `VolumeNumber` plus `DOSDirectoryNumber`; the reply is FinderInfo[32], ProDOSInfo[6], ResourceForkSize, FileNameLen, FileName. - Implement it only as an adapter over the shared mars_nwe salvage/deleted-entry record. Do not expose or normally open `.recycle` or `.salvage` through AFP code; those remain hidden backend repositories. - The implementation returns FinderInfo[32], ProDOSInfo[6], resource fork size, and deleted original name from the Salvage JSON snapshot. FinderInfo and ProDOSInfo are captured through the existing nwatalk xattr-backed AFP metadata store, not through a parallel AFP metadata database. - The AFP smoke suite has a dedicated `afp_deleted_info_smoke` helper. It pre-cleans salvage entries in the tested directory through NCP purge, creates a temporary AFP file, writes FinderInfo and ProDOSInfo, deletes it, verifies AFP `0x13`, and purges the tested deleted entry afterwards. - Verified AFP smoke status: the full suite completed with `failures=0` after AFP 35/19 and ProDOSInfo work. It verifies live FinderInfo and ProDOSInfo xattrs on `SYS:PUBLIC/pmdflts.ini`, verifies AFP 35/19 returns `prodos=010203040506` from the deleted-file Salvage snapshot, and leaves normal AFP-only attributes absent when Hidden/System/Archive map through the NetWare attribute path. - Reuse existing AFP/nwatalk metadata mechanisms for FinderInfo, AFP attributes, entry ids, resource fork state, and related restore/lookup behavior. Do not add a parallel AFP metadata database. ## Logging rules Desired future server log format: ```text key=value ... ``` - `LVL4` is exactly four characters: `INFO`, `DBUG`, `WARN`, `ERRR`. - `AREA` examples: `NCP`, `SALVAGE`, `AFP`, `MAP`, `BIND`, `TRUST`, `AUTH`, `CONN`, `FILE`, `QUEUE`. - The front code should be human/protocol decimal where applicable, for example `87/16`, `87/17`, `87/18`. - Exact wire values should still be logged later as key/value hex fields, for example `fn=0x57 sub=0x10 seq=0x00000000 base=0x00000004 result=0x89ff`. - Unknown or unimplemented endpoints should be easy to grep, 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" ``` - Do not invent a parallel logger casually. Reuse existing mars_nwe logging functions/macros and normalize message format gradually. ## 2026-06-06 - handoff for next chat: redesign plus FLAIM/directory foundation This is the latest working handoff from the long FLAIM/MatrixSSL/nwssl session. If a new chat starts, ask the user for the current root bundle and the current bundles or pushed refs for all submodules before constructing a build tree. Do not assume the bundles named in the old chat are still current. There are now two active work streams. Keep them separate in patches and in commit messages: 1. **mars-nwe redesign / future-proofing of existing code.** This is the `REDESIGN.md` track. The next intended first task is small: add a typed enum/type layer for internal operations/request kinds/schema-facing IDs so old magic strings and magic numbers can be translated at one boundary before moving larger logic. Read `REDESIGN.md`, `TODO.md`, and this file before proposing the first enum patch. Do not start with a large rewrite. 2. **vendored storage/crypto/directory infrastructure.** This is the track that introduced `libnwowfat`, `libnwsodium`, `libnwmatrixssl`, `libnwssl`, `libnwflaim*`, and `libnwdirectory`/tinyldap integration. The purpose is to later replace old local helper code and, more importantly, to move tinyldap/nwdirectory away from flat files toward a FLAIM-backed store. Current green test state reached in the previous chat: ```sh ctest -L flaim --output-on-failure # nwflaim.database.create-and-check ......... Passed # mars_nwe.flaim.api-create-query-encrypt ... Passed # mars_nwe.xflaim.api-alloc ................. Passed ctest -L nwflaim --output-on-failure # nwflaim.database.create-and-check ... Passed ``` Meaning of the green tests: - FLAIM tools can create and check a database through CTest. - mars-nwe root tests can create a classic FLAIM database, add a dictionary `EncDef` through the dictionary API, write/read/query records, close/reopen the database, and verify the test secret is not visible as plaintext on disk. - `libnwssl` now has a functional NICI/CCS compatibility layer sufficient for classic FLAIM at-rest encryption tests. - XFLAIM stays build-covered but does **not** use the classic FLAIM NICI compat path; NICI support is scoped to classic FLAIM targets only. - FlaimSQL is experimental and must be default `OFF`; do not let default mars-nwe builds link hard against `libnwflaimsql`. Important FLAIM/nwssl fixes that were part of the green state: - `libnwssl` owns `include/nwssl/private/nici/*` and the NICI/CCS compatibility implementation used by FLAIM. - `CCS_Init()` / `CCS_Shutdown()` exist for FLAIM startup/cleanup. - NICI handle types must match FLAIM `FLMUINT` width on 64-bit builds. - MatrixSSL must export the same AES-related compiler options/defines to consumers that it used for `libnwmatrixssl`, otherwise `psCryptoOpen()` fails with a crypto config mismatch. - FLAIM dictionary code had EOF-as-not-found / EOF-as-end-of-base64 decode cases that needed to be treated as success in the relevant paths. - The encrypted root test must create `EncDef` through the dictionary API; do not put `encdef` as a child of a `field` record. Known remaining FLAIM follow-up: - Manual `nwflmgigatest -b` with default 100000 records still hit a `Gleitkomma-Ausnahme` / SIGFPE even though the CTest DB smoke passes. The divisions in `gigaUpdateLoadTimes()` were already guarded. The likely bug is shutdown ordering in `flaim/util/gigatest.cpp`: the code stops the screen thread, then later calls `gigaUpdateLoadTimes()` and stops the screen thread again. The next small mars-flaim patch should move final stats before the first `gigaStopScreenThread()` and stop the screen thread only once. Verify with: ```sh cd /third_party/flaim ./nwflmgigatest -b echo $? ctest -L nwflaim --output-on-failure ctest -L flaim --output-on-failure ``` At-rest encryption/key policy notes: - FLAIM encryption uses a database wrapping key plus EncDef keys. The EncDef key is stored in FLAIM metadata in wrapped/encrypted form; records use the EncDef key for encrypted field/blob storage. - The current `nwssl` NICI/CCS layer is a functional compatibility layer for tests and initial directory storage work. Before storing real production directory secrets, define a key policy: where the server/tree master key lives, how it is created, how backups/restores work, and how rotation will later be handled. - Candidate future key locations are root-only files such as `/etc/mars_nwe/nwssl.key` or `/var/lib/mars_nwe/keys/...` with mode `0600`. Do not hard-code a production master key into the database or source. TinyLDAP / directory follow-up test ideas before replacing flat-file storage: - Create/open/reopen a directory database. - Add user object, group object, and user-to-group membership. - Lookup by DN/name and by indexed common attributes. - Authenticate user/password; password material must not appear plaintext in the FLAIM database files. - Duplicate object/name conflict, delete, rename/move, restart/reopen recovery. - Once the user extracts real NetWare 4.11 schema data, add schema tests for object classes, mandatory/optional attributes, attribute syntax, single/multi-value rules, naming attributes, inheritance, and default indexes. `nwsetup` direction: - ncurses is already needed for FLAIM tools and should also support a future `nwsetup` tool. The user wants a NetWare-like phase-2 setup flow for provisioning the Directory tree. Later `nwsetup` should initialize the FLAIM-backed directory store, create tree/server/org/user/admin objects, set the admin password, create default SYS/volume/config state, and avoid writing reusable plaintext secrets to config files. ## 2026-06-05 - current superbuild / storage / TLS handoff This chat switched from documentation-only endpoint audit work back to build and integration work around the mars-nwe superbuild. The old patch-number guidance below remains useful historical context for the endpoint-audit series, but the current accepted work in this chat is a separate functional/build patch stack. Do not assume the next patch after this point is an endpoint-audit `0269` patch unless the user explicitly returns to that series. Current root/superbuild direction implemented or in progress: - `update-submodules.sh` is now the normal helper for keeping mars-nwe's submodules reproducible. Private mars-owned submodules are updated to their configured latest branch, while external upstream snapshots are pinned by a single editable `EXTERNAL_TAG_PINS` block near the top of the script. - Current external pins are `third_party/yyjson=0.12.0`, `third_party/zlog=1.2.18`, and `third_party/libsodium/libsodium=1.0.20-FINAL`. - The helper must not run a root-level `git submodule update --init --recursive` after updating top-level private submodules, because that can reset updated gitlinks such as `third_party/matrixssl` back to the parent commit. Nested submodules are initialized inside the owning top-level submodule instead. - The helper prints recursive submodule status on success and failure and can auto-commit root gitlink/script changes. Root gitlinks must only reference commits that exist in the respective submodule remotes; a parent gitlink to an unpushed submodule commit will make later `git submodule update` fail with `upload-pack: not our ref`. - `yyjson` is being folded into the mars-nwe core library path. Consumers should include it through the `nwcore` include namespace and link `mars_nwe::core`, not link an independent public yyjson target directly. - FLAIM is currently only needed when the directory service is enabled. The root CMake should therefore add/build `third_party/flaim` only when `ENABLE_DIRECTORY=ON`. - Namespace rule: keep historical mars-nwe binaries with their established names (`nwserv`, `ncpserv`, `nwclient`, `dbmtool`, `ftrustee`, etc.), but give vendored libraries, vendored headers, CMake packages, and imported helper tools an `nw` namespace when they could collide with system packages or upstream tool names. - Current library namespace examples: `libnwowfat`, `libnwsodium`, `libnwmatrixssl`, `libnwflaimtk`, `libnwflaim`, `libnwflaimsql`, `libnwxflaim`, `libnwcore`, `libnwssl`, and `libnwdirectory`. - Current header namespace examples: `include/nwlibowfat/`, `include/nwsodium/`, `include/nwmatrixssl/`, `include/nwflaim/`, `include/nwssl/`, `include/nwcore/`, and `include/nwdirectory/`. - TinyLDAP/directory tools and FLAIM/XFLAIM tools should install with `nw` prefixes (`nwt2`, `nwparse`, `nwldapclient`, `nwx`, `nwflmcheckdb`, `nwxflmdbshell`, etc.) because their upstream names are generic or collision-prone. Current `libnwssl` / MatrixSSL / OpenSSL-compat direction: - MatrixSSL owns only the renamed low-level backend library (`libnwmatrixssl`). Temporary OpenSSL-compat test headers/sources that were placed in the MatrixSSL fork must move out of MatrixSSL. - `libnwssl` owns the mars-nwe crypto/TLS facade plus the narrow compatibility surfaces needed by FLAIM: OpenSSL-style FTK/network headers and NICI/CCS-style private headers. - OpenSSL-compat headers should live under the `nwssl` include subtree, e.g. `include/nwssl/openssl/*.h`, not as a root-level `include/openssl` directory that could conflict with system OpenSSL headers. - Private FLAIM/NICI compatibility headers should also live under the `nwssl` subtree, e.g. `include/nwssl/private/nici/...`. They are private build compatibility headers, not the public TLS API for normal mars-nwe code. - `smart`, `directory`, and FLAIM should link against `libnwssl` / the `mars_nwe::ssl` target when they need TLS/crypto compatibility. They should not include MatrixSSL headers directly and should not link OpenSSL directly. Current FLAIM import/build direction: - The imported FLAIM tree is kept under `third_party/flaim` and should remain as close to upstream source as practical. Prefer CMake/build glue, include paths, and tiny compile fixes over broad C/C++ rewrites. - The mars-nwe build currently wants `libnwflaimtk`, `libnwflaim`, `libnwflaimsql`, and `libnwxflaim`. XFLAIM is now included even though it is not immediately required, so it stays build-covered. - FLAIM library versions should come from the public headers when those disagree with `configure.ac`, because the headers are the ABI-facing version source in this import. Current expected shared-object versions are: `libnwflaimtk.so.1.2`, `libnwflaim.so.4.62`, `libnwflaimsql.so.6.00`, and `libnwxflaim.so.5.12`. - All installed FLAIM public headers should go below one mars-nwe namespace directory: `include/nwflaim/`. Do not make `xflaim.h` a special `include/nwxflaim/` exception. - FLAIM command-line utilities should be built and installed with `nw`-prefixed binary names, for example `nwflmcheckdb`, `nwflmrebuild`, `nwflmview`, `nwflmdbshell`, `nwflmgigatest`, and the matching `nwxflm...` utilities. - FLAIM tools require curses/ncurses. CMake should report clearly whether curses/ncurses was found and whether the curses-backed tools will be built. - The uploaded `ncurses-stable.tar.gz` is a valid current upstream ncurses/stable source snapshot for local build testing even if the top-level extracted name does not look like a conventional ncurses release tarball. - The CMake conversion should keep translating the old `Makefile.am` source inventories. Recent build fixes added missing result-set sources and fixed XFLAIM tool include ordering so `xflaim/util` code includes the XFLAIM `flaimsys.h` rather than the classic FLAIM one. - Minimal FLAIM C++ compile fixes are acceptable when required by modern compilers, for example replacing pointer assignments/comparisons using character `\0` with `NULL`/null-pointer checks. Keep those patches small and separate from build-system changes where possible. Current local dependency policy for build checks: - Build GDBM locally from the uploaded `gdbm-1.26.tar.gz` when testing in an isolated prefix. - Build ncurses locally from the uploaded `ncurses-stable.tar.gz` when testing FLAIM tools in an isolated prefix. - Use the uploaded `Linux-PAM-1.7.2.tar.xz` for PAM headers if needed, but link against the system PAM library. Do not vendor PAM as a mars-nwe library. - These local dependency builds are for verification; they are not new vendored submodules unless a later explicit import decision says otherwise. When continuing this work, expect more incremental compile/build patches rather than one large redesign patch. Build after each FLAIM/CMake change, record the next concrete compiler/linker error, and keep generated patches per repository or submodule so the user can apply them with `git am` at the correct path. ## Build and test notes Dependencies used during local checks in this conversation: - `gdbm-1.26.tar.gz` - `Linux-PAM-1.7.2.tar.xz` for PAM headers; link against system PAM if present - `ncpfs-master.zip` for the salvage smoke helper client build - `yyjson` under `third_party/yyjson` If CMake finds GDBM but a target still cannot see `gdbm.h`, pass include paths explicitly for local verification, for example: ```sh CFLAGS="-I/path/to/gdbm/include -I/path/to/Linux-PAM-1.7.2/libpam/include" \ cmake -S . -B build cmake --build build --target nwconn ncp_salvage_scan_smoke ncp_salvage_recover_smoke ``` Useful quick checks: ```sh bash -n tests/salvage/salvage_smoke_suite.sh cc -DLINUX -fsyntax-only -Iinclude -Isrc -Ithird_party/yyjson/src src/nwsalvage.c src/namspace.c ``` When server-side code or smoke helper clients change, rebuild both the server and the helper targets so the runtime test is not using stale binaries: ```sh cmake --build build --target nwserv ncpserv cmake --build build --target \ ncp_delete_smoke \ ncp_read_smoke \ ncp_salvage_scan_smoke \ ncp_salvage_recover_smoke \ ncp_salvage_purge_smoke \ afp_entry_id_smoke \ afp_file_info_smoke \ afp_scan_info_smoke \ afp_set_file_info_smoke \ afp_deleted_info_smoke ``` Runtime smoke suites: ```sh tests/salvage/salvage_smoke_suite.sh --out /tmp/mars-salvage-report.txt tests/afp/afp_smoke_suite.sh --out /tmp/mars-afp-smoke.txt ``` The suite streams the report to `--out` while running, so a failure before the end should still leave useful output. It has a manual stale-payload pause: the script prints a `sudo rm -f .../.recycle/...` command; remove that payload in a second shell and press Enter. The next scan should remove the stale sidecar and `grep` `/var/log/mars_nwe/nw.log` for `WARN SALVAGE 87/16 STALE`. Normal NCP reads of `.recycle` or `.salvage` are expected to fail with invalid path. Verify payload data through the visible live file after NCP write or recover, using `ncp_read_smoke`. Treat the final summary (`failures=0`, `ncp_warnings=0`) as the important signal. ### AFP ProDOSInfo storage ProDOSInfo is AFP/NCP per-entry metadata. Store it in the existing nwatalk AFP metadata layer, not in nwarchive/nwxattr directly and not in a parallel DB. The xattr key is `user.org.mars-nwe.afp.prodos-info` via the mars_nwe xattr wrapper name `org.mars-nwe.afp.prodos-info`; it is a raw 6-byte value, analogous to FinderInfo's 32-byte `org.mars-nwe.afp.finder-info`. Salvage captures this as `prodos_info_hex` (12 hex characters) beside `finder_info_hex`. AFP 35/19 Get Macintosh Info On Deleted File returns FinderInfo[32] followed by ProDOSInfo[6] from the Salvage snapshot. The verified smoke value is `010203040506` and the Linux xattr dump should show: ```text user.org.mars-nwe.afp.prodos-info=0x010203040506 ``` ## Latest endpoint audit checkpoint As of patch `0212-docs-audit-namespace-lock-salvage-stubs.patch`, the latest audited endpoint block is the Name Space lock/quota/search/salvage-rights subset of `NCP 0x2222/87` / wire `0x57` in `src/namspace.c`. `nwconn.c` still forwards requestdata starting at the Name Space `SubFunction` byte to `handle_func_0x57()`, and the handler return convention remains unchanged: non-negative values are reply payload lengths, negative values are Completion codes. The previous `87/16`..`87/29` block contains active source cases 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; - `87/29` Get Effective Directory Rights. Disabled source stubs exist for eligible 3.x/4.x metadata gaps from that range: - `87/19` Get NS Information; - `87/23` Query NS Information Format; - `87/25` Set NS Information; - `87/27` Get Name Space Directory Entry. Patch `0212` added the next set of disabled source stubs for eligible 1.x/2.x/3.x and planned-4.x namespace/file gaps that were missing from the active switch range: - `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; - `87/43` Revoke File Handle Rights. These stubs are under `#if 0`, document selector path/request/reply/provider intent, and do not change runtime behavior. `87/44` Update File Handle Rights is NetWare 5.x in the NDK material and was not stubbed under the current scope. The existing `87/26` source slot is still effectively unimplemented and returns the default `0xfb` completion. The next endpoint block can continue with `87/64`..`87/69`, the matching `89` long-name-space family, or another unaudited top-level family such as AFP `0x2222/35`, packet burst `0x2222/97`/`101`, or deeper `0x2222/23` bindery/property/admin subfunction coverage, unless the user requests a specific family first. The next patch number should follow the latest applied patch; after patch `0223`, use `0224`. Retro source-stub checkpoint from patch 0207: - Already documented eligible gaps in Directory Services `22/12`, `22/35`, and `22/36` have disabled source stubs at the correct `src/nwconn.c` dispatch slots. Do not rewrite those stubs unless implementing the endpoint. - Already documented File Server Environment `23` queue/server-management gaps have disabled source stubs at the appropriate `src/nwbind.c` switch slots. Some pre-existing disabled stubs still contain legacy placeholder control flow; leave existing stubs alone unless implementing or explicitly cleaning that exact block. - Message `21/04`..`21/08` were not SDK/PDF server endpoints in the default audit set, so no stubs are required. Message `21/12` is later-generation only and remains prose-only/out-of-scope under the current rules. - Physical-record `26`..`31` plus `110`, TTS `34/00`..`34/10`, and direct file `59`, `61`..`77` do not have additional eligible missing slots in the audited ranges; no new source stubs were needed. - Future retro-audits must distinguish three cases: add a disabled source stub for an eligible missing endpoint, leave an already-present stub unchanged and only document that it exists, or keep non-endpoints / 5.x+ endpoints out of source. Remember: for every new endpoint-audit patch, also update this AI handoff file with the latest audited block and expected next patch number. Put detailed Coverage/Request/Reply/Known-difference notes inline at each endpoint case rather than as one large audit block before the switch range. Missing-endpoint rule: when an audited SDK/PDF/WebSDK/Header endpoint is not implemented but belongs to the compatibility scope, document it at the appropriate dispatch location as a disabled `#if 0` stub instead of only mentioning it in prose. The compatibility scope for stubs is NetWare 1.x/2.x legacy calls, NetWare 3.x/default compatibility calls, and explicitly planned NetWare 4.x/NDS work. Do not add stubs merely for NetWare 5.x/OES/MOAB/newer endpoints: those are outside the current target unless the user explicitly asks for that later generation. A 3.x-compatible server should remain compatible with documented 1.x/2.x calls, and the current forward plan is only through 4.x. Disabled stubs should include selector path, name, request/reply sketch, provider/out-of-scope reason, and no active behavior change. Disabled stubs must not use misleading control flow such as `return(-1)` where that return value has no local handoff meaning. Latest endpoint audit checkpoint from patch 0223: - Direct `NCP 0x2222/111` / wire `0x6f` Semaphore is now source-stub-audited in `src/nwconn.c`. There is no active top-level handler for this newer NetWare 3.x/4.x semaphore family. - Patch `0223` records disabled `#if 0` selector slots for `111/00` Open/Create a Semaphore, `111/01` Examine Semaphore, `111/02` Wait On (P) Semaphore, `111/03` Signal (V) Semaphore, and `111/04` Close Semaphore. - The old `32/xx` semaphore implementation in `src/sema.c` remains the active compatibility path. Future work should bridge both families through one semaphore provider/state table and verify the documented Lo-Hi handle order against existing MARS-NWE big-endian handle helpers before changing behavior. - This block is local synchronization, not `nwnds`/directory work. Next patch number should be `0224`. Latest endpoint audit checkpoint from patch 0224: - SDK `0x2222/90` / wire `0x5a` Data Migration / parse-tree / compression metadata is now source-stub-audited as planned NetWare-4.x filesystem and namespace work. There was no active top-level handler in `src/nwconn.c`. - Patch `0224` records the selector map behind `MARS_NWE_4`: `90/00` Parse Tree, `90/10` Get Reference Count from Dir Entry Number, `90/11` Get Reference Count from Dir Handle, `90/12` Set Compressed File Size, `90/128` Move File Data To DM, `90/129` DM File Information, `90/130` Volume DM Status, `90/131` Migrator Status Info, `90/132` DM Support Module Information, `90/133` Move File Data From DM, `90/134` Get/Set Default Read-Write Support Module ID, `90/135` DM Support Module Capacity Request, `90/136` RTDM Request, and `90/150` File Migration Request. - The future owner is the filesystem/namespace provider, not `nwnds`. There is no active Data Migration support module, parse-tree engine, compressed file-size backend, or RTDM provider yet. Keep this as unsupported `0xfb` unless the filesystem provider grows real backing state. Next patch number should be `0225`. Latest endpoint audit checkpoint from patch 0225: - SDK `0x2222/92` / wire `0x5c` SecretStore is now scope-audited as later-generation and out of the current source-stub target. The NDK PDF marks SecretStore Services as NetWare Server 5.x and eDirectory 8.5 or later, with subverbs `0` Query Server through `9` Get Service Information. - No active top-level `case 0x5c` exists in `src/nwconn.c`, and no indirect handler/provider path was found during this audit. Do not add a disabled source stub for SecretStore while the target remains 1.x/2.x/3.x plus planned 4.x only. - SecretStore is not the same as the planned 4.x `libdirectory`/`nwnds` work. If a future post-4.x/eDirectory target is ever added, it should be designed as a separate secure secret-storage provider with strict no-secret logging rules. Next patch number should be `0226`. Latest endpoint audit checkpoint from patch 0227: - After Accounting, the next relevant block checked was the already-present bindery property/password/set/access portion of SDK `0x2222/23` / wire `0x17`, especially SDK `23/57`..`23/76` in `src/nwbind.c`. - The source already contains per-endpoint comments for the property calls (`23/57`..`23/62`) and the set/password/access calls (`23/63`..`23/76`), including the disabled `23/63` Verify Bindery Object Password stub and the `23/71` note that trustee-path scanning is handled in `nwconn.c`. - Patch `0227` only updates the coverage index: this is no longer a missing-stub/source-change target. Further work in the `23` family should be targeted behavior/security/provider review rather than another broad endpoint-presence pass. Latest endpoint audit checkpoint from patch 0228: - SDK `0x2222/131` / wire `0x83` RPC / server-control is now source-stub-audited as a NetWare-4.x server-control planning family. No active top-level handler exists in `src/nwconn.c`. - Patch `0228` records disabled `MARS_NWE_4` selector slots for `131/01` RPC Load an NLM, `131/02` RPC Unload an NLM, `131/03` RPC Mount Volume, `131/04` RPC Dismount Volume, `131/05` RPC Add Name Space To Volume, `131/06` RPC Set Set Command Value, and `131/07` RPC Execute NCF File. - Future ownership belongs to the `servermgmt`/RPC provider boundary. Do not wire these calls to fake success: the real operations can change server state and the documented reply carries an `RPCccode`. `nwserv` may supervise or register providers, but must not become a data-plane broker for RPC payloads. Latest endpoint audit checkpoint from patch 0231: - SDK `0x2222/123` / wire `0x7b` server information/statistics is now partially source-stub-audited as planned NetWare-4.x server-management work. There is no active top-level handler in `src/nwconn.c`. - Patch `0231` records the first core selector block behind `MARS_NWE_4`: `123/01` Get Cache Information, `123/02` Get File Server Information, `123/03` NetWare File Systems Information, `123/04` User Information, `123/05` Packet Burst Information, `123/06` IPX SPX Information, `123/07` Garbage Collection Information, `123/08` CPU Information, `123/09` Volume Switch Information, `123/10` Get NLM Loaded List, `123/11` NLM Information, `123/12` Get Directory Cache Information, `123/13` Get Operating System Version Information, `123/14` Get Active Connection List by Type, `123/15` Get NLM Resource Tag List, `123/16` Enumerate Connection Information from Connection List, and `123/17` Enumerate NCP Service Network Addresses. - The common SDK 123 request wrapper is `SubFuncStrucLen` Hi-Lo, `SubFuncCode`, `VersionNumber`, `RevisionNumber`, plus selector-specific payload. Replies commonly start with `CurrentServerTime` Lo-Hi, `VConsoleVersion`, `VConsoleRevision`, and reserved fields, then selector-specific structures. - Future ownership belongs to the `servermgmt`/information provider boundary. It should adapt existing mars-nwe/host/transport/filesystem state and must not grow a second management database or return fake success for detailed information that is not modeled. Latest redesign checkpoint from patch 0232: - `REDESIGN.md` now records `nwservermgmt` as a possible future process for the `servermgmt` provider once multiple NetWare-4.x management families become real: `123/xx` server information/statistics, `114/xx` TimeSync adapter, selected `23/200+` console/server-management calls, and guarded `131/xx` RPC server-control requests. - This does not make `nwserv` a data-plane router. `nwserv` remains supervisor, provider registry, and control plane. If `nwservermgmt` exists later, `nwconn` sends normalized handoff requests directly to it; `nwservermgmt` may query `nwserv` only for control-plane state such as provider status/capabilities. - Small static/status calls may stay in-process until a dedicated process is justified. RPC/server-control calls must not fake success and require a real privilege model before activation. Next patch number should be `0233`. Latest endpoint audit checkpoint from patch 0233: - SDK `0x2222/123` / wire `0x7b` server information/statistics now has a second source-stub-audited selector block behind `MARS_NWE_4` in `src/nwconn.c`: `123/20` Active LAN Board List, `123/21` LAN Configuration Information, `123/22` LAN Common Counters Information, `123/23` LAN Custom Counters Information, `123/25` LSL Information, and `123/26` LSL Logical Board Statistics. - This audit was checked against the local NDK/Core Protocols PDF plus the uploaded WebSDK/include `nwfse` material. Patch 0234 corrects the adjacent LAN/LSL coverage by adding the PDF-listed `123/24` LAN Name Information and `123/27` MLID Board Information selector slots. - Future ownership remains the `servermgmt`/information provider boundary, adapting real transport/IPX/adapter/LSL state. Do not synthesize fake LAN boards, expose raw Linux-interface details directly, or route this data plane through `nwserv`; `nwserv` remains supervisor/provider registry/control plane. - Remaining `123/30` and higher Media Manager, volume, protocol-stack, router/SAP, server/set-command, and compression information selectors still need later follow-up auditing. Latest endpoint audit checkpoint from patch 0234: - SDK `0x2222/123` / wire `0x7b` LAN/LSL source-stub coverage now also includes the adjacent local-PDF selectors `123/24` LAN Name Information and `123/27` MLID Board Information behind `MARS_NWE_4` in `src/nwconn.c`. - `123/27` is documented with a NetWare 4.x versus NetWare 5.x reply-layout difference: the current guarded mars-nwe planning scope should model only the 4.x semantics if this slot is later activated. - The earlier note that `123/24` was not listed is superseded by this correction; it was present in the local NDK/Core Protocols PDF even though the uploaded include/WebSDK material surfaced the surrounding `nwfse` structs more clearly. Next patch number should be `0235`. Latest endpoint audit checkpoint from patch 0235: - SDK `0x2222/123` / wire `0x7b` server information/statistics now records the next Media Manager / volume selector run behind `MARS_NWE_4` in `src/nwconn.c`: `123/30` Get Media Manager Object Information, `123/31` Get Media Manager Objects List, `123/32` Get Media Manager Object Children's List, `123/33` Get Volume Segment List, and `123/34` Get Volume Information by Level. - This block was checked against the local NDK/Core Protocols PDF plus the uploaded WebSDK/include `nwfse` material. `123/34` has an internal `InfoLevelNumber` payload selector for the returned volume-information structure; do not treat those levels as separate wire subfunctions. - Future ownership remains the `servermgmt`/information provider boundary, with filesystem/namespace/volume-provider input for real volume/media state. Do not invent a separate NetWare Media Manager database and do not route these data-plane requests through `nwserv`. - Remaining `123/40` and higher protocol-stack, router/SAP, server/set-command, and compression information selectors still need later follow-up auditing. Latest endpoint audit checkpoint from patch 0237: - SDK `0x2222/123` / wire `0x7b` server information/statistics now records the router/SAP/server/source selector run behind `MARS_NWE_4` in `src/nwconn.c`: `123/50` Get General Router and SAP Information, `123/51` Get Network Router Information, `123/52` Get Network Routers Information, `123/53` Get Known Networks Information, `123/54` Get Server Information, `123/55` Get Server Sources Information, and `123/56` Get Known Servers Information. - This block was checked against the local NDK/Core Protocols PDF plus the uploaded WebSDK/include `nwfse` material. PDF/WebSDK/includes jump from `123/56` to the server set-command group at `123/60`; do not invent `123/57`..`123/59` selector slots unless a new primary source is found. - Future ownership remains the `servermgmt`/information provider boundary with IPX/SAP/RIP transport/provider input for real routing and advertised-server state. Do not synthesize fake routers, known networks, SAP server lists, or server-source records, and do not route these read-only data-plane requests through `nwserv`. - Remaining `123/60` and higher server set-command and compression information selectors still need later follow-up auditing. Latest endpoint audit checkpoint from patch 0238: - SDK `0x2222/123` / wire `0x7b` server information/statistics now records the NetWare-4.x server SET query selector run behind `MARS_NWE_4` in `src/nwconn.c`: `123/60` Get Server Set Commands Information and `123/61` Get Server Set Categories. - This block was checked against the local NDK/Core Protocols PDF plus the uploaded WebSDK/include `nwfse` material. The PDF also documents `123/62` Get Server Set Commands Information By Name, but marks it as NetWare 5.x; do not add a source stub for `123/62` under the current through-4.x planning scope unless the target scope changes. - Future ownership remains the `servermgmt`/configuration provider boundary. The SET command/category views should expose real mars-nwe configuration and runtime state once modeled; do not synthesize a fake NetWare SET database or route these read-only data-plane requests through `nwserv`. - Patch 0239 records the final in-scope compression/decompression selector run: `123/70` Get Current Compressing File, `123/71` Get Current DeCompressing File Info List, and `123/72` Get Compression and Decompression Time and Counts. Latest endpoint audit checkpoint from patch 0239: - SDK `0x2222/123` / wire `0x7b` server information/statistics now records the NetWare-4.x compression/decompression information selector run behind `MARS_NWE_4` in `src/nwconn.c`: `123/70` Get Current Compressing File, `123/71` Get Current DeCompressing File Info List, and `123/72` Get Compression and Decompression Time and Counts. - This block was checked against the local NDK/Core Protocols PDF plus the uploaded WebSDK/include `nwfse` material. The PDF/WebSDK/include material jumps from the NetWare-5.x-only `123/62` SET-by-name selector to the compression group at `123/70`; do not invent `123/63`..`123/69` selector slots unless a new primary source is found. - Future ownership remains the `servermgmt`/information provider boundary with filesystem/volume compression state as the source of truth. Do not synthesize fake current-compression files, decompression file lists, or compression byte/tick counters, and do not route these read-only data-plane requests through `nwserv`. - This completes the currently identified in-scope `123/xx` NetWare-4.x server-information/statistics source-stub audit. The next endpoint-audit block should be selected from a different SDK family after rechecking active dispatch and handoff paths. Latest endpoint audit checkpoint from patch 0240: - After completing the `123/xx` SDK server-information audit, the next adjacent source block checked was the disabled `_MAR_TESTS_XX` wire `0x5f` UNIX-client probe in `src/nwconn.c`. It is documented as local/test-only, not an SDK `0x2222/95` endpoint family. - The local NDK/Core Protocols NCP-by-number table does not list a documented `0x2222/95` group, and the original source comment records that a NetWare 4.1 server also did not know this call. Do not promote it to a normal default handler or add compatibility stubs without a real client trace and explicit provider ownership. - The observed disabled branch shape is FunctionCode `0x5f` followed by four unknown bytes, historically seen as `0x10 00 00 00`; its old success reply is not exposed outside `_MAR_TESTS_XX`. Next patch number should be `0241`. Latest endpoint audit checkpoint from patch 0241: - Direction corrected back to NDK-first endpoint selection: choose the next documented NetWare 1.x/2.x/3.x endpoint gap or planned NetWare 4.x endpoint from the local NDK/Core Protocols PDF first, then compare mars-nwe dispatch. Local/test-only source probes such as the disabled wire `0x5f` branch are not endpoint-audit candidates unless an in-scope NDK entry exists. - SDK `0x2222/22` / wire `0x16` directory-services source-stub coverage now records two NDK-first gaps in `src/nwconn.c`: `22/49` Open Data Stream and `22/52` Get Mount Volume List. - `22/49` is a NetWare 3.x/4.x data-stream open endpoint. It remains disabled until the filesystem/namespace/datastream provider can open real alternate data streams and return real file handles; do not synthesize fake stream handles. - `22/52` is a NetWare 4.x mounted-volume-list endpoint. It remains disabled behind `MARS_NWE_4` until mounted-volume and namespace-specific volume-list state is modeled by the servermgmt/information provider with volume-provider input. Do not route this read-only data plane through `nwserv`. Latest endpoint audit checkpoint from patch 0242: - Continuing the corrected NDK-first pass, SDK `0x2222/23` / wire `0x17` File Server Environment now records the NetWare-2.x server statistics block `23/212` through `23/217` as disabled source stubs in `src/nwbind.c`: Get File System Statistics, Get Transaction Tracking Statistics, Read Disk Cache Statistics, Get Drive Mapping Table, Read Physical Disk Statistics, and Get Disk Channel Statistics. - These selectors are reached through the normal `nwconn.c` File Server Environment forward path into `nwbind.c`. There was no active implementation for the wire `0xd4`..`0xd9` subfunction slots before this documentation marker. - Do not synthesize fake NetWare FAT/cache, TTS, SFT mirror, physical-disk, or disk-channel counter blocks. Future ownership belongs to a servermgmt/ statistics provider backed by real filesystem, volume, and backend state. - The next NDK-first `23/xx` statistics/monitoring audit block should continue with the nearby open-file/lock/semaphore/usage selectors such as `23/219` through `23/242`, keeping small reviewable sub-blocks. Latest endpoint audit checkpoint from patch 0243: - Continuing the corrected NDK-first pass, SDK `0x2222/23` / wire `0x17` File Server Environment now records the NetWare-2.x/3.x legacy monitor scan block `23/219` through `23/226` as disabled source stubs in `src/nwbind.c`: Get Connection's Open Files (old), Get Connection Using A File (old), Get Physical Record Locks By Connection And File (old), Get Physical Record Locks By File (old), Get Logical Records By Connection (old), Get Logical Record Information (old), Get Connection's Semaphores (old), and Get Semaphore Information (old). - These selectors are reached through the normal `nwconn.c` File Server Environment forward path into `nwbind.c`. There was no active implementation for the wire `0xdb`..`0xe2` subfunction slots before this documentation marker. - Do not synthesize fake open-file, file-user, physical-lock, logical-lock, or semaphore lists from partial state. Future ownership belongs to servermgmt/ statistics with real file-handle, byte-range-lock, logical-lock, and semaphore provider input. - The next NDK-first `23/xx` statistics/monitoring audit block should continue with the nearby LAN-driver, connection-usage, disk-space, LAN-I/O, misc/volume, and newer open-file/lock/semaphore selectors such as `23/227`, `23/229`..`23/242`, keeping the patch scope small. Next patch number should be `0244`. Endpoint audit formatting requirement from patch 0244: - Disabled source stubs for audited NDK endpoints must not group multiple selectors under one shared explanatory block. Each `switch` `case` must be documented as its own case. - Active fall-through handlers do not need control-flow rewrites only for documentation. It is acceptable to keep adjacent `case` labels sharing one handler, as long as each label has its own adjacent concise `Request:` and `Response:` summary before the shared implementation block. - Each audited case comment must include a concise `Request:` summary and a concise `Response:` summary from NDK/PDF/WebSDK/include sources. - Keep provider ownership and "do not fake" constraints in the same case block when relevant, so future implementers do not need to infer requirements from a surrounding grouped comment. - Endpoint selection remains NDK-first: NetWare 1.x/2.x/3.x plus planned 4.x; ignore 5.x+ only endpoints unless the project scope is explicitly changed. - Final verification snippets should show only the new patch, using `git am patchname.patch` with no path prefix. Latest endpoint audit checkpoint from patch 0244: - Corrects the previously applied `23/212` through `23/217` and `23/219` through `23/226` source stubs in `src/nwbind.c` from grouped cases into one documented disabled case per selector. - The request/response details are now adjacent to each wire case: `0xd4` through `0xd9` for statistics and `0xdb` through `0xe2` for old monitor scan calls. - The next NDK-first `23/xx` audit block can continue with the nearby LAN-driver, connection-usage, disk-space, LAN-I/O, misc/volume, and newer open-file/lock/ semaphore selectors such as `23/227`, `23/229`..`23/242`. Next patch number should be `0245`. Latest endpoint audit checkpoint from patch 0245: - Continued the NDK-first File Server Environment pass with `23/227` and `23/229` through `23/236` at wire `0xe3` and `0xe5` through `0xec`. `23/228` is not listed in the NDK table and no wire `0xe4` marker was added. - Added/split individual disabled `src/nwbind.c` cases for LAN driver configuration, connection usage statistics, object remaining disk space, LAN I/O statistics, file-server misc information, volume information, connection task information, connection open files, and connection-using-a-file scans. - The old grouped `23/232`/`23/235` placeholder is gone. Each audited selector now has its own case-local `Request:` and `Response:` summary. - Do not implement these from approximations. They need real LAN binding, NCP byte/request counter, bindery quota, volume/free-space, routing/LAN I/O, server memory/utilization, volume-table, task/lock-wait, open-file/share/deny, and file-user provider state. Next patch number should be `0246`. Latest endpoint audit checkpoint from patch 0246: - Continued the NDK-first File Server Environment pass with the newer NetWare 3.x/4.x monitor selectors `23/237` through `23/242` at wire `0xed` through `0xf2`: physical record locks by connection/file, physical record locks by file, logical records by connection, logical record information, connection semaphores, and semaphore information. - Each selector is documented as its own disabled `#if 0` `src/nwbind.c` case with a case-local `Request:` and `Response:` summary, matching the post-0244 endpoint-audit formatting rule. - These endpoints must not be implemented from approximations. They require real byte-range lock state, namespace/data-stream mapping, logical-record lock/log state, and semaphore open/value/wait provider state. - The next NDK-first `23/xx` pass should skip unlisted gaps and continue with the next documented NetWare 1.x/2.x/3.x selector or planned 4.x selector after `23/242`. Next patch number should be `0247`. Latest endpoint audit checkpoint from patch 0247: - Continued the NDK-first File Server Environment pass after `23/242` by skipping the already implemented `23/243` Map Directory Number to Path and `23/244` Convert Path to Dir Entry helpers, then tightening the existing disabled `23/253` and `23/254` tail cases in `src/nwbind.c`. - `23/253` / wire `0xfd` Send Console Broadcast now has a case-local Request summary for NumberOfStations, StationList long[] and BroadcastMessage, plus a Response summary covering status-only success/error returns. - `23/254` / wire `0xfe` Clear Connection Number now has a case-local Request summary for the long ConnectionNumber variant and a Response summary covering status-only success/error returns. - These endpoints must not be implemented from approximations. They require real console/supervisor privilege checks, broadcast disabled/delivery state, valid target connection handling, and full logout/resource-release semantics. - The next NDK-first pass should continue outside this `23/xx` tail with the next documented NetWare 1.x/2.x/3.x endpoint or planned 4.x endpoint, while skipping unlisted gaps and ignoring 5.x-only endpoints. Next patch number should be `0248`. Latest endpoint audit checkpoint from patch 0248: - Continued NDK-first outside the `23/xx` tail with the in-scope Transaction Tracking System family `34/00` through `34/10` in `src/nwconn.c`. - Replaced the old grouped TTS documentation block with an explicit `switch (ufunc)` so every NDK selector has its own `case` and adjacent `Request:`/`Response:` summary: `34/00` availability, `34/01` begin, `34/02` end, `34/03` abort, `34/04` status, `34/05`/`34/06` application thresholds, `34/07`/`34/08` workstation thresholds, and `34/09`/`34/10` transaction control bits. - Runtime behavior is preserved: `34/00` reports TTS unavailable and all other TTS selectors return `0xfb`. Do not return synthetic success without real transaction files, transaction status tracking, lock integration, threshold state, control-bit state, and rollback/backout logic. - The next NDK-first pass should continue with the next documented NetWare 1.x/2.x/3.x endpoint or planned 4.x endpoint after the TTS family, skipping unlisted gaps and ignoring 5.x-only endpoints. Next patch number should be `0249`. Latest endpoint audit checkpoint from patch 0249: - Continued NDK-first after the TTS family with the in-scope AFP/Mac namespace family `35/01` through `35/19` in `src/nwconn.c`. The NDK lists these AFP calls for NetWare 2.x/3.x/4.x, so they remain relevant even though the same pages also mention 5.x. - Converted the AFP dispatcher from grouped `if`/`else` pairs into an explicit `switch (ufunc)` with one case per NDK selector: create directory/file, delete, entry-ID lookup by name/handle/path, rename, open file fork, get/set/scan file information, AFP 2.0 create/get/set/scan variants, DOS-name lookup, and deleted-file Macintosh-info lookup. - Runtime behavior is unchanged. Some selectors still share the same helper, but each selector now has its own case-local `Request:` and `Response:` summary matching the endpoint-audit rule. Do not regroup these cases in a later cleanup. - Future AFP work must keep stable AFP entry IDs/CNIDs, FinderInfo/ProDOSInfo, data/resource fork identity, directory enumeration state, and Salvage metadata grounded in real provider state. Do not fake AFP replies from plain Unix path names when the NDK requires namespace identity or metadata persistence. - The next NDK-first pass should continue with the next documented NetWare 1.x/2.x/3.x endpoint or planned 4.x endpoint after the AFP family, skipping unlisted gaps and ignoring 5.x-only endpoints. ## 2026-06-02 - Patch 0250 NCP Extension selector notes 36/00..06 and 37 - Continued NDK-first after AFP with the NetWare-4.x planned-scope NCP Extension family: `0x2222/36` selectors `36/00` through `36/06`, plus `0x2222/37` Execute NCP Extension. - The source already carried an explicit `switch` for the NCP Extension selectors. Patch `0250` tightens each selector-local comment so every case has concrete NDK Request/Response fields rather than a generic extension summary: - `36/00` Get NCP Extension Information old - `36/01` Get NCP Extension Maximum Data Size - `36/02` Get NCP Extension Information by Name - `36/03` Get Number of Registered NCP Extensions - `36/04` Get NCP Extension Registered Verbs List - `36/05` Return NCP Extension Information - `36/06` Return NCP Extension Maximum Data Size - `37` Execute NCP Extension - Runtime behavior is unchanged: all extension-registration and execution requests still return `0xfb` until a real extension registry/provider exists. - Future NCP Extension work must model a real registered-extension table, version/name/custom-data records, maximum data-size policy, registered verb enumeration, and provider-owned execute payload dispatch. Do not route extension payloads through `nwserv` as a generic data-plane broker. - Continue NDK-first with the next documented NetWare 1.x/2.x/3.x endpoint or planned 4.x endpoint after the NCP Extension family, skipping 5.x-only NDS unless explicitly brought into scope. ## 2026-06-02 - Patch 0251 old direct create-file selector split 67/77 - Continued NDK-first after the NCP Extension checkpoint by returning to the in-scope old direct file-I/O calls in `src/nwconn.c`. The NDK lists both `0x2222/67` Create File and `0x2222/77` Create New File for NetWare 2.x/3.x/4.x, so they remain relevant even though the same pages also mention 5.x. - Split the old grouped `case 0x43` / `case 0x4d` implementation into two explicit case bodies. Each case now has its own adjacent `Request:` and `Response:` notes: - `67` / wire `0x43` Create File: replace-if-existing semantics when the caller has sufficient create/delete rights. - `77` / wire `0x4d` Create New File: no-replace semantics; fail if the target already exists. - Runtime behavior is intentionally unchanged. Both cases still use the existing `nw_creat_open_file()` path and return the old six-byte file-handle plus `NW_FILE_INFO` reply layout, but they no longer rely on a grouped case label or a `function == 0x43` mode selector inside a shared block. - Do not regroup these two direct create-file cases in a later cleanup; keep the per-case Request/Response audit rule intact. ## 2026-06-02 - Patch 0252 SDK 90 tree/reference/compression selector notes - Continued NDK-first after the direct create-file split. The NDK Enhanced NCP `89/xx` chapter is not taken as the next implementation target here because the `89/01` page is marked `NetWare Servers: 6.5, SP2 and later`; keep those 5.x+/6.x-only enhanced namespace endpoints out of this 1.x-4.x audit unless project scope changes. - Audited the first NetWare-4.x-relevant SDK `90/xx` block in `src/nwconn.c`: - `90/00` Parse Tree - `90/10` Get Reference Count from Dir Entry Number - `90/11` Get Reference Count from Dir Handle - `90/12` Set Compressed File Size - Each selector already had its own `switch` case; patch `0252` tightens those case-local comments with exact NDK `SubFuncStrucLen`, request fields and response fields. - Runtime behavior remains unchanged: all four selectors still return `0xfb` until a real namespace tree/reference-count/compression metadata provider exists. - Do not synthesize reference counts or compressed-size replies from partial Unix `stat(2)` state. These replies require NetWare directory-base identity, namespace handles, reference tracking and compression metadata. Next patch number should be `0253`. ## 2026-06-02 - Patch 0253 SDK 90 data-migration selector notes - Continued NDK-first after the first SDK `90/xx` tree/reference/compression selector pass with the planned NetWare-4.x Data Migration selector block in `src/nwconn.c`: - `90/128` Move File Data To DM - `90/129` DM File Information - `90/130` Volume DM Status - `90/131` Migrator Status Info - `90/132` DM Support Module Information - `90/133` Move File Data From DM - `90/134` Get/Set Default Read-Write Support Module ID - `90/135` DM Support Module Capacity Request - `90/136` RTDM Request - `90/150` File Migration Request - Each selector already had its own `switch` case. Patch `0253` tightens the case-local comments with exact NDK `SubFuncStrucLen`, request fields, and response fields so the Data Migration block follows the current endpoint audit rule. - Runtime behavior remains unchanged: all Data Migration selectors still return `0xfb` until a real filesystem/data-migration provider exists. - Do not fake Data Migration replies from ordinary Unix file metadata. These endpoints require NetWare volume/directory-entry identity, namespace-aware migrated-file state, support-module registration, capacity accounting, migrator status, RTDM verbs, and file-migration attribute persistence. ## 2026-06-02 - Patch 0254 TimeSync selector split 114/01..12 - Continued NDK-first after SDK `90` Data Migration with the planned NetWare-4.x Time Synchronization family in `src/nwconn.c`: - `114/01` Timesync Get Time - `114/02` Timesync Exchange Time - `114/05` Timesync Get Server List - `114/06` Timesync Set Server List - `114/12` Timesync Get Version - The source already had selector coverage behind `MARS_NWE_4`, but the cases were grouped with fall-through to one shared unsupported return. Patch `0254` splits them so each selector has its own `case`, own `Request:` summary, own `Response:` summary, and own `0xfb` return. - Runtime behavior remains unchanged: TimeSync remains unsupported until a real server-management/time provider exists. - Do not emulate the NDK note that `114/06` returns success in all cases until there is an explicit TimeSync compatibility policy and real server-list state. ## 2026-06-02 - Patch 0255 RPC selector split 131/01..07 - Continued NDK-first after Time Synchronization by revisiting the planned NetWare-4.x RPC/server-control family in `src/nwconn.c`: - `131/01` RPC Load an NLM - `131/02` RPC Unload an NLM - `131/03` RPC Mount Volume - `131/04` RPC Dismount Volume - `131/05` RPC Add Name Space To Volume - `131/06` RPC Set Set Command Value - `131/07` RPC Execute NCF File - The source already had selector coverage behind `MARS_NWE_4`, but the cases were grouped through fall-through to one shared unsupported return. Patch `0255` splits them so each selector has its own `case`, own `Request:` summary, own `Reply:` summary, and own `0xfb` return. - Runtime behavior remains unchanged. RPC/server-control remains unsupported until a real server-management/RPC provider exists. - Do not fake RPC success. These calls can load/unload NLMs, mount/dismount volumes, add name spaces, change SET commands, and execute NCF files; they require supervisor-equivalent authentication, real provider state, and documented `RPCccode` mapping. - Keep `nwserv` as control-plane supervisor/registry only; do not route these RPC payloads through `nwserv` as a generic data-plane broker. ## 2026-06-02 - Patch 0256 Physical-record selector notes without control-flow split - Continued NDK-first after RPC/server-control with the implemented physical record lock family in `src/nwconn.c`: - `26` Log Physical Record (old) - `27` Lock Physical Record Set (old) - `28` Release Physical Record - `29` Release Physical Record Set - `30` Clear Physical Record - `31` Clear Physical Record Set - `110` Lock Physical Record Set - Patch `0256` is documentation-only and intentionally keeps the existing fall-through handler structure. Adjacent cases may remain adjacent when they share parser/handler logic; the requirement is that each wire case has its own nearby `Request:` and `Response:` notes, not that active control flow be split for documentation. - Keep the known parser audit notes unchanged: old `27` is documented as Lo-Hi timeout while the shared handler reads Hi-Lo, and the current LockFlag mapping differs from the NDK/Core-Protocols text until real requester traces justify a behavior change. ## 2026-06-02 - Patch 0257 Clear Lock Wait Node stub 112 - Continued NDK-first after the implemented physical-record family with the direct NetWare-3.x/4.x asynchronous-lock cleanup endpoint: - `112` Clear Lock Wait Node - Patch `0257` adds a disabled source stub in `src/nwconn.c` for wire `0x70`. The stub records the NDK request as `FunctionCode=112` plus a `WaitNode` structure and the response as completion-only: success, `ERR_LOCK_WAITING`, or lock error. - The endpoint must not fake success from the current synchronous lock tables. It requires real asynchronous wait-node state allocated by Log/Lock File, Logical Record, and Physical Record async requests (`105` through `110`). - This is synchronization/lock-provider state, not server-management or directory state. ## 2026-06-02 - Patch 0258 async synchronization direct stubs 105/107/108/109 - Continued NDK-first after Clear Lock Wait Node with the missing direct asynchronous synchronization endpoints in `src/nwconn.c`: - `105` / wire `0x69` Log File (old) - `107` / wire `0x6b` Log Logical Record - `108` / wire `0x6c` Lock Logical Record Set - `109` / wire `0x6d` Log Physical Record - These are NetWare-3.x/4.x-relevant endpoints. The NDK also lists 5.x, but this audit keeps only the 3.x/4.x contract. - Patch `0258` adds disabled source stubs only. Runtime behavior is unchanged. - Do not map these direct async-capable calls onto the existing old synchronous handlers (`03`, `09`, `10`, `26`) or namespace handlers (`87/36`, `87/67`) without a real provider design. The request encodings and async wait-node semantics differ. - These calls share state requirements with `112` Clear Lock Wait Node: pending lock allocation, async wait-node lifetime, and correct completion-code mapping. ## 2026-06-02 - Patch 0259 fall-through synchronization selector notes - Continued NDK-first after the direct async synchronization stubs by tightening the implemented old file/logical synchronization fall-through handlers in `src/nwconn.c`: - `04` Lock File Set (old) and `106` Lock File Set - `05` Release File (old) and `07` Clear File (old) - `06` Release File Set and `08` Clear File Set - `11` Clear Logical Record and `12` Release Logical Record - `14` Clear Logical Record Set and `13` Release Logical Record Set - This is documentation-only. The active fall-through control flow remains unchanged: shared parser/handler branches stay shared, but each wire `case` label now has its own nearby `Request:` and `Response:` notes. - Keep the parser audit items unchanged: old `04` documents Lo-Hi timeout while the shared handler uses `GET_BE16()`, and the set release/clear handlers for file and logical records still ignore the documented `LockFlag` byte until direct requester traces justify changing behavior. ## 2026-06-02 - Patch 0260 final NDK/WebSDK/include endpoint-audit closure - Re-ran the endpoint-audit inventory NDK-first against the local Core Protocols PDF text, uploaded WebSDK HTML, and uploaded SDK includes after patches `0255` through `0259`. - No additional in-scope NetWare 1.x/2.x/3.x endpoint family or planned NetWare-4.x endpoint family was found that still needs a new source-dispatch stub in this documentation pass. - Current coverage state is considered documentation-complete for this audit: each in-scope family is either actively handled, forwarded to the file that parses it, represented by a disabled source stub with request/reply notes, or explicitly documented as out of scope because it is NetWare 5.x/OES/MOAB/newer or requires a future provider. - This does not mean all endpoints are behaviorally complete. It only closes the NDK/WebSDK/include source-stub inventory. Remaining work should be driven by tests, requester traces, and provider implementation tasks, not by adding more placeholder endpoint stubs. - Keep using the corrected documentation rule from patches `0256` and `0259`: do not split active fall-through control flow merely for documentation; instead keep shared parser/handler branches shared and place the appropriate `Request:`/`Response:` notes next to the relevant case labels. ## 2026-06-02 - Patch 0261 source/header subtree layout rules - Documented the planned large-source-file split as a module-subtree layout, not a semantic provider change. Source files should move under `src//` while headers mirror the same hierarchy under `include//`. - Keep ownership names explicit: `nwconn` code stays under `src/nwconn/`, `nwbind` code under `src/nwbind/`, `nwqueue` code under `src/nwqueue/`, `nwnds` code under `src/nwnds/`, and directory code under `src/nwdirectory/`. - Flat headers remain umbrella headers. For example, `include/nwbind.h` should include public headers from `include/nwbind/*.h`; do the same later for `nwconn.h`, `nwqueue.h`, `nwnds.h`, and `nwdirectory.h`. - Private implementation headers should be named `include//internal.h` and may only be included by files in the matching `src//` subtree. - Mechanical move/split patches must not change runtime behavior and must not be combined with endpoint semantics, provider IPC changes, or switch cleanup. - Start with build-system support for `src//*.c` plus `include//*.h`, then move smaller modules such as `nwdirectory` before splitting very large files such as `nwconn.c` and `nwbind.c`. ## 2026-06-02 - Patch 0262 libowfat hard dependency policy - Reviewed the uploaded `libowfat-0.34.tar.xz` archive as the dependency used by tinyldap-style code. Its README states that libowfat provides general purpose APIs extracted from Dan Bernstein's software and reimplemented under GNU GPL version 2 only, with no later-version grant. - Treat libowfat as a planned hard third-party dependency for the tinyldap-derived `mars-tinyldap`/`nwdirectory` work, similar to how yyjson is a required bundled dependency for salvage metadata. - The planned import path is `third_party/libowfat`. Do not keep it merely as a reference archive and do not place it at the repository root. - The pinned initial source should be libowfat 0.34 unless a later explicit dependency bump patch chooses a different version. The import must carry a mars-nwe note documenting source/version, GPL-2.0-only license, local CMake changes, and how `mars-tinyldap`/`nwdirectory` links it. - The first integration should expose a normal CMake target, for example `OWFAT::owfat`, and should be usable from both standalone `mars-tinyldap` and the mars-nwe superbuild. Do not wrap libowfat's original Makefile as the long-term build path. - Scope the first direct libowfat dependency to the tinyldap-derived directory-service build so the initial import remains reviewable. - It is also acceptable for mars-nwe core code to use libowfat later when a concrete call site benefits from it, for example `byte`, `buffer`, `fmt`, `scan`, `stralloc`, `uint`, `socket`, or `io` helpers. Do that deliberately in follow-up patches with an explicit consumer and without scattering convenience includes through unrelated dispatch code. - Prefer a small mars-nwe facade when multiple modules need the same libowfat helper pattern, but do not invent wrappers merely to hide a useful hard dependency. - Keep GPLv3 code out of this dependency path. ## 2026-06-02 - Patch 0263 libowfat consumer scope clarification - Relaxed the `0262` wording that made libowfat sound restricted to only tinyldap/nwdirectory compatibility code. - libowfat remains a hard bundled GPL-2.0-only dependency under `third_party/libowfat`, exposed as `OWFAT::owfat`. - The first consumer should still be the tinyldap-derived `mars-tinyldap` / `nwdirectory` work, but mars-nwe core code may use libowfat later when the helper is technically useful and the patch names the concrete consumer. - Keep direct includes deliberate: do not add libowfat to unrelated switch dispatch code only because it is available, and prefer a small mars-nwe facade if several modules need the same helper pattern. ## 2026-06-02 - Patch 0264 GPL-2.0-only source/header normalization - Normalize mars-nwe-owned `.c` and `.h` files to GPL-2.0-only. Existing GPL-2-or-later text should be rewritten to version 2 only, and files without a license header should gain a project header. - C/header files should carry `SPDX-License-Identifier: GPL-2.0-only` at the top. - Preserve/restore copyright attribution for Martin Stover and add current maintenance attribution for Mario Fetka where missing. - Root `COPYING` should state the project-level GPL-2.0-only policy before the full GNU GPL version 2 text. - `README` and `README.md` should describe the GPL-2.0-only policy and point to `COPYING`. - Do not introduce GPLv3-or-later wording in mars-nwe-owned source/header files or dependency documentation unless a separate explicit relicensing decision is made. ## 2026-06-02 - Patch 0265 MatrixSSL fork/CMake policy - MatrixSSL is now the preferred GPL-2.0-compatible crypto/TLS candidate to evaluate for the FLAIM CCS/NICI compatibility layer and possible future TLS needs, instead of pulling OpenSSL into the tree. - Treat MatrixSSL as a mars-nwe-maintained fork/import under `third_party/matrixssl`, not as an opaque system probe and not as a source tree built by its original Makefiles. - The import must document the exact upstream/fork URL, revision, license terms, any local patches, and the reason it is GPL-2.0-compatible with mars-nwe. - Add a native CMake build in the MatrixSSL fork. It must work standalone and as a mars-nwe subdirectory, and should expose normal targets such as `MATRIXSSL::crypto` and, if TLS is built, `MATRIXSSL::tls`. - FLAIM must not call MatrixSSL directly. FLAIM still talks to the future CCS/NICI compatibility layer; that layer may use MatrixSSL crypto primitives underneath. - Keep old OpenSSL-facing FLAIM/FTK code disabled by default. Do not introduce OpenSSL as a default mars-nwe dependency. - Do not mix MatrixSSL import/CMake work with FLAIM CCS/NICI implementation or source tree layout changes in the same patch. ## 2026-06-02 - Patch 0266 shared library layering for MatrixSSL, FLAIM, and directory services - The third-party storage/crypto plan now uses mars-nwe-named shared library layers, not raw upstream target names as public project interfaces. - `libnwmatrixssl` is the patched MatrixSSL fork/library. It exists only to make the GPL-2.0-compatible MatrixSSL source build cleanly under mars-nwe CMake and to avoid collisions with any system MatrixSSL package. Keep local changes limited to portability, naming, CMake, and build hygiene unless a later security/compatibility patch explicitly says otherwise. - `libnwssl` is the mars-nwe SSL/crypto facade. It owns the MatrixSSL-facing wrappers, future TLS abstraction used by apps/services, and the CCS/NICI compatibility layer that FLAIM needs. Application code should include/use `libnwssl`, not raw MatrixSSL headers. - `libnwflaimtk` and `libnwflaim` are the renamed mars-nwe FLAIM libraries built from the imported FLAIM sources. The rename is intentional so mars-nwe never accidentally links against, or conflicts with, a system `libflaim`/FTK install. - `libnwdirectory` is the directory abstraction library above the FLAIM store. It is the API used by `nwdirectory`, future `nwnds`, setup/import tooling, and later Bindery/NDS integration; those consumers should not call `libnwflaim` directly. - Keep the layering explicit: ```text apps/services/setup/nwnds -> libnwdirectory -> libnwflaim -> libnwflaimtk -> libnwssl CCS/NICI -> libnwmatrixssl apps/services TLS -> libnwssl TLS -> libnwmatrixssl ``` - FLAIM source import, MatrixSSL fork/CMake work, `libnwssl` facade work, CCS/NICI implementation, and `libnwdirectory` API work should remain separate patches. ## 2026-06-02 - Patch 0267 libnwssl FLAIM OpenSSL-compat boundary - The inspected `flaim-code-r1112-trunk` uses OpenSSL-style APIs only in the FTK network/TLS helper code, not as the primary FLAIM database-at-rest encryption API. FLAIM storage encryption still goes through NICI/CCS-style `CCS_*` calls. - `libnwssl` should therefore own two separate compatibility surfaces: - a CCS/NICI compatibility API for FLAIM encrypted storage, backed by `libnwmatrixssl` crypto primitives; and - a narrow OpenSSL-compatibility facade for the legacy FLAIM/FTK network code, backed by `libnwmatrixssl` TLS/crypto when that code cannot be disabled. - Do not expose OpenSSL-compatible types outside the FLAIM/FTK import boundary. If wrappers are needed, they should be private to `libnwssl` plus the `libnwflaimtk` build glue. - The FTK OpenSSL-compat surface should be limited to the symbols actually seen in r1112 (`SSL_*`, `SSL_CTX_*`, `BIO_*`, `X509_*`, `EVP_PKEY_*`, and error initialization helpers). Do not implement a general OpenSSL replacement API unless a later source audit proves it is required. - Keep the FLAIM network/TLS compatibility path separate from mars-nwe LDAP, provider IPC, and application TLS policy. Those consumers use the native `libnwssl` TLS facade, not the OpenSSL-compat shim. ## 2026-06-02 - Patch 0268 third-party compat-header boundary - Keep imported third-party code as third-party code. FLAIM, MatrixSSL, and libowfat imports may receive build fixes, CMake integration, portability fixes, local library naming, and documented minimal compatibility fixes, but they must not grow mars-nwe-specific public APIs or be edited merely to call mars-nwe wrappers directly. - Prefer include-path compatibility over source edits for old FLAIM dependencies: `libnwssl` should provide private compatibility headers under `include/nwssl/private/`, for example: - `include/nwssl/private/nici.h` for NICI/CCS declarations expected by FLAIM; and - `include/nwssl/private/openssl/*.h` for the narrow OpenSSL-style headers required by the FTK network/TLS code. - The `libnwflaimtk`/`libnwflaim` CMake targets may add `include/nwssl/private` to their private include path so legacy includes such as `` resolve to the `libnwssl` compatibility headers without patching FLAIM call sites. - The compatibility headers are private to the FLAIM build. mars-nwe modules, LDAP, provider IPC, `nwconn`, `nwbind`, and `libnwdirectory` consumers must use the normal `libnwssl` and `libnwdirectory` public headers instead. - MatrixSSL remains a renamed third-party backend producing `libnwmatrixssl` and must not expose mars-nwe-specific APIs. `libnwssl` owns the public TLS/crypto facade and bridges to MatrixSSL underneath. - libowfat remains a renamed/bundled hard dependency with its own mars-nwe build target/library, including the planned `libnwowfat` shared library name. Keep libowfat changes limited to import/build/CMake/portability work in the same spirit as MatrixSSL and FLAIM. ## 2026-06-05 - Current handoff for next chat: redesign + FLAIM/directory storage track This section is the current working handoff for the next mars-nwe chat. It is newer than the old patch-number notes above. If the user starts a fresh chat, ask for the current bundles/commits of all submodules first and rebuild the tree from those, because the live work has moved beyond the old `0269` documentation line. Current repositories used in this work: - `mars-nwe`: `https://gitea.disconnected-by-peer.at/mars_nwe/mars-nwe` - `mars-flaim`: `https://gitea.disconnected-by-peer.at/mars_nwe/mars-flaim` There are now two separate workstreams. Keep patches and tests separated by workstream. ### Workstream A: mars-nwe redesign of existing code Goal: make the existing mars-nwe codebase more future-proof without doing a big rewrite. Near-term first redesign task: - introduce small enum/type layers before moving logic; - reduce magic strings / magic numbers at provider and directory boundaries; - centralize string-to-enum mapping at the edges; - add smoke/CTest coverage for known mappings; - do not move large chunks of logic in the first enum patch. Likely first targets: - operation/request enums for internal handoff/provider dispatch; - directory/NDS object and attribute identifiers once the real NetWare 4.11 schema is available; - typed config/setup enums for future `nwsetup`. Keep the redesign direction from `REDESIGN.md`: `nwserv` is control plane and provider registry, not a data-plane payload broker; `nwconn` owns client reply envelopes; providers/modules get clearer boundaries over time. ### Workstream B: vendored infrastructure for future directory/storage rewrite Today’s integrated infrastructure work is not the redesign itself. It prepares the replacement of old ad-hoc/self-built functions and flat-file directory storage with maintained, namespaced libraries: - `libnwowfat` - `libnwsodium` - `libnwmatrixssl` - `libnwssl` - `libnwflaimtk`, `libnwflaim`, `libnwxflaim` - `libnwdirectory` / `nwdirectory` from the tinyldap-derived tree Namespace policy: - historical mars-nwe programs keep their established names: `nwserv`, `ncpserv`, `nwclient`, `dbmtool`, `ftrustee`; - vendored/system-colliding libraries, headers, CMake packages, and imported helper tools use the `nw` namespace/prefix; - TinyLDAP/directory tools and FLAIM/XFLAIM tools install with `nw` prefixes; - vendored headers stay below namespaced include directories such as `nwcore/`, `nwssl/`, `nwflaim/`, `nwmatrixssl/`, `nwsodium/`, `nwlibowfat/`, and `nwdirectory/`. FLAIM/MatrixSSL/NWSSL status at this handoff: - MatrixSSL is built as `libnwmatrixssl` and must export CPU/compiler feature options such as AES flags to consumers so `PSCRYPTO_CONFIG` matches between library and consumer. - `yyjson` is built into `libnwcore`; public header is installed under `include/nwcore/yyjson.h`. - `nwssl` owns OpenSSL-compat headers under `include/nwssl/openssl/*.h` and private NICI/CCS headers under `include/nwssl/private/nici/*.h`. - The temporary OpenSSL-compat code was removed from MatrixSSL; OpenSSL-style compatibility belongs in `nwssl`, not MatrixSSL. - `nwssl` now has a functional NICI/CCS compatibility layer used by classic FLAIM at-rest encryption. - NICI support must be scoped to classic FLAIM targets only. Do not define `FLM_USE_NICI` globally for XFLAIM; XFLAIM has a different NICI path and will not compile against the classic FLAIM compat API. - FLAIMSQL remains experimental and default-OFF. Do not make the default build depend on `libnwflaimsql`; keep SQLFLAIM work separate. - FLAIM is currently required only when directory support is enabled. Current green tests at the end of the 2026-06-05 session: ```sh ctest -L nwflaim --output-on-failure # nwflaim.database.create-and-check ... Passed ctest -L flaim --output-on-failure # nwflaim.database.create-and-check ......... Passed # mars_nwe.flaim.api-create-query-encrypt ... Passed # mars_nwe.xflaim.api-alloc ................. Passed ``` These tests confirm: - FLAIM tools can create and check a database; - mars-nwe can use classic FLAIM API from the root test tree; - classic FLAIM at-rest encryption works through `nwssl` NICI/CCS compat; - XFLAIM still builds/runs its allocation smoke test without the incompatible classic NICI path. Known important FLAIM fixes from this session: - GigaTest final rate calculation had a divide-by-zero/SIGFPE when elapsed time was zero; this was fixed in `mars-flaim` source, not hidden in CTest. - FLAIM dictionary add path needed to treat missing dictionary-name lookup EOF as no-conflict. - FLAIM base64 key decode needed to treat EOF after successful decode as successful completion. - FLAIM EncDef test dictionary syntax: `encdef` is valid on index definitions; encrypted data fields in the root API test are created by adding an EncDef dictionary record and using the API with that EncDef ID, not by putting `encdef` below a field record. Planned directory/storage direction: - tinyldap/nwdirectory currently has flat-file/mmap storage. Long term it should write through `libdirectory -> libnwflaim`, not directly to flat files. - At-rest encryption was tested hard now because the future directory store will contain keys, password verifiers, and other sensitive objects. - When the user extracts the real NetWare 4.11 Directory/NDS schema, use it as truth rather than inventing schema by hand. Important data to capture: object classes, numeric IDs if available, attributes, syntax types, single/multi-value flags, mandatory/optional attributes, naming attributes, inheritance/superclasses, and index expectations. Useful future TinyLDAP/Directory tests: - initialize an empty directory database; - add organization/container/user/group objects; - authenticate a user/password; - ensure password/secret material is not plaintext in the FLAIM files; - close/reopen and verify all objects still exist; - duplicate-name/object conflict handling; - rename/move/delete object behavior; - group membership add/remove lookup; - indexed lookup for common attributes; - schema validation once the real NetWare 4.11 schema is available. Future `nwsetup` direction: - Add a curses/ncurses `nwsetup` tool after the directory foundation exists. - It should mimic the NetWare setup flow from installation phase 2 enough to provision a mars-nwe directory: tree/server/org/O/user/admin password, defaults, config files, and initial storage. - `nwsetup` should write only hashes/verifiers/sealed keys to the store; no reusable plaintext passwords in config. - The user referenced the NetWare 6.5 Proxmox installation article as UI/setup inspiration, not as an implementation dependency. When tomorrow’s chat starts, ask the user for the current bundles of `mars-nwe` and all submodules, then rebuild a clean tree before producing new patches. Next patch number should be `0269`.