mars_nwe/mars-nwe
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases 2 Wiki Activity

tests: add AFP open file fork write smoke
All checks were successful
Source release / source-package (push) Successful in 52s
Details

Browse Source
This commit is contained in:
Mario Fetka
2026-05-30 21:12:58 +00:00
parent 330d20a0e1
commit 9c1787345d
3 changed files with 38 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
tests/linux/README.md
View File

@@ -501,11 +501,13 @@ request:
NCP 0x2222/35/08 AFP Open File Fork
```
The first mars_nwe implementation is deliberately conservative. It supports
raw `VOL:`-style path requests such as `SYS:` or `HOME:` with base Entry ID
zero, opens only the AFP data fork, and only for read access. For path-backed
requests, mars_nwe resolves the effective NetWare volume from the raw path
prefix instead of assuming volume 0. On success the server returns the
mars_nwe supports raw `VOL:`-style path requests such as `SYS:` or
`HOME:` with base Entry ID zero and opens only the AFP data fork. Read and
write data-fork opens are routed through the existing NetWare file open/share
path (`nw_creat_open_file()`/`file_creat_open()`), so trustee rights, read-only
attributes, and share-deny checks stay shared with regular NCP file opens. For
path-backed requests, mars_nwe resolves the effective NetWare volume from the
raw path prefix instead of assuming volume 0. On success the server returns the
normal six-byte NetWare file handle shape used by AFP handle APIs plus the
current data-fork length. The smoke helper immediately closes the returned
NetWare file handle in the same connection.
@@ -522,7 +524,7 @@ A file on another exported volume should be tested with its raw volume prefix
volume number, while still showing the request volume byte separately.
A successful reply prints the returned NetWare handle, the requested fork, the
read access mode, and the data-fork length. A verified runtime smoke run
requested access mode, and the data-fork length. A verified runtime smoke run
against the standard DOS utility files produced:
```text
@@ -540,20 +542,21 @@ AFP Open File Fork: vol=0 request_vol=0 entry=0x00000000 fork=0 access=0x01 path
The exact handle number is connection-local and must not be reused across
processes. The exact `fork_len` depends on the backing file contents.
Resource-fork opens (`--fork 1`), write access (`--access 2`), and
Entry-ID-only open remain unsupported until persistent CNID/base-ID lookup,
AppleDouble/resource-fork, and AFP write-open semantics are available. The
smoke helper can assert those conservative rejections explicitly:
Write access is tested on a temporary file created through AFP Create File and
then removed with AFP Delete:
```sh
./tests/linux/afp_open_file_fork_smoke --expect-completion 0x84 --access 0x02 -S MARS -U SUPERVISOR -P secret SYS:PUBLIC/pmdflts.ini
./tests/linux/afp_open_file_fork_smoke --expect-completion 0x9c --fork 1 -S MARS -U SUPERVISOR -P secret SYS:PUBLIC/pmdflts.ini
./tests/linux/afp_create_file_smoke -S MARS -U SUPERVISOR -P secret SYS:PUBLIC/afpwrit
./tests/linux/afp_open_file_fork_smoke --access 0x02 -S MARS -U SUPERVISOR -P secret SYS:PUBLIC/afpwrit
./tests/linux/afp_delete_smoke -S MARS -U SUPERVISOR -P secret SYS:PUBLIC/afpwrit
```
A rejected write-open probe should print:
Resource-fork opens (`--fork 1`) and Entry-ID-only open remain unsupported until
AppleDouble/resource-fork support and persistent CNID/base-ID lookup exist. The
smoke helper can assert the resource-fork rejection explicitly:
```text
AFP Open File Fork returned expected completion 0x84: path=SYS:PUBLIC/pmdflts.ini fork=0 access=0x02
```sh
./tests/linux/afp_open_file_fork_smoke --expect-completion 0x9c --fork 1 -S MARS -U SUPERVISOR -P secret SYS:PUBLIC/pmdflts.ini
```
A rejected resource-fork probe should print: