Der Heimrechner ist beim ersten Lauf haengengeblieben. Ursache:
d4rk_media-2026-08-11-2307.tar.gz 327030051 Archive, ReparsePoint
d4rk_media-2026-08-12-0430.tar.gz 352258706 4199968
4199968 = 0x401620:
0x400000 RECALL_ON_DATA_ACCESS beim Zugriff erst herunterladen
0x001000 OFFLINE Inhalt liegt nicht hier
0x000400 ReparsePoint
0x000200 SPARSE_FILE
0x000020 Archive
Der Nextcloud-Client hatte "virtuelle Dateien" aktiviert: im Ordner steht ein
Verweis mit der richtigen GROESSE, aber ohne Inhalt. robocopy fasst alle an,
und jedes Anfassen loest einen Download aus -- bei fuenf Archiven 1,7 GB auf
einmal, waehrend Windows blockierte.
Das Skript prueft das jetzt VORHER und bricht ab, ohne etwas zu kopieren oder
zu loeschen. Mit dem Hinweis, wo man es abstellt, und woran man es im Explorer
sieht: Wolken-Symbol statt gruenem Haken.
An einer Datei mit gesetztem OFFLINE-Attribut nachgemessen -- erkannt und
abgebrochen; ohne das Attribut laeuft es normal durch.
Die Lehre ist dieselbe wie den ganzen Tag: eine Groessenangabe ist keine Datei.
robocopy hat die 336 MB geglaubt, die dastanden, statt zu pruefen, ob sie da
sind.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gemeldet: "danach nur ==> Nachsehen und dann passiert nichts mehr."
Zwischen der Ueberschrift und der ersten Ausgabe liefen drei Schritte, die
alle drei minutenlang blockieren koennen -- Test-Path, New-Item und
Resolve-Path, wenn ein Pfad auf eine Netzfreigabe oder eine schlafende Platte
zeigt. Welcher davon stand, war von aussen nicht zu sehen.
Jetzt sagt jeder Schritt VORHER, was er tut. Eine Ausgabe, die erst nach dem
Blockieren kommt, hilft genau dann nicht, wenn man sie braucht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Weg nach draussen fuehrt jetzt ueber die Nextcloud, die ohnehin jede Nacht
ein geprueftes Archiv bekommt: der Desktop-Client zieht den Ordner auf die
Platte zu Hause. Serverseitig ist dafuer nichts noetig -- kein Konto, kein
Schluessel, kein Skript.
WARUM DAS ALLEIN NICHT REICHT: der Client gleicht in BEIDE Richtungen ab.
Verschwinden die Archive auf dem Server -- Trojaner, Fehlgriff, kaputter
Auftrag --, loescht er sie auch zu Hause. Der synchronisierte Ordner ist eine
Kopie, aber keine Sicherung.
Dieses Skript kopiert daraus in einen zweiten Ordner, den der Client nicht
kennt, und bricht damit die Kette: was einmal dort liegt, bleibt liegen, bis
die Aufbewahrungsfrist es wegraeumt. Der Server kann es nicht mehr erreichen.
robocopy OHNE /MIR, und das ist der ganze Punkt -- /MIR wuerde das Ziel dem
Quellordner angleichen und dort Geloeschtes mitloeschen.
Es weigert sich ausserdem, wenn das Ziel IM synchronisierten Ordner liegt: dann
wuerde der Client die Kopien wieder hochladen und alles waere umsonst.
UND ES MELDET SICH, WENN NICHTS MEHR ANKOMMT. Ein Kopierauftrag, der still
aufhoert, ist genau der Schaden, gegen den er gebaut ist: man glaubt, man haette
eine Sicherung, und merkt es an dem Tag, an dem man sie braucht. Gemeldet wird
nur bei Zustandswechsel -- eine taegliche "alles in Ordnung"-Meldung liest nach
einer Woche niemand mehr, und dann auch die eine nicht, auf die es ankommt.
An Wegwerf-Ordnern durchgespielt, alle Faelle einzeln:
drei Archive holen -> 3 neu
Datei in der QUELLE geloescht -> bleibt im Ziel <- der Punkt
Aufbewahrung auf 2 -> aeltestes entfernt
seit 8 Tagen nichts Neues -> Alarm
zweiter Lauf -> bleibt still
neues Archiv kommt an -> Entwarnung
Ziel im Quellordner -> abgelehnt
Der vierte Test hat beim ersten Anlauf nichts gemessen: ich hatte die KOPIEN
gealtert statt der Quelle, und robocopy hat sie korrekt neu geholt. Ein Test,
der das Falsche misst, meldet "in Ordnung" und wird geglaubt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D4rkst3randClaude Opus 5