tests: accept duplicate original names in salvage scan
All checks were successful
Source release / source-package (push) Successful in 57s

This commit is contained in:
OpenAI
2026-05-31 16:41:50 +00:00
committed by Mario Fetka
parent 1b6e84b858
commit b39976c239
3 changed files with 16 additions and 3 deletions

View File

@@ -26,6 +26,8 @@ The current salvage tests cover:
`tests/salvage/salvage_smoke_suite.sh` is the single NCP integration entry
point. It creates and deletes the same file twice, then appends the `87/16` scan check,
so one report covers delete capture, history/versioning, and scan visibility.
The scan check expects duplicate sequence entries for the original deleted name;
the `Copy #1 of ...` history path is validated through the JSON sidecars.
The NCP smoke suite is intended to run as the same Unix user that normally runs
the test client, not necessarily as root. Pre-clean of old `.recycle` or

View File

@@ -114,7 +114,10 @@ The suite appends all current integration checks into one report:
- second delete: verifies version naming with `Copy #1 of NAME` when option `53`
contains the `v` flag,
- NCP `0x2222 / 87 / 16`: scans the same directory through the official
`ncpfs` salvage scan API and verifies that both deleted names are returned.
`ncpfs` salvage scan API. The NCP reply reports the original deleted file
name, so the suite expects at least two entries named `SLVGCHK.TXT`; the
`Copy #1 of ...` history name is verified through the `.salvage` JSON path
above.
The script does not call local `rm`/`unlink` for the tested live path; local
filesystem access is used only after the NCP delete to inspect the expected
@@ -148,6 +151,9 @@ separate top-level smoke scripts.
Runtime endpoint tests should be appended as the NCP salvage calls are
implemented. The suite already covers the initial `NCP 0x2222 / 87 / 16` scan
endpoint after the delete/history phases have created salvageable entries.
For duplicate original names, the scan endpoint exposes multiple sequence
entries with the same original name; the server-side `.salvage` metadata keeps
the selected recycle/history path.
- optional `NCP 0x2222 / 22 / 27` Scan Salvageable Files (old),
- `NCP 0x2222 / 87 / 17` Recover Salvageable File,

View File

@@ -285,8 +285,13 @@ run_ncp_salvage_scan() {
return 1
fi
grep -F "name=$BASENAME" "$scan_tmp" >/dev/null || fail_check "NCP salvage scan missing $BASENAME"
grep -F "name=$COPY_NAME" "$scan_tmp" >/dev/null || fail_check "NCP salvage scan missing $COPY_NAME"
local basename_count
basename_count=$(grep -F "name=$BASENAME" "$scan_tmp" | wc -l)
if [ "$basename_count" -lt 2 ]; then
fail_check "NCP salvage scan expected at least two $BASENAME entries, found $basename_count"
fi
emit "NCP salvage scan matched $basename_count entries named $BASENAME"
emit "note: 87/16 reports the original deleted name; the Copy #1 history name is verified via .salvage metadata above"
rm -f "$scan_tmp"
}