mars_nwe/mars-nwe
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases 2 Wiki Activity
Files
c80861b92b00a02091944eb04d964deca8e6c721
mars-nwe/TODO.md
Mario Fetka c80861b92b
All checks were successful
Source release / source-package (push) Successful in 54s
Details
nwconn: implement extracted base handle restore 
Wire NCP 0x16/0x17 Extract a Base Handle and NCP 0x16/0x18 Restore an
Extracted Base Handle to connection-local directory-handle state.

The WebSDK documents NCP 0x2222/22/23 as taking a DirectoryHandle and
returning a 14-byte save buffer composed of a 10-byte ServerNetworkAddress
plus a 4-byte HandleID. The same documentation describes NCP 0x2222/22/24 as
taking that saved ServerNetworkAddress/HandleID pair and returning a
NewDirectoryHandle plus AccessRightsMask.

The SDK headers expose these calls as NWSaveDirectoryHandle() and
NWRestoreDirectoryHandle(), with the save buffer explicitly documented as 14
bytes. The Rust nwserver and lwared references do not implement this older
save/restore pair, and newer clients typically use the normal allocate/set
directory-handle calls instead, so keep the MARS-NWE HandleID opaque and
connection-local rather than guessing a global NetWare directory-base number.

Store extracted base-handle IDs in a small per-connection table that records
the saved volume/path tuple. Extract requires a live permanent directory
handle, and Restore validates the saved server address against this server
before allocating a new permanent directory handle for the saved path.

Add the SDK request/reply semantics to the inline endpoint comments and remove
the corresponding TODO entry.

This enables the documented endpoint path while keeping the saved HandleID
conservative and private to MARS-NWE.
2026-05-30 00:12:31 +02:00

6.5 KiB
Raw Blame History

TODO

This file collects follow-up work that is known but intentionally not part of the current patches. It is meant for project-level items that are too broad or too low-priority to keep as inline source TODO comments.

Server / NCP compatibility

Console privilege model

Current status:

  • NCP 23/200 Check Console Privileges is implemented as a protocol-compatible status check.
  • For now, console privileges are mapped to the existing supervisor-equivalence state computed for the connection.
  • Callers with supervisor equivalence get success; other callers get 0xc6 (No Console Rights).

Follow-up:

  • Add a real console-operator privilege model instead of treating console rights as identical to supervisor equivalence.
  • Decide where the console privilege map should live:
    • a bindery property,
    • a server configuration option,
    • or a small explicit internal list similar to queue operator handling.
  • Check how NetWare 3.x tools such as PCONSOLE, SYSCON, and console utilities expect console operators to be represented.
  • Keep NCP 23/200 as a completion-code-only endpoint; only the privilege source should change.

Queue spool path case handling

Current status:

  • Queue job paths can still be rebuilt from DOS/bindery path spelling such as SYS:SYSTEM/EPSON.QDR.
  • On a case-sensitive Unix filesystem this can differ from the existing directory, for example system/epson.qdr.

Follow-up:

  • Resolve queue job file paths case-insensitively in the queue connection/path resolver, or use the queue object's already-resolved Unix spool directory instead of rebuilding it from the DOS path.
  • Avoid creating duplicate directories that differ only by case.

NCP 17/4C test coverage

Current status:

  • NCP 17/4C List Relations of an Object is implemented server-side.
  • Existing DOS and Linux tools do not reliably trigger it for all useful set properties such as GROUP_MEMBERS and GROUPS_I'M_IN.

Follow-up:

  • Add a small direct test utility to mars-dosutils / NWTESTS that sends NCP 17/4C directly.
  • Suggested test cases:
    • TESTGRP1 type 0x0002, property GROUP_MEMBERS
    • TESTGRP2 type 0x0002, property GROUP_MEMBERS
    • MARIO type 0x0001, property GROUPS_I'M_IN
    • NOPASSUSER type 0x0001, property GROUPS_I'M_IN
    • GUEST type 0x0001, property GROUPS_I'M_IN

NCP endpoint SDK documentation / stub audit

Current status:

  • Several legacy NCP endpoints in src/nwconn.c are implemented only as disabled stubs, explicit 0xfb unsupported replies, or success/no-op dummies.
  • The known candidates now have inline SDK-context comments so future work can start from the documented wire semantics instead of from guesswork.

Follow-up:

  • Implement or deliberately reject remaining endpoint gaps after client evidence or direct protocol tests.
  • Keep SDK details close to the corresponding endpoint in nwconn.c, and keep broader prioritization/status here in TODO.md.

NCP endpoint audit tracking

Current status:

  • src/nwconn.c contains a mix of implemented, forwarded, partial, dummy, and intentionally unsupported NCP endpoints.
  • Endpoint comments should be aligned with the Novell SDK Web documentation, SDK headers, the Rust nwserver implementation, lwared, and the existing mars_nwe admin/Pascal code where those sources cover the same call.

Follow-up:

  • Keep inline TODO: comments only where endpoint behavior is incomplete, approximate, intentionally dummy/no-op, or still needs SDK layout verification.
  • Mirror every real incomplete endpoint in this file so follow-up work remains visible outside the source code.
  • Do not treat every return(-1) in nwconn.c as incomplete: many of those paths intentionally forward bindery/global-server work to nwbind.

NCP synchronization endpoint audit

Current status:

  • The old NCP synchronization endpoint family in src/nwconn.c is now annotated with Novell SDK endpoint names.
  • The existing source already marked this area as not well tested, so the comments intentionally keep that compatibility warning visible.
  • NCP 0x03, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0d, 0x0e, 0x1a, and 0x1e have local implementations.

Follow-up:

  • Verify the implemented file/logical-record/physical-record calls against the Novell SDK request/reply layouts and a real DOS requester or direct test caller.
  • Continue direct requester or NWTESTS coverage for the file, logical-record, and physical-record synchronization calls that are now wired.
  • Verify timeout and error-code behavior for set-oriented locking calls against a real requester, especially where MARS-NWE currently relies on the existing underlying share implementation.

Extended volume information field mapping

Current status:

  • NCP 0x16/0x33 Get Extended Volume Information returns the documented NWVolExtendedInfo reply and fills the core fields that can be derived from generic Unix filesystem statistics.
  • NetWare-specific fields that MARS-NWE does not currently model are returned as zero for now instead of guessed values.

Follow-up:

  • Fill additional NWVolExtendedInfo fields when reliable data is available from the backing filesystem or from MARS-NWE metadata.
  • Candidate fields include suballocation, deleted-file/limbo accounting, compression counters, migration counters, EA counters, Directory Services object id, and last-modified timestamp data.
  • Treat compression-related fields as real follow-up work rather than permanent zeroes; populate them only when the backing filesystem exposes trustworthy compressed-file or compressed-block accounting.

Printing / Queue backend

Q_UNIX_PRINT backend status

Current status:

  • Queue metadata handling and the Q_UNIX_PRINT backend are intentionally separate.
  • The backend can already call /usr/bin/lp, lpr, or a custom script.

Follow-up:

  • Improve logging around queue job submission to the Unix print command.
  • Capture and expose backend exit status where possible.
  • Consider direct CUPS integration only if MARS_NWE needs CUPS job IDs, cancellation, or status polling. Do not add a hard CUPS dependency for basic queue compatibility.

Deferred / optional protocol work

  • Basic Packet Burst file transfer support is implemented and verified with a diagnostics-enabled DOS client test.
  • Packet Burst support is built by default, but runtime use remains controlled by nwserv.conf.
  • Packet Burst/NDS fragmentation support remains out of scope unless a concrete client requires it.
Reference in New Issue View Git Blame Copy Permalink