HitonabiandClaude Fable 5
c44bfa6daa
- Faktenfehler korrigiert: Gitea ist oeffentlich per HTTPS erreichbar (gemessen, § 3.6) — Updates kommen direkt daraus, Drei-Wege-Tabelle weg - node:sqlite in Electron 44 im utilityProcess bewiesen (§ 3.4, beweise/sqlite-main.js + sqlite-kern.js) — better-sqlite3 nicht noetig - Disc-Wache umgedreht: 3-Sekunden-Takt ist Plan A, WM_DEVICECHANGE spaetere Verfeinerung (§ 5) - Entscheid 7 verschaerft: main-Aufraeumen sofort, nicht erst nach W-6 - Entscheid 9 neu: Zielgruppe Bekannte mit Link, Lizenztexte liegen bei - MakeMKV-Lage tagesaktuell bestaetigt (Key bis Ende September 2026, Kaufseite defekt = Dauerzustand seit Sommer 2025) - Electron-Pflege-Regel (§ 6.8), npm-11-Sperre trifft auch Electron selbst (§ 3.5), Release = drei Dateien, 4K-Schluesselkette in § 10, Risikotabelle aktualisiert Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
136 lines
4.8 KiB
Markdown
136 lines
4.8 KiB
Markdown
# Beweise — die Messungen zu KONZEPT-WINDOWS.md § 3
|
|
|
|
Diese zwei Skripte sind die Grundlage für die Entscheidung, Rippy v5 in
|
|
TypeScript/Node zu bauen. Sie beantworten die einzige Frage, an der das ganze
|
|
Konzept hängt:
|
|
|
|
> **Kann Node überhaupt alles, was Rippy am Laufwerk braucht?**
|
|
|
|
Wäre die Antwort nein gewesen, wäre das Konzept wertlos gewesen. Deshalb sind
|
|
sie zuerst gelaufen — vor der ersten Zeile Konzept.
|
|
|
|
`AGENTS.md` Regel D: *„Externe Schnittstellen NIE aus dem Kopf."*
|
|
|
|
---
|
|
|
|
## Nachstellen
|
|
|
|
```
|
|
npm install koffi
|
|
node laufwerk.js
|
|
```
|
|
|
|
Gemessen am 30.08.2026 mit Node v24.19.0, koffi 3.1.6, an einem
|
|
HL-DT-ST BD-RE BU40N (USB) mit eingelegter Blu-ray.
|
|
|
|
---
|
|
|
|
## `laufwerk.js` — Win32-Laufwerkszugriff
|
|
|
|
Ruft dieselben Steuercodes auf wie `src/rippy/drives/win_ioctl.py` im
|
|
Docker-Zweig. **Nur lesend** — kein Auswerfen, kein Verriegeln.
|
|
|
|
```
|
|
1. GetLogicalDrives + GetDriveTypeW -> optische Laufwerke: [ 'G' ]
|
|
2. CreateFileW \\.\G: (Zugriff 0) -> offen
|
|
CreateFileW \\.\G: (GENERIC_READ) -> offen
|
|
3. IOCTL_STORAGE_QUERY_PROPERTY -> Hersteller: HL-DT-ST | Modell: BD-RE BU40N
|
|
| Rev: 1.03 | Serial: 0025114C0149
|
|
4. IOCTL_STORAGE_CHECK_VERIFY2 -> Medium eingelegt
|
|
5. IOCTL_CDROM_DISK_TYPE -> Win32-Fehler 50
|
|
6. IOCTL_DISK_GET_LENGTH_INFO -> 33.759.690.752 Bytes (33,76 GB) => Blu-ray
|
|
```
|
|
|
|
**Punkt 5 ist kein Fehlschlag.** Fehler 50 ist `ERROR_NOT_SUPPORTED` — genau
|
|
das, was der Python-Treiber an diesem Laufwerk auch sieht (`SAVEPOINT.md`,
|
|
v4.0-rc11, Abschnitt „Das Laufwerk"). Node verhält sich identisch. Die Lehre
|
|
steht im alten Code und gilt weiter: **Die Disc-Einordnung darf sich nicht auf
|
|
`IOCTL_CDROM_DISK_TYPE` verlassen — die Größe ist der verlässliche Weg.**
|
|
|
|
Punkt 2 zeigt die Unterscheidung, die in rc11 teuer war: `Zugriff 0` fragt das
|
|
**Gerät**, `GENERIC_READ` fragt das **Medium**. Bei einer gestörten Disc
|
|
scheitert das zweite und das erste geht weiter — wer nur eins probiert, hält
|
|
ein antwortendes Laufwerk für tot.
|
|
|
|
---
|
|
|
|
## `leine.js` — die Prozess-Leine (Job Object)
|
|
|
|
Stellt den Befund aus `SAVEPOINT.md` v4.0-rc10 nach: Windows räumt
|
|
Kindprozesse **nicht** auf. Ein hart beendeter Rippy hinterlässt ein
|
|
`makemkvcon`, das das Laufwerk festhält, und jeder spätere Rip scheitert.
|
|
|
|
Das Skript setzt eine Arbeitsgruppe mit `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`,
|
|
startet ein langlebiges Kind und lässt sich dann hart abschießen —
|
|
`taskkill /F` **ohne** `/T`, also genau das, was bei einem Absturz und beim
|
|
Drüber-Installieren passiert.
|
|
|
|
```
|
|
1. CreateJobObjectW -> Arbeitsgruppe angelegt
|
|
2. SetInformationJobObject -> KILL_ON_JOB_CLOSE gesetzt
|
|
3. AssignProcessToJobObject -> dieser Prozess hängt in der Gruppe
|
|
4. Kindprozess gestartet, PID 16040
|
|
|
|
vor dem Abschuss: Eltern lebt: True Kind lebt: True
|
|
taskkill /F /PID 29488 -> ERFOLGREICH
|
|
danach: Eltern lebt: False Kind lebt: False
|
|
```
|
|
|
|
Nachstellen (PowerShell):
|
|
|
|
```powershell
|
|
$p = Start-Process node -ArgumentList "leine.js" -PassThru -RedirectStandardOutput out.txt
|
|
Start-Sleep 3
|
|
$kind = (Select-String -Path out.txt -Pattern 'KIND-PID=(\d+)').Matches[0].Groups[1].Value
|
|
taskkill /F /PID $p.Id
|
|
Start-Sleep 2
|
|
Get-Process -Id $kind -ErrorAction SilentlyContinue # muss LEER sein
|
|
```
|
|
|
|
---
|
|
|
|
## `sqlite-main.js` + `sqlite-kern.js` — node:sqlite in Electron
|
|
|
|
Beantwortet die Frage, die in der ersten Fassung des Konzepts als ⚠️ offen
|
|
stand: Electron baut sein Node mit eigenen Flags — ist `node:sqlite` dort
|
|
überhaupt vorhanden?
|
|
|
|
Gemessen am 30.08.2026 mit **Electron 44.0.0**, und zwar im
|
|
**utilityProcess** — dem Kontext, in dem Rippy v5 seine Datenbank betreiben
|
|
wird (`kern/speicher/db.ts`), nicht bloß im Node-Modus der Binary:
|
|
|
|
```
|
|
KERN-ANTWORT: {"ok":true,"wert":"geht","node":"24.18.1"}
|
|
Kern beendet mit 0
|
|
```
|
|
|
|
**Antwort: ja.** Die im Konzept vorgesehene Rückfallebene `better-sqlite3`
|
|
wird nicht gebraucht. (Zur Einordnung: In Node 24.19.0 pur war dieselbe
|
|
Messung zuvor ebenfalls grün.)
|
|
|
|
Nachstellen:
|
|
|
|
```
|
|
npm install electron@44 --no-save
|
|
node node_modules/electron/install.js
|
|
./node_modules/electron/dist/electron.exe sqlite-main.js
|
|
```
|
|
|
|
Die zweite Zeile ist kein Versehen — siehe nächster Abschnitt.
|
|
|
|
---
|
|
|
|
## npm 11 blockiert Install-Skripte — und das trifft Electron selbst
|
|
|
|
```
|
|
npm warn allow-scripts koffi@3.1.6 (install: node ./cnoke.cjs -P . --prebuild --release)
|
|
```
|
|
|
|
koffi lädt trotzdem — es bringt vorgebaute Binärdateien mit. **Electron
|
|
trifft die Sperre härter:** Sein Install-Skript lädt die eigentliche
|
|
Programmdatei herunter; wird es geblockt, liegt nach `npm install` ein
|
|
Paket **ohne `dist/electron.exe`** da, und nichts startet. Am 30.08.2026
|
|
beim sqlite-Beweis selbst hineingelaufen; `node node_modules/electron/install.js`
|
|
holt die Binary nach. Beides gehört in die Bau-Anleitung, sonst sucht eines
|
|
Tages jemand an der falschen Stelle.
|