nc-inventar (Rust)

Paralleler WebDAV-Inventarlauf als Rust-Port von ~/bin/nc-inventar.py. Läuft einen Nextcloud-Baum per PROPFIND (Depth: 1) ab und schreibt pfad<TAB>groesse fort — die Eingabe für nc-sortier-check.

Warum

Das Python-Original holt jeden Ordner sequenziell. Bei ~70 ms pro PROPFIND bestimmt die Zahl der Ordner die Laufzeit. Der Rust-Port verteilt die Ordner auf mehrere Worker-Threads und wiederholt transiente Fehler, statt einen Teilbaum still auszulassen.

Bauen und installieren

cargo build --release
install -m 755 target/release/nc-inventar ~/bin/nc-inventar

Benutzen

nc-inventar [wurzel1,wurzel2] [ausgabe.tsv] [-j N]

• Default-Wurzel: SSD-Share
• Default-Ausgabe: /home/pandi/.hermes/cache/scratch/nc-inventar.tsv
• -j: Worker-Threads (Default 8). Mehr als 8 bringt bei diesem Server nichts, weil der Baum meist tiefer als breit ist.

Umgebung:

• NC_BASE — Basis-URL (Default: Nextcloud des Users aus ~/.hermes/.env)
• NC_USER / NC_PASS — überschreiben die Zugangsdaten aus ~/.hermes/.env

Übersprungen werden wie im Original alle Namen mit führendem Punkt sowie .Trash-1000, PC-Backups, balast, Transfer, .zfs, @eaDir.

Unterschiede zum Python-Original

• Parallel: mehrere PROPFIND gleichzeitig. Die Reihenfolge der Zeilen in der Ausgabedatei ist dadurch nicht deterministisch; der Dateisatz ist es.
• Retry: Transportfehler, 429 und 5xx werden bis zu zweimal wiederholt (200/400 ms Backoff). Ein abgerissener Request kostet damit keinen Teilbaum. Im Original blieb so ein Ordner kommentarlos draußen.
• Fehlerzähler: FEHLER-Zeilen nennen den Pfad und den HTTP-Status.
• Der User-Agent ist wie im Original curl/8.5.0 — der Server blockt python-urllib bzw. fremde Agents mit 403.

Tests

cargo test

• 5 Unit-Tests: XML-Parsing (Namensräume egal), Percent-Dekodierung inkl. kodiertem / (%2F), fehlende Größe = 0, Skip-Regeln, URL-Kodierung.
• 4 Integrationstests gegen tests/mock_dav.py (echter HTTP-Server, Basic-Auth, percent-kodierte hrefs, künstliche Latenz): vollständiger Dateisatz, gleicher Satz bei -j 1 und -j 8, Retry bei 503, Zeitgewinn durch Nebenläufigkeit.

Messung (2026-10-29)

Echter Baum SSD-Share/10_Vault (35 Ordner, 718 Dateien), Ausgabe sortiert byte-identisch zum Python-Original:

Python       2.56 s
Rust -j 8    0.53 s      ≈ 4,8× schneller

Synthetischer breiter Baum (61 Ordner, 101 Dateien, 25 ms Latenz pro Request):

-j 1    4.00 s
-j 4    0.98 s
-j 8    0.48 s      ≈ 8,3× schneller
-j 16   1.12 s      (Server wird zum Flaschenhals)