Directory.CreateDirectory warten bis abgeschlossen

Hallo zusammen,

es kommt manchmal vor, dass bei nutzen des Befehls "Directory.CreateDirectory" die Funktion danach nicht ausgeführt wird und ein Fehler kommt, dass das Verzeichnis nicht exisitiert.
Insbesondere wenn ein System mit "alter" HDD (nicht SSD) eingesetzt wird.

Frage:
Gibt es eine Möglichkeit auf Beendigung der Verzeichniserstellung zu warten?

Danke

Hallo Krumnix,

du bekommt ja ein Ergebnis zurück (DirectoryInfo) - wenn dies nicht null ist und es keine Exception beim Anlegen des Dirctories gegeben hat sollte es keine Probleme geben.

Ich hatte mit dem Befehl noch nie das Problem, dass die Bearbeitung zu lange gedauert hat - selbst auf de rguten alten 3,5" Diskette gab/gibt es da keine Probleme.
Führst du den Befehl evtl **asynchron **aus?

LG Stefan

Nein. Bis jetzt hatte ich dies auch nicht.
Aber auf einem "alten" Rechner (von 2017) bekomme ich immer ein Zugrifffehler, dass das Verzeichnis nicht da ist.
Ich hab mal aus "Langeweile" eine Wartezeit reingemacht und dann läuft es.
Das ist aber unsauber 🙂

Ich teste mal deinen Vorschlag. Danke

Wie sieht den dein Code aus?
Anhand der aktuellen Meldungen klingt es eher nach irgend einem asynchronen Ablauf, bei dem du auf das Verzeichnis zugreifst bevor es angelegt wurd.
Da die System.IO Klassen im Kern nur Wrapper für die Win32 File Api sind, kann es nur einen Fehler geben beim Aufruf.
Ein Aufruf mit einem Ergebnis ohne den Ordner anzulegen würde eigentlich eine Exception werfen.

Deshalb kann der Code nur "krum" sein.
Ansonsten spielt auch das alter des Systems keine Rolle.
Mein Rechner ist von 2018 und liefert auch korrekte Werte.

T-Virus

Gibt es eine Möglichkeit auf Beendigung der Verzeichniserstellung zu warten?

Nein, weil .NET hier keine Aktien im Spiel hat.
CreateDirectory (ist eine Methode, keine Funktion) ruft (auf Windows) die Win32 API ( CreateDirectoryA function (fileapi.h) - Win32 apps ) auf, die kein Warten anbietet.
Das Erstellen wiederum ist eine Metadata-Operation, was bedeutet, dass es "kurz" braucht, bis das Dateisystem das übernommen hat. Man kann sich das wie ein Commit vorstellen.
Daher ja: das von Dir festgestellte Verhalten ist bekannt und (aus Dateisystem-sicht) by design. Prinzipiell ist man auf keinem Datenträger davor geschützt; bei langsamen Datenträgern kommt das aber häufiger vor.

Dass die .NET Methode hier ein Info-Objekt zurück gibt, das hat nichts damit zutun.

Hier mal mein Code.

if (!Directory.Exists(path))
                  Directory.CreateDirectory(path);

if (Directory.Exists(path + "Release\\"))
                    Directory.Delete(path + "Release\\", true);

if (Directory.Exists(path))
{
                   string NewReleasePath = path + "Release\\" + FolderNameVersion + "\\" + FolderNameRelease;
                   File.Copy(ReleaseZIPName, NewReleasePath + "CopyRelease.zip", true);
                   Directory.Move(NewReleasePath, ProgramConfig.AppPath + "\\" + FolderNameRelease);
}

Vielleicht hab ich ja einen Denkfehler drin, fall es nix mit Abt seine Info zu tun hat.
Danke

Bis auf dass man Pfade nicht mit String Frickerleien zusammen baut, sondern mit Path.Combine ist das ok.
Deswegen kann es gut sein, dass Du einfach in die Fakten meines Beitrags läuft. Da hilft leider nur ein Delay.
Gibt aber leider keinen fixen Wert für einen Delay, da dies auf das OS und die Hardware/Systemauslastung ankommt bzw. unterschiedlich ist.

Kann das sein, dass Du hier etwas baust, das eigentlich ein Release System automatisch machen sollte..?
Frage nur wegen den Bezeichnern.

Kann das sein, dass Du hier etwas baust, das eigentlich ein Release System automatisch machen sollte..?

Nicht ganz. Für die Microcontroller in der Produktion benötigt es die neuste SW.
Dies wird von der Entwicklung in ein ZIP-File abgelegt. Will das Mail-System durch ein kleines Programm
ersetzen, dass die neuste Version aus dem Netzwerk auf die IB-Laptops lädt.

..und für sowas nutzt man eigentlich ein Release System wie zB Azure DevOps 🙂

Das Buildsystem erzeugt die Software und packt daraus ein Artefakt (zB Deine ZIP).
Das Release System stellt diese ZIP dann entsprechend zur Verfügung, zB auf einer Share oder einem anderen Storage.

Komme auch aus dem Maschinenbau und berate Maschinenbaufirmen seit vielen vielen Jahren solche Prozesse zu standardisieren und gerade zu ziehen 🙂

Ja, für reine SW, welche DevOps unterstützen gerne.
Für diese SW leider nicht. Basiert zwar auf Ansi C aber das Compilieren funktioniert in DevOps nicht.
Die Zeit dass dann irgendwann lauffähig zu bekommen steht in keiner Relation zum Nutzen.

Für mein Tool hab ich jetzt einen Tag gebraucht und bis auf diesen "Fehler" läuft es.
Mit einer Wartezeit dazwischen funktioniert es auch super.

DevOps ist ein Prozess und kein Tool.
Eigentlich jede Software lässt sich automatisiert im Build umsetzen. Hab das auch schon mit Ansi C für Controller gemacht.

Spätestens wenn man beachtet, dass man mindestens 10 Jahre jede Software und jedes Artefakt, wozu eine Firmware gehört, rechtlich aufbewahren muss, ist der Aufwand eines solchen Prozesses ein Vielfaches geringer - einfach weil es dafür standardisierte Wege gibt, die solche Vorgaben beachten.
So wusstest du davon vermutlich gar nichts und erfüllt vielleicht daher auch nicht diese Vorgabe 🙂

Aber ja bei DevOps ist das leider wie bei der IT Security, nur dass du bei DevOos mit einem kleinen Invest sehr viel Arbeit in der Zukunft sparen kannst. So hast du ein Tool dass meistens über die Zeit mehr Geld und Aufwand kostet als wenn du Standardmittel verwendet hättest.
Blinde Augen und taube Ohren: Es gibt immer das Budget vor einem Security Leak und nach einem Security Leak.