Hier:
https://github.com/PeterPawn/YourFr...60b19387370/eva_tools/EVA-FTP-Client.ps1#L407 wird nach dem Ende der Datenübertragung und dem Schließen von Stream, Datei und Socket noch für fünf Sekunden gewartet, damit die Box Zeit hat, mit einer passenden Meldung (
226 oder
553) zu reagieren ... aber die Schleife wird auch hier schon abgebrochen (
$sending = false).
Die Box reagiert halt auf einen Upload eines Images, das sie dann starten kann (ansonsten kommt
553), nur noch mit dem Schließen der (Control-)Connection des FTP-Servers und NICHT mit einer weiteren Meldung, die man dann auswerten könnte - der Verbindungsabbruch an sich ist auch schon das einzige Anzeichen, welches man für den "Erfolg" auswerten könnte. Irgendwelche anderen Meldungen gibt es nur bei Mißerfolgen.
Offenbar kommt es in der Zwischenzeit bei Dir aber noch zu anderen, unerwarteten Problemen, die dann in diesen
catch-Block (
https://github.com/PeterPawn/YourFr...60b19387370/eva_tools/EVA-FTP-Client.ps1#L424) laufen und dort wieder den Rückgabewert (
$result) auf
False ändern - womit das
BootDeviceFromImage dann seinerseits in die Fehlerbehandlung für nicht erfolgreiches
WriteFile läuft (
https://github.com/PeterPawn/YourFr...60b19387370/eva_tools/EVA-FTP-Client.ps1#L310) und versucht, die Speichereinstellung wieder auf ihre Ausgangswerte zu setzen.
Das ist also nicht mit einer so simplen Änderung getan ... dazu muß man entweder ermitteln, welche Exceptions denn tatsächlich im
WriteFile auftauchen und die ggf. genauer untersuchen, damit man entscheiden kann, ob man vielleicht auf das Setzen von
$result verzichten kann in dem
catch-Block. Aber ich zäume solche Pferde nur ungern von hinten auf ... deshalb habe ich auch nach einem Netzwerk-Mitschnitt gefragt, weil man in diesem anhand der Zeitstempel der Pakete erst mal beginnen kann, sich das Timing der verschiedenen Aktionen zu vergegenwärtigen.
Stellt sich dann heraus, daß der Mitschnitt eigentlich gut aussieht und keine offensichtlichen Anzeichen für Probleme enthält, kann/muß man sich die Exceptions in dem
catch-Block in
WriteFile eben genauer ansehen - die werden im Moment ja gar nicht ausgewertet, weil sie im "normalen Ablauf" selten bis nie auftreten und jede Exception daher als "Fehler" angesehen wird.
Und wie schon angedeutet ... ich hatte nicht geschrieben, daß Du einfach nur einen Timeout-Wert irgendwo im Skript "hochsetzen" müßtest - ich wollte zum Ausdruck bringen, daß ich mich dann mit einem zusätzlichen "passenden" Parameter (wenn der überhaupt notwendig sein sollte) anfreunden könnte und den einbauen würde. Davon, daß dieser Parameter dann irgendeinen Timeout-Wert erhöhen oder verringern würde, steht bei mir gar nichts, wenn Du #121 noch einmal liest. Leider sind auch nicht alle genutzten .NET-Interfaces dann "native" in PowerShell - daher endet eine Kette von Exceptions auch schon mal in irgendwelchem Glue-Code (zwischen .NET und PS) und gibt nicht immer ausreichend Aufschluß (in "Textform") über den tatsächlichen Fehler.
EDIT: Wobei ich mich hinsichtlich der Meldungen geirrt habe ... auch beim Upload in den Speicher kommt noch ein
226 Transfer completed - da wäre es tatsächlich denkbar, daß das fünfsekündige Warten, bevor dann versucht wird, diese Nachricht im Control-Channel zu lesen, zu kurz ist und daher
$result nicht auf
True gesetzt wird (was bei
226 ja erfolgen würde).
