Document and exercise the conservative AFP Open File Fork boundary before adding more destructive AFP write endpoints.
The current NCP 0x2222/35/08 implementation intentionally supports only path-backed data-fork read opens. Resource-fork access still requires AppleDouble/resource-fork semantics, and write-open access must wait for an AFP write-fork path that preserves the existing NetWare share, lock, trustee, and file-handle behavior.
Extend the Linux smoke helper with a generic expected-completion option so unsupported paths can be asserted as successful negative coverage rather than treated as ad-hoc failures. The smoke suite now checks that write-open requests return 0x84 and resource-fork opens return 0x9c while the positive data-fork read-open path remains unchanged.
This keeps the currently incomplete Open File Fork semantics explicit before moving on to Create/Rename/Remove. It also gives Gitea reviewers a small incremental diff: helper option parsing, two suite probes, and README/TODO status updates only.
Tests:
- git diff --check
- bash -n tests/linux/afp_smoke_suite.sh
- gcc -Iinclude -I/mnt/data/stubs -fsyntax-only tests/linux/afp_open_file_fork_smoke.c
TODO:
- Implement AFP write-open semantics only after the server can route them through the existing NetWare handle/share/lock code paths.
- Implement resource-fork opens only after AppleDouble/libatalk resource-fork storage semantics are available.
Implement the WebSDK/nwafp.h NCP 0x2222/35 AFP subfunction 0x08, Open File Fork, for the same conservative path-backed subset that the current AFP smoke endpoints use.
The request is decoded as volume number, AFP Entry ID, fork selector, access mode, path length, and AFP path. Until persistent CNID/base-ID lookup exists, empty path / Entry-ID-only opens continue to fail with Invalid Path rather than pretending that the temporary stat-derived AFP Entry IDs are a durable namespace. The handler also keeps resource forks and write access negative for now, because those require AppleDouble/resource-fork and write-safe Finder metadata semantics that are not implemented yet.
For the supported data-fork read-only case, delegate to the existing NetWare open-file path via nw_creat_open_file(). The reply returns the normal six-byte NetWare file handle shape used by the AFP handle APIs followed by the current data-fork length. That lets follow-up smoke tests verify handle interoperability with AFP Get Entry ID From NetWare Handle and with the ordinary NetWare close path while keeping write/resource semantics conservative.
Add afp_open_file_fork_smoke so Linux ncpfs/libncp tests can exercise the endpoint through the same requester path as the other AFP probes. The helper closes the returned handle in the same connection and documents the expected data-fork-only coverage in tests/linux/README.md and TODO.md.
Tests: git diff --check
Tests: cmake --build build-off --target nwconn with ENABLE_NETATALK_LIBATALK=OFF
Tests: cmake --build build-on --target nwconn with ENABLE_NETATALK_LIBATALK=ON requested; local environment lacks libatalk headers/library so CMake reports the metadata backend disabled, but the target still builds and the new handler has no direct libatalk symbol references
Tests: gcc -fsyntax-only tests/linux/afp_open_file_fork_smoke.c with local ncpfs header stubs
TODO: add persistent CNID/base-ID lookup, AppleDouble/resource-fork open support, and write-safe AFP fork semantics before accepting resource-fork or write-mode opens.
