2482c2bd99
All checks were successful
Source release / source-package (push) Successful in 48s
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.