Wire NCP 0x23/0x11 AFP 2.0 Scan File Information to a conservative read-only directory scan.
The WebSDK documents NWAFPScanFileInformation as taking a volume number, AFP base entry id, last-seen AFP id, search mask, request mask, path string, and file-info buffer. The call scans a directory relative to the AFP base and returns AFP file information for the next matching entry, updating the last-seen id for the caller's next iteration.
Reuse the existing AFP file information formatter and libatalk/stat-derived entry-id path. For now, support path-backed scans only: resolve the supplied SYS:-style path through the mars_nwe path machinery, enumerate one child directory entry after the supplied last-seen id, and return a last-seen id plus an AFP file-info record. Entry-id-only scans, persistent CNID lookup, and full AFP search-mask semantics remain future work.
Add a Linux afp_scan_info_smoke helper using ncpfs/libncp so the new endpoint can be exercised without an AppleTalk client.
This implements the documented read-only scan path needed for directory browsing smoke tests, while keeping write-side AFP and persistent Mac namespace semantics unchanged.
Document the verified AFP 2.0 Get File Information smoke-test coverage after the endpoint was exercised against the same standard SYS volume paths as the older AFP file-information call.
The Linux afp_file_info_smoke test now covers both NCP 0x23/0x05 and NCP 0x23/0x0f. Record that --afp20 was verified against SYS:, SYS:PUBLIC, SYS:SYSTEM, and SYS:BURST using the current path-backed read-only reply.
Keep the remaining AFP limitations explicit: the reply still uses stat/libatalk-derived fields, marks temporary Entry IDs with the fallback diagnostic, and leaves persistent CNID/AppleDouble IDs, Parent ID mapping, and fuller Mac namespace metadata as future work.
This is documentation-only and does not change AFP protocol behavior.
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.
Document the Linux smoke-test coverage for the newly implemented AFP Get File Information endpoint.\n\nThe WebSDK-documented NCP 0x2222/35/05 path now has a Linux libncp smoke test alongside the existing AFP Entry ID probe. Record the verified SYS:, SYS:PUBLIC, SYS:SYSTEM, and SYS:BURST cases and describe the read-only reply fields currently populated from Unix stat data and the optional libatalk helper wrappers.\n\nAlso update the AFP Entry ID smoke-test documentation to match the current default raw-path mode, where SYS:-style paths are sent with directory handle 0 and handle allocation is kept behind --alloc-handle for separate debugging.\n\nKeep the remaining AFP/Mac namespace work in TODO.md, including persistent CNID/AppleDouble entry IDs, Parent ID mapping, Finder Info/resource-fork semantics, AFP 2.0 file information, and Scan File Information coverage.\n\nThis is documentation-only and does not change AFP protocol behavior.
Do not include the AFP Get File Information subfunction byte in the NWRequestSimple payload when the request is already sent through NCPC_SFN().
libncp's subfunction request helper supplies the NCP 0x23 AFP subfunction on the wire. The smoke test also placed 0x05 as the first byte of its local payload, so mars_nwe received a duplicated subfunction byte. The server then decoded the low byte of the request mask as the path length, producing a boundary-check failure with path_len=255 before the path could be resolved.
Build the smoke-test payload as the data following the subfunction byte: Volume Number, AFP Entry ID, Request Bit Map, Path String Length, and Path String. This matches the server-side decoder, which sees the subfunction byte at afp_req[0].
This changes only the Linux smoke test; server AFP protocol behavior is unchanged.
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.
Default the Linux AFP Entry ID smoke test to sending the supplied path directly
with directory handle 0.
The verified smoke cases use SYS:-style paths against mars_nwe, and those
requests reach NCP 0x23/0x0c and return Entry IDs. The intermediate automatic
temporary directory-handle allocation path is not required for that endpoint
coverage and can fail before the AFP request is sent, which makes the smoke
test diagnose the wrong subsystem.
Keep the handle-allocation path available behind --alloc-handle for follow-up
debugging, keep --raw-path as an explicit no-op for compatibility, and keep
--dir-handle N for testing relative paths against a handle that is valid in
the current connection.
This changes only the Linux smoke test; server AFP protocol behavior is
unchanged.
Document the Linux AFP Entry ID smoke-test coverage after the endpoint was verified against the standard SYS volume paths.
The test exercises the WebSDK-documented NCP 0x23/0x0c AFP Get Entry ID From Path Name request by logging in through libncp, allocating a temporary directory handle for the volume root, and sending the relative path to the AFP endpoint.
Record the verified SYS:, SYS:PUBLIC, SYS:SYSTEM, and SYS:BURST cases, and describe the current stat-derived fallback Entry ID diagnostics so the result is not confused with persistent CNID/AppleDouble storage.
Keep the remaining AFP work tracked in TODO.md, including replacing the fallback with persistent CNID/directory-id mapping and extending tests when additional AFP subfunctions are implemented.
This is documentation-only and does not change AFP protocol behavior.
Open the libncp connection with login_necessary set to true.
ncpfs/libncp does not block individual NCP endpoints here. The problem was that ncp_initialize(..., 0, ...) deliberately clears the user name even when -S/-U/-P were supplied, leaving the connection unauthenticated. mars_nwe then rejects directory-handle allocation for non-login paths with Invalid Path before the AFP NCP 0x23/0x0c request is ever sent.
The AFP Entry ID smoke test needs normal file-service path access in order to allocate or use a directory handle before issuing the AFP request. Require a logged-in connection, while still allowing no-password test users via libncp's existing -n option.
This changes only the Linux smoke test; server AFP protocol behavior is unchanged.
Allocate the temporary directory handle for the AFP Entry ID smoke test through mars_nwe's old directory-handle endpoint instead of the NCP 87 namespace helper.
The AFP Get Entry ID From Path Name call expects a directory handle plus a relative path. The previous smoke-test variants tried to obtain that handle through libncp's namespace allocation helper, but mars_nwe currently rejects the NCP 87 DIRBASE volume-root form before the AFP request is sent, so no AFP diagnostics appear in the server log.
Use the old NCP 0x16/0x13 Allocate Temporary Directory Handle call that mars_nwe implements directly, passing a VOL: root path and then sending only the relative path to NCP 0x23/0x0c. Keep the existing deallocate path.
This changes only the Linux smoke test; server AFP protocol behavior is unchanged.
Resolve the volume name before allocating the temporary directory handle used by the AFP Entry ID smoke test.
ncpfs does not block the AFP endpoint. Its ncp_ns_alloc_short_dir_handle() helper sends the namespace-aware handle allocation request using the supplied directory style, volume, directory entry, and path tuple. The ncpfs tests allocate a handle for a volume root with NCP_DIRSTYLE_DIRBASE, a volume number, directory entry 0, and no encoded path, then use that handle with relative paths.
The smoke test was still trying to allocate the handle as a NOHANDLE path using a raw VOL: string. mars_nwe rejects that request before the AFP request is sent, so the test never reaches NCP 0x23/0x0c and no AFP diagnostics appear in the server log.
Look up the volume number with ncp_get_volume_number(), allocate the temporary handle as DIRBASE(volume, 0, NULL), and keep passing only the relative path to AFP Get Entry ID From Path Name.
This changes only the Linux smoke test; server AFP protocol behavior is unchanged.
Pass NCP_PATH_STD to ncp_ns_alloc_short_dir_handle() when the AFP Entry ID
smoke test allocates a temporary directory handle for a VOL: path.
The test already uses libncp to allocate the handle, but it passed the raw
"SYS:" bytes together with an explicit byte length. ncpfs helpers expect
NCP_PATH_STD when the caller wants libncp to encode a normal NetWare path into
the component-counted wire format. Sending the raw VOL: string made the server
reject the handle allocation with completion 0x98 before the AFP endpoint was
reached.
Keep the libncp handle allocation path, but let libncp encode the root volume
path the same way the ncpfs tools do. This changes only the Linux smoke test;
server AFP protocol behavior is unchanged.
Use libncp\047s namespace-aware short directory handle helper in the AFP Entry ID smoke test instead of hand-building the old Allocate Temporary Directory Handle request.\n\nThe smoke test accepts NetWare-style VOL:PATH arguments, but NCP 0x23/0x0c AFP Get Entry ID From Path Name expects a directory handle plus a relative path. The previous test tried to allocate a temporary handle by issuing the old NCP 0x16/0x13 request directly, which failed with Invalid Path before the AFP endpoint was reached.\n\nMirror the ncpfs tools and call ncp_ns_alloc_short_dir_handle() for the volume root in the DOS namespace, then pass only the relative path to the AFP request. Keep deallocating the temporary handle after the request.\n\nThis changes only the Linux smoke test; server AFP protocol behavior is unchanged.
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.
Add an optional Linux-side smoke test for the first implemented NetWare AFP endpoint.
The WebSDK documents NCP 0x2222/35/12 AFP Get Entry ID From Path Name as taking a NetWare directory handle and path string and returning a 32-bit AFP entry id. MARS-NWE now has a guarded implementation of that probe when the optional Netatalk/libatalk backend is compiled in, but exercising it does not require a real AppleTalk workstation.
Use the ncpfs/libncp client library as the test transport. ncpfs is commonly available on Linux mars_nwe test hosts and its NWRequestSimple() helper builds the same length-prefixed subfunction request format used by normal libncp callers. The test accepts standard ncpfs connection options such as -S, -U, -P, and -n, sends NCP 0x23/0x0c, and prints the returned entry id.
Keep the test out of normal builds behind MARS_NWE_BUILD_LINUX_TESTS because it depends on host ncpfs development headers/library and on a running server. Add an --allow-invalid-namespace mode so builds without the Netatalk backend can still run a negative smoke test and verify that AFP remains unavailable.
This adds test infrastructure only and does not change server protocol behavior.
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.
Update TODO.md after the recently enabled synchronization and extended volume
information endpoints.
The file/logical-record/physical-record synchronization entries no longer need
to list NCP 0x04, 0x0c, and 0x1f as disabled or dummy endpoints. Keep the
remaining work focused on requester/NWTESTS coverage plus timeout and
error-code verification for set-oriented locking calls.
Also track follow-up work for fields that are currently returned as zero by
Get Extended Volume Information because MARS-NWE does not yet model them. The
endpoint now returns the documented NWVolExtendedInfo reply, but NetWare-
specific counters such as suballocation, deleted-file/limbo, compression,
migration, EA, Directory Services, and timestamp fields should only be filled
once reliable backing filesystem or MARS-NWE metadata is available.
This is documentation-only and does not change NCP behavior.
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.
Add physical-record entries to the shared synchronization set table.
The Novell SDK documents the physical-record set calls as operating on the
caller's logged data byte range table: Log Physical Record adds byte ranges,
Lock Physical Record Set locks all logged ranges, Release Physical Record Set
unlocks them while keeping them logged, and Clear Physical Record Set unlocks
and removes them.
MARS-NWE already used the shared set handler for file and logical-record sets.
Extend the same table with type 4 entries for physical records, storing the
NetWare file handle, start offset, record length, timeout, lock directive, and
current locked state.
Add a type 4 handler that reuses nw_log_physical_record() for set lock and
release operations, and export share_set_physrec_add_rm() so nwconn can
maintain the set table when individual physical-record calls log or clear
ranges.
This prepares the documented Physical Record Set endpoints to use the existing
byte-range lock 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.
Keep synchronization set entries linked while handling Lock, Release, and Clear
Set operations.
The Novell SDK documents the set-oriented synchronization calls as operating on
the caller task table: Log File and Log Logical Record add entries, Lock Set
locks the logged entries, Release Set unlocks them while keeping them logged
for future Lock Set calls, and Clear Set unlocks and removes them.
share_handle_lock_sets() already encoded that semantic split with lock_flag -1
for release and -2 for clear, but its iterator unlinked each entry before
checking whether it should be removed. That meant even Lock Set and Release Set
walked the table destructively, and non-matching set types could be lost while
operating on another set family.
Only unlink entries when processing a matching Clear Set operation. Leave
entries in place for Lock Set and Release Set, and advance the list normally
for non-matching entries.
This fixes the shared set iterator used by the documented File Set and Logical
Record Set endpoints; it does not change the low-level locking primitives.
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.
Store the set-entry type when files and logical records are added to a
connection's synchronization set.
The Novell SDK documents the set-oriented synchronization calls as operating
on the caller's current task file/logical-record set: Log File and Log Logical
Record add entries, while Lock/Release/Clear Set calls later operate on those
logged entries.
MARS-NWE already had type-specific handling in share_handle_lock_sets(), using
type 1 for file sets and type 2 for logical-record sets, but newly allocated
SHARESET entries were left with the zero-filled default type. That meant the
type filter could not reliably match entries for set operations.
Assign type 1 in share_set_file_add_rm() and type 2 in
share_set_logrec_add_rm() so the existing set handlers can find the entries
they are supposed to lock, release, or clear.
This prepares the documented Lock File Set endpoint to use the existing set
path and also fixes the already-wired release/clear set handlers.
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.
Use the bounded printable formatter for two remaining debug paths that can
log protocol-derived byte fields directly.
The SAP route suppression log can print SAP-derived server names, including
non-printable bytes advertised by newer NetWare service types. The namespace
search diagnostic can also contain DOS wildcard bytes such as 0xff padding.
Format both fields through visable_data() so diagnostics stay readable and do
not emit raw control or high-bit bytes.
This is logging-only and does not change SAP, routing, or namespace behavior.
Bindery object names are fixed-size NetWare protocol fields and may contain
non-printable bytes when they originate from SAP service advertisements.
Use the existing bounded printable formatter for bindery object names in debug
output so nwbind logs do not emit raw high-bit/control bytes for SAP-derived
objects. This keeps diagnostics readable after SAP name logging was made
bounded in nwserv.
This is logging-only and does not change bindery or SAP/RIP behavior.
SAP service names are fixed-size 48-byte fields and are not guaranteed to be
safe C strings in diagnostics. Some NetWare 6.5 SAP service types advertise
non-printable or high-bit bytes in the name field, which made the debug log
hard to read and could run past the intended protocol field if logged with a
plain %s.
Add bounded formatting for SAP names used in debug output. Stop at NUL within
the fixed field, keep printable ASCII unchanged, and escape other bytes as
\\xNN.
This is logging-only and does not change SAP/RIP protocol behavior.
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.
Packet Burst is no longer merely optional follow-up work for DOS tool
compatibility.
A diagnostics-enabled DOS client run verified real Packet Burst negotiation
and READ/WRITE data-path usage, and ENABLE_BURSTMODE now defaults to ON at
build time while runtime use remains controlled by nwserv.conf.
Keep Packet Burst/NDS fragmentation listed as deferred optional work.
Build Packet Burst support by default.
The feature is still controlled at runtime by the server configuration, so
enabling the CMake option does not force Packet Burst usage for deployments
that have not enabled it in nwserv.conf.
A diagnostics-enabled DOS client test confirmed real Packet Burst negotiation
and READ/WRITE data-path usage, so the optional code path is now suitable to
ship in normal builds.
Packet Burst/NDS fragmentation support remains deferred.
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.
Add a top-level TODO.md for follow-up work that should not remain as scattered
inline source comments.
Document the current Check Console Privileges limitation, where console rights
are mapped to supervisor equivalence for now, and track the need for a real
console privilege map. Also record follow-ups for queue spool path case
handling, direct NCP 17/4c test coverage, Q_UNIX_PRINT backend improvements,
and deferred optional protocol work.
Reference TODO.md from the main README.
Replace the old Check Console Privileges TODO with the documented NCP 23/200
behavior.
The call has no reply data and reports authorization solely through the
completion code. Return success for supervisor-equivalent connections and
0xc6 for callers without console operator privileges instead of accepting all
callers.
MARS-NWE does not currently maintain a separate console-operator list, so map
console privileges to the existing supervisor-equivalence flag computed at
login time.
No queue or file service behavior change.
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.
Implement the Queue Change Job Entry endpoint for both the old NCP 17/6d
and newer NCP 17/7b variants.
Parse the queue job structure, look up the selected job by its job number,
and update the mutable job metadata fields while preserving server-managed
state such as client identity, entry time, job number, queue position, file
name/handle and servicing information.
Allow the job creator to update the standard user-changeable fields and allow
SUPERVISOR or Q_OPERATORS members to update the operator hold flag as well.
Return the documented queue/job/right/servicing completion codes for missing
queues, missing jobs, insufficient rights and jobs already being serviced.
This only updates NetWare queue metadata. It does not change the existing
Q_UNIX_PRINT/lp backend behavior and adds no CUPS dependency.
Implement the Bindery "List Relations of an Object" endpoint.
Parse the NCP 17 subfunction 0x4c request, look up the requested bindery
object and set property, and return up to 32 related object IDs from the set
property value segments. Support the Novell last-seen cursor convention where
0xffffffff starts a new scan and subsequent calls continue after the last
returned object ID.
Add a small nwdbm helper for listing set-property members while preserving the
existing bindery property read-right checks. Reject wildcard object names with
the documented illegal-wildcard completion code.
Stop logging the build_base NW_HPATH component buffer as a raw C string.
The path buffer is length-prefixed and not NUL-terminated. Printing it with %s
can over-read into following packet or process memory and pollute unrelated
client/test output, for example ZIP output appearing inside MAPDEBUG lines.
Use the safe NW_HPATH component formatter for the build_base ENTER log line as
well as individual component debug output.
No protocol behavior change.
Stop logging NW_HPATH path component buffers with %s in MAPDEBUG output.
The namespace path buffer is not a NUL-terminated C string. It contains a list
of length-prefixed components, so printing it directly can over-read into
following packet or process memory and pollute unrelated client/test output.
Add small debug formatters for complete NW_HPATH component lists and individual
components, and use them in build_base/add_hpath_to_nwpath debug messages.
No protocol 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.
Novell NCOPY can allocate temporary directory handles while checking
effective directory rights before copying. On long-running test runs the
temporary directory handle table may already contain stale entries, causing
Allocate Temporary Directory Handle to fail with -0x9d / "no directory
handles". NCOPY then falls back to relative GetEffectiveRights requests that
fail and reports:
NWGetEffectiveDirectoryRights returned an error.
Restore recycling of stale temporary directory handles in xinsert_new_dir().
Free slots are still preferred. If none are available and the caller requests
a temporary handle, recycle the oldest temporary handle for the same task first,
then the oldest temporary handle globally. Permanent directory handles are not
recycled.
This matches the expected NetWare-style behaviour for temporary handles and
allows NCOPY-style allocate-temp-handle / get-effective-rights flows to keep
working after repeated tests.
