Wire NCP 0x23/0x05 AFP Get File Information to a conservative read-only reply
for SYS:-style paths.
The WebSDK documents NCP 0x2222/35/05 as taking a Volume Number, AFP Entry ID,
request bit map, and AFP path modifier string, and returning an AFP file
information record with entry id, parent id, attributes, data and resource fork
lengths, offspring count, NetWare dates, Finder Info, long and short names,
owner id, access privileges, and ProDOS information. The SDK headers expose the
same call as AFPGetFileInformation() and NWAFPGetFileInformation(), with the
wire reply matching RECPKT_AFPFILEINFO.
Resolve the supplied path through the existing mars_nwe path machinery, require
the optional Netatalk/libatalk backend as for the entry-id probe, and fill the
fields that can be derived safely from Unix stat data and the existing libatalk
helpers. Finder Info and resource fork length are read through nwatalk when
present; entry ids fall back to the existing stat-derived AFP id until
persistent CNID/AppleDouble ids are implemented. Parent id and ProDOS-specific
data remain zero for now.
Add a Linux afp_file_info_smoke test using ncpfs/libncp so the new call can be
exercised without an AppleTalk client. The test sends raw SYS:-style paths with
directory handle 0, matching the verified AFP Entry ID smoke-test path.
This implements only the read-only AFP file information query for path-based
requests; entry-id-only lookup, persistent CNID mapping, and write-side AFP
semantics remain future work.
Teach the Linux AFP Entry ID smoke test to treat VOL:PATH arguments like normal NetWare paths instead of sending the full string as the AFP path component.
The WebSDK documents AFP Get Entry ID From Path Name as taking a NetWare directory handle plus a path string. A user-supplied path such as SYS:PUBLIC therefore needs a directory handle for the SYS volume root and a relative AFP path of PUBLIC; sending SYS:PUBLIC as the AFP path with directory handle zero makes the server reject the request with Invalid Path before the actual AFP lookup is useful.
Use the existing ncpfs/libncp request path to allocate a temporary directory handle for the volume root when the test receives a VOL:PATH argument and no explicit --dir-handle was supplied. Keep --raw-path for callers that want to send the path exactly as typed, and add --allow-invalid-path so negative path-resolution tests can distinguish Invalid Path from Invalid Namespace.
Also add failure diagnostics to the server-side AFP path lookup so unsupported-backend, boundary-check, path-resolution, and stat failures are visible in the mars_nwe log.
This changes only the Linux smoke test and debug logging; it does not change successful AFP protocol semantics.
Keep NCP 0x16/0x20 Scan Volume User Disk Restrictions from linking nwconn against bindery database helpers.
The WebSDK documents the scan call as returning a sequence of Object ID / Restriction pairs, while the per-object NCP 0x16/0x29 query can be resolved through nwbind because it carries a concrete Object ID. The scan call is different: producing a quota-backed list requires iterating bindery user objects and reading each UNIX_USER property, which belongs to the nwbind/nwdbm side of the existing process split.
The previous implementation attempted that scan directly in nwconn and therefore referenced scan_for_obj() and nw_get_prop_val_by_obj_id(), which are provided by nwdbm and are not linked into the nwconn executable. This broke quota-enabled builds when the endpoint was compiled.
Return the SDK-compatible empty list after validating the volume, matching the existing non-quota behavior and the conservative behavior used by other open implementations. Leave real quota-backed scan enumeration as future nwbind-side work instead of pulling bindery database code into nwconn.
This fixes the build and preserves the documented endpoint shape; real quota scanning remains unimplemented.
Wire NCP 0x23/0x0c AFP Get Entry ID From Path Name to a real path lookup when the optional Netatalk/libatalk backend is available.
The WebSDK documents NCP 0x2222/35/12 as converting a NetWare directory handle plus short-name path string into a unique 32-bit Macintosh file or directory Entry ID. The request carries the AFP subfunction, NetWare directory handle, path length, and path string; the reply carries the 4-byte AFP Entry ID. The SDK headers expose the same operation as AFPGetEntryIDFromPathName() and NWAFPGetEntryIDFromPathName(), and NWAFPSupported() uses this path-name probe to test AFP support.
Resolve the NetWare directory handle and path through the existing mars_nwe path machinery, require the optional libatalk backend before returning AFP success, and then ask libatalk for an AppleDouble/CNID-style id when available. If libatalk is present but the file has no stored id yet, return a deterministic stat-derived local entry id as a temporary fallback so the path-name probe can succeed without inventing NetWare directory base numbers.
Keep all other AFP subfunctions returning invalid namespace for now. They still need Finder Info, resource fork, AFP file information, fork open, and persistent CNID/directory-id support before they can safely report success.
Add the SDK request/reply semantics to the inline endpoint comments and keep the remaining AFP work tracked in TODO.md.
This implements only the AFP path-to-entry-id probe; it does not add general AFP file or resource-fork semantics yet.
Decode the NCP 0x23 AFP subfunction number in diagnostics before rejecting the
call as an unavailable Mac namespace request.
The WebSDK documents the old NetWare AFP calls as NCP 0x2222/35 subfunctions,
and the SDK headers expose the same entry points through nwafp.h. Record the
known subfunction names for AFP Delete, Get Entry ID From Name, Get Entry ID
From NetWare Handle, Rename, Open File Fork, Alloc Temporary Dir Handle, Get
Entry ID From Path Name, AFP 2.0 Create, Get/Set File Information, and Scan
File Information.
MARS-NWE still does not implement the per-volume Mac namespace semantics
required to return success for these calls. Netatalk/libatalk can provide local
AppleDouble/Finder Info/resource-fork helpers, but mars_nwe must still decode
and answer the NetWare NCPs itself.
Keep returning invalid namespace for now, but make the rejected call visible in
the log so real client probes can be mapped to the SDK subcall that needs to be
implemented next. Update TODO.md to track that the AFP dispatcher now has
subfunction-aware diagnostics.
This is diagnostics-only and does not change AFP protocol behavior.
Add an opt-in CMake hook for Netatalk/libatalk and a small nwconn-side helper
layer for future AFP/Mac namespace work.
NetWare AFP NCP 0x23 calls still have to be decoded and answered by MARS-NWE;
libatalk is not used as an afpd proxy. Instead, expose local helper wrappers
that can read AppleDouble/Finder Info metadata and resource-fork sizes from a
backing Unix path when libatalk is available.
The WebSDK documents the AFP calls as NetWare server entry points for Mac
namespace semantics, and the SDK headers expose probes such as NWAFPSupported()
plus AFP entry-id and file-information calls. Those calls require AFP entry
IDs, Finder Info, resource forks, and per-volume Mac namespace state before
MARS-NWE can return success.
Keep NCP 0x23 returning invalid namespace for now, but record whether the
libatalk metadata backend was compiled in when rejecting AFP calls. Update
TODO.md to track the remaining NetWare AFP implementation work on top of the
new backend hook.
This adds build-time integration and local metadata helpers only; it does not
change AFP protocol behavior.
Add WebSDK context to the Transaction Tracking System endpoint handling.
The WebSDK documents NCP 0x2222/34/00 TTS Is Available as a
completion-code-only status probe with no reply data. A completion code of
0x00 means Transaction Tracking Unavailable, 0xfd means Disabled, and 0xff
means Available. The SDK headers expose this call as NWTTSIsAvailable().
MARS-NWE does not implement TTS rollback semantics, transaction files,
transaction status tracking, or the begin/end/abort transaction state machine.
Keep reporting the documented unavailable status for the availability probe,
but leave state-changing TTS subfunctions unsupported rather than pretending
to start or complete transactions without rollback behavior.
lwared and the Rust nwserver implementation do not provide a fuller TTS
transaction implementation to mirror, so keep the remaining TTS work tracked
as deferred optional protocol work in TODO.md.
This preserves existing protocol behavior while documenting why the only
locally handled TTS subfunction is the availability probe.
Wire NCP 0x16/0x20 Scan Volume's User Disk Restrictions to the existing
quota backend when quota support is available.
The WebSDK documents NCP 0x2222/22/32 as taking a Volume Number and a Sequence
value, and returning a Number Of Entries byte followed by up to twelve Object
ID / Restriction pairs. The Sequence starts at zero and is incremented by the
number of entries returned by previous calls. Restrictions are reported in 4K
blocks.
The SDK headers expose the same call as NWScanVolDiskRestrictions() and
NWScanVolDiskRestrictions2(). The Rust nwserver implementation and lwared both
validate the volume and return an empty list, which is compatible with an
unrestricted server but does not expose configured quotas.
Keep that empty-list behavior for non-quota builds. When QUOTA_SUPPORT is
enabled, scan bindery user objects, map each object through its UNIX_USER
property to a Unix uid, query nw_get_vol_restrictions(), and return entries for
users with an actual finite restriction. Use the request Sequence as an index
into the restricted-entry stream and return at most the SDK maximum of twelve
entries per reply.
Add the SDK request/reply semantics to the inline endpoint comment.
This enables the documented endpoint path while preserving the existing
no-restrictions result for builds without quota support.
Add SDK context to NCP 0x16/0x29 Get Object Disk Usage And Restrictions while
keeping the existing QUOTA_SUPPORT split intact.
The WebSDK documents NCP 0x2222/22/41 as taking a Volume Number and a high-low
Object ID, and returning Restriction and In Use values in 4K blocks. A
restriction of 0x40000000 means that the object has no disk restriction, and
invalid object IDs return success with no restriction and no space used.
With QUOTA_SUPPORT enabled, MARS-NWE routes the call through nwbind so the
object ID can be mapped to a Unix uid before nw_get_vol_restrictions() queries
the quota backend. With quota support disabled, keep the local SDK-compatible
unrestricted/no-use fallback so hosts without quota support do not need the
quota backend.
Add the SDK request/reply semantics to the inline endpoint comment and track
direct test coverage for both build modes in TODO.md.
This is documentation-only apart from renaming the debug message from DUMMY to
fallback, and preserves the build-time QUOTA_SUPPORT behavior.
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.
Wire NCP 0x16/0x33 Get Extended Volume Information to a real reply instead of
returning 0xfb.
The WebSDK documents NCP 0x2222/22/51 as taking a VolumeNumber and returning a
low-high VolInfoReplyLen, an NWVolExtendedInfo structure, and a
length-prefixed volume name. The SDK headers define NWVolExtendedInfo as 33
32-bit fields covering volume type, status flags, sector and cluster geometry,
free-space counters, suballocation/limbo/compression/migration counters,
directory counters, EA counters, a Directory Services object id, and a
last-modified timestamp.
Map the Unix filesystem data already used by the older volume-information
calls to the core extended-volume fields: report a NetWare 386 v3.1 style
volume type, 512-byte sectors, 8 sectors per cluster, total/free clusters, and
directory-entry counters derived from fs_usage. Report NetWare-specific
suballocation, limbo, compression, migration, EA, Directory Services, and
timestamp fields as zero for now.
Add the SDK request/reply semantics to the inline endpoint comment and remove
the corresponding TODO entry.
This enables the documented endpoint path while keeping the mapping
conservative; fields MARS-NWE cannot currently model remain zero rather than
guessed.
Wire the physical-record set endpoints to the shared synchronization-set
handler.
The Novell SDK documents NCP 0x2222/27 Lock Physical Record Set (old) and NCP
0x2222/110 Lock Physical Record Set as locking all byte ranges logged by the
calling client. The request carries a one-byte Lock Flag plus a 2-byte Lock
Timeout in 1/18 second units. Bit 1 of the Lock Flag selects shareable/read-only
locking; otherwise the set is locked exclusive/read-write.
The SDK documents NCP 0x2222/29 Release Physical Record Set as releasing all
locked byte ranges while leaving them in the client data byte range table, and
NCP 0x2222/31 Clear Physical Record Set as releasing all locked ranges and
clearing that table. The set calls return no reply data and report success,
timeout, or lock errors through the completion code.
Maintain the physical-record set table from the individual Log/Release/Clear
Physical Record path: successful 0x1a calls add the range, 0x1c leaves it
logged, and 0x1e removes the matching range after a successful unlock. Then
route 0x1b/0x6e, 0x1d, and 0x1f through share_handle_lock_sets() with type 4.
Remove the old Clear Physical Record Set dummy and the corresponding TODO
entry.
This enables the documented endpoint paths; timeout handling remains limited to
the existing underlying share implementation.
Wire NCP 0x1c Release Physical Record to the existing physical-record unlock
path.
The Novell SDK documents NCP 0x2222/28 as releasing one byte range held by the
calling client without removing it from the client data byte range table. The
byte range remains logged and may be relocked by a later Lock Physical Record
Set call. The request carries a reserved byte, a 6-byte NetWare file handle, a
start offset, and a record length; the reply carries no data and reports
Unlock Error through the completion code.
The neighboring handler already supported NCP 0x1a Log Physical Record and NCP
0x1e Clear Physical Record. Reuse the same request layout and distinguish
release from clear by passing lock_flag -1 for release/unlock only and
lock_flag -2 for clear/unlock plus unlog.
Add the SDK request/reply semantics to the inline endpoint comment and make
the previously missing 0x1c endpoint reachable.
This only enables the documented endpoint path; the underlying physical-record
locking implementation is unchanged.
Wire NCP 0x04 Lock File Set and NCP 0x6a Lock File Set to the existing
file-set lock path.
The Novell SDK documents NCP 0x2222/04 as the old Lock File Set call and NCP
0x2222/106 as its replacement. Both calls lock all files logged by the calling
client's current task. The request carries a 2-byte Lock Timeout in 1/18
second units, the reply carries no data, and completion reports success,
timeout, or lock error.
MARS-NWE already records file-set members through Log File and already routes
Release File Set and Clear File Set through share_handle_lock_sets(). Use the
same set handler for Lock File Set with lock_flag 0 so the handler locks the
logged entries using each entry's recorded lock directive, defaulting to
exclusive when no directive was logged.
Enable the previously disabled old endpoint, add support for the SDK
replacement endpoint, add the SDK request/reply semantics to the inline
endpoint comment, and remove the corresponding TODO entry.
This enables the documented endpoint path; timeout handling remains limited to
the existing underlying share implementation.
Wire NCP 0x0c Release Logical Record to the existing logical-record release
path.
The Novell SDK documents NCP 0x2222/12 as releasing one synchronization string
held by the calling client without removing it from the client's
synchronization string table. The string remains logged and may be relocked by
a later Lock Logical Record Set call.
The handler already distinguished this from NCP 0x0b Clear Logical Record:
0x0b uses lock_flag -2 to unlock and unlog the record, while 0x0c uses
lock_flag -1 to unlock only.
Enable the previously disabled case label, add the SDK request/reply semantics
to the inline endpoint comment, and remove the corresponding TODO entry.
This only enables the documented endpoint path; the underlying locking
implementation is unchanged.
Add SDK/protocol context comments for the remaining known nwconn.c endpoint
stubs and partial implementations.
Document the intended behavior and follow-up work for Lock File Set, Release
Logical Record, Restore Directory Handle, Get Extended Volume Information, and
Clear Physical Record Set. Also add matching TODO.md entries so these
compatibility gaps are tracked outside inline source comments.
This is documentation-only and does not change NCP behavior.
Add explicit debug logging around the existing Packet Burst code paths.
Log burst buffer negotiation, connection setup, incoming burst data packets,
read/write burst requests and replies, response packets, and missing-list
requests. This makes it possible to distinguish normal NCP file transfers from
actual Packet Burst data-path usage when ENABLE_BURSTMODE is enabled.
No protocol behavior change.
Expose the existing experimental Packet Burst code through a CMake option.
Generate ENABLE_BURSTMODE in config.h from -DENABLE_BURSTMODE instead of
keeping it hard-coded to 0, and print the selected state during configuration.
Also fix the existing nwconn burst dispatch conditional so the source compiles
when ENABLE_BURSTMODE is enabled.
This only makes the existing Packet Burst code build-selectable; it does not
change the default behavior, which remains disabled.
Replace the old "Get connection ??" TODO for NCP function 0x13 with the
documented old Get Station Number semantics.
This simple legacy call returns the current station/connection number as a
single byte and is used by old DOS requesters before the richer NCP 23
connection services. Keep the existing one-byte reply for normal connections,
but reject invalid or unrepresentable connection numbers instead of silently
truncating them.
No queue or file service behavior change.
Add the missing NCP 21 message service endpoints for disabling/enabling
broadcast reception and for the newer send/get broadcast message calls.
Track a per-connection broadcast_disabled flag and use a shared helper for
storing pending broadcast messages and notifying the target nwconn process.
The old NCP 21/00 send path now uses the same helper as the newer NCP 21/10
path.
Also improve UNKNOWN FUNCTION logging in nwconn.c by including the NCP type,
function and, where available, subfunction. This makes future missing-endpoint
logs easier to map back to SDK/NCP documentation.
Based on the existing MARS-NWE message handling, the old lwared broadcast
implementation, and the Novell WebSDK message service layouts.
Keep the Supervisor trustee bit when converting rights between the
internal v3 representation and the NCP22 wire format.
Mars calculated effective rights with the Supervisor bit set, for
example 0x01ff, but the NCP22 conversion collapsed the result to
0x00ff before returning it to DOS clients. As a result Novell RIGHTS
showed only:
[ RWCEMFA]
instead of the expected:
[SRWCEMFA]
Map the old Open right to bit 0x0004 and keep Supervisor on bit 0x0100
in both conversion directions so NCP22/3 and NCP22/42 preserve the full
effective rights mask.
NCP22 uses bit 0x80 for Modify. MARS internally uses the same bit for
TRUSTEE_M, while Supervisor is represented internally as TRUSTEE_S at 0x100.
Only the Supervisor/Open bit needs translation.
The previous conversion mapped NCP22 0x80 incorrectly, causing GRANT M from
Novell tools to be stored without TRUSTEE_M internally. As a result, users with
directory Modify rights could not rename files even though NDIR/RIGHTS displayed
the rights as expected.
