8e885bb16d
All checks were successful
Source release / source-package (push) Successful in 46s
Route NCP 0x23/0x0f AFP 2.0 Get File Information through the existing read-only AFP file-information helper. The WebSDK and nwafp.h list both AFP Get File Information and AFP 2.0 Get File Information as path/file-information queries that return the AFP file-information record used by Mac namespace clients. The already implemented 0x05 path handles SYS:-style path requests and fills the safe read-only fields from Unix stat data plus the optional libatalk Finder Info and resource-fork helpers. Use the same conservative path-backed reply for 0x0f for now. This gives Linux smoke-test coverage for the AFP 2.0 subfunction without adding entry-id-only lookup, persistent CNID mapping, write-side metadata updates, or fuller resource-fork semantics. Extend afp_file_info_smoke with --afp20 so the same SYS:, SYS:PUBLIC, SYS:SYSTEM, and SYS:BURST cases can exercise the AFP 2.0 subfunction. Update the Linux test README and TODO tracking to record that AFP 2.0 file information is covered by the same temporary fallback model. This implements only the read-only path-based subset; richer AFP 2.0 behavior remains future Mac-namespace work.
239 lines
10 KiB
Markdown
239 lines
10 KiB
Markdown
# 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.
|
|
|
|
### Object disk restriction fallback coverage
|
|
|
|
Current status:
|
|
|
|
- `NCP 0x16/0x29 Get Object Disk Usage And Restrictions` keeps the existing
|
|
`QUOTA_SUPPORT` split.
|
|
- With quota support enabled, the endpoint is routed through `nwbind` so the
|
|
bindery Object ID can be mapped to a Unix uid before querying the quota
|
|
backend.
|
|
- Without quota support, the endpoint returns the SDK-compatible fallback:
|
|
unrestricted (`0x40000000`) and no space in use.
|
|
|
|
Follow-up:
|
|
|
|
- Add direct tests for both build modes.
|
|
- Verify the quota-enabled path against a real Unix quota setup.
|
|
- Verify that the quota-disabled fallback remains compatible with requesters
|
|
and with the WebSDK rule for invalid object IDs.
|
|
|
|
## Printing / Queue backend
|
|
|
|
### Q_UNIX_PRINT backend status
|
|
|
|
Current status:
|
|
|
|
- Queue metadata handling and the `Q_UNIX_PRINT` backend are intentionally separate.
|
|
- The backend can already call `/usr/bin/lp`, `lpr`, or a custom script.
|
|
|
|
Follow-up:
|
|
|
|
- Improve logging around queue job submission to the Unix print command.
|
|
- Capture and expose backend exit status where possible.
|
|
- Consider direct CUPS integration only if MARS_NWE needs CUPS job IDs, cancellation, or status polling. Do not add a hard CUPS dependency for basic queue compatibility.
|
|
|
|
### Transaction Tracking System (TTS)
|
|
|
|
Current status:
|
|
|
|
- `NCP 0x22/0x00 TTS Is Available` reports the WebSDK-documented
|
|
unavailable status.
|
|
- MARS-NWE does not currently implement TTS rollback semantics, transaction
|
|
files, transaction status tracking, or the begin/end/abort transaction
|
|
state machine.
|
|
- Other TTS subfunctions remain unsupported instead of pretending to succeed
|
|
without real transaction tracking.
|
|
|
|
Follow-up:
|
|
|
|
- Implement TTS only if a concrete client requires it.
|
|
- Treat this as a real transaction subsystem, not as a completion-code shim:
|
|
the WebSDK TTS calls include begin/end/abort transaction, status, threshold,
|
|
and control/statistics operations.
|
|
|
|
### AFP / Mac namespace backend
|
|
|
|
Current status:
|
|
|
|
- `NCP 0x23` still returns invalid namespace for AFP calls that are not implemented yet.
|
|
- `AFP Get Entry ID From Path Name` is implemented when the optional
|
|
Netatalk/libatalk backend is available. Linux smoke coverage exists in
|
|
`tests/linux/afp_entry_id_smoke` and has been verified against `SYS:`,
|
|
`SYS:PUBLIC`, `SYS:SYSTEM`, and `SYS:BURST` with stat-derived fallback
|
|
entry IDs.
|
|
- `AFP Get File Information` is implemented for read-only path-based requests.
|
|
Linux smoke coverage exists in `tests/linux/afp_file_info_smoke` and has
|
|
been verified against `SYS:`, `SYS:PUBLIC`, `SYS:SYSTEM`, and `SYS:BURST`.
|
|
The same test can exercise the AFP 2.0 Get File Information subfunction via
|
|
`--afp20`, using the same path-backed read-only reply for now. The current
|
|
reply fills stat/libatalk-derived fields and leaves persistent CNID Parent ID
|
|
/ fuller Mac namespace metadata as future work.
|
|
- The AFP dispatcher now decodes the WebSDK/NWAFP subfunction number in
|
|
diagnostics so real client probes can be mapped to the corresponding AFP
|
|
call before implementation work starts.
|
|
- Optional build-time detection/linking for Netatalk/libatalk exists as a first
|
|
local metadata backend hook. It is deliberately not an AFP protocol
|
|
implementation yet.
|
|
- NetWare AFP calls are NCP entry points for Mac namespace semantics on a
|
|
NetWare volume, not transport-level AFP proxy calls to `afpd`.
|
|
|
|
Follow-up:
|
|
|
|
- Implement the NetWare AFP NCP calls locally, using libatalk helpers rather
|
|
than proxying requests to `afpd`.
|
|
- Candidate libatalk pieces include the new AppleDouble/Finder Info/resource
|
|
fork helper wrappers, plus future CNID/directory-id helpers, attribute
|
|
mapping, and filename conversion.
|
|
- Keep returning invalid namespace for AFP calls that still lack a real per-volume Mac
|
|
namespace/AFP metadata layer. Do not return success for additional AFP calls without
|
|
data/resource fork and Finder Info semantics.
|
|
- Replace the temporary stat-derived AFP entry-id fallback with a persistent
|
|
CNID/directory-id mapping once the libatalk/CNID backend is integrated.
|
|
- Extend the Linux AFP smoke tests once additional AFP subfunctions are
|
|
implemented, especially Scan File Information, Finder Info updates, fork
|
|
open/read/write paths, and resource-fork handling.
|
|
|
|
## 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.
|