C# NTFS Transaktionen

[Ghost_Rider_R]

Hallo zusammen,

ist es mit C# eigentlich möglich Transaktionsgestützten Dateioperationen durchzuführen?

D.h. ich starte eine Transaktion, lösche zwei Dateien, ändere drei weitere Dateien, merke
dass ich da eben einen Murks gemacht habe und mach einfach wieder einen Rollback,
so wie es unter T-SQL möglich ist?

NTFS unterstützt dies ja prinzipiell, jedoch wird es wohl nicht mehr empfohlen, so wie ich das
gelesen habe, aber hier habe ich auch nur gefährliches Halbwissen.

Drittanbieter Bibliotheken möchte ich nicht verwenden.

Danke für die Info.

LG Ghost

 

[tRITON]

Datei Zugriffe sind meist Asyncron. Daher weiß Operation 2 nichts von Operation 1

Wenn du das Programm selbst schreibst, dann hast ja auch den Programmfluss selbst im Griff.

Wenn Du erst löscht und dann "hoffst" das der Rest sauber läuft solltest Du dein Programmkonzept überdenken

 

[Ghost_Rider_R]

Danke. Das heißt unter C# gibt es so nicht direkt ein implementiertes Transaktionskonzept wie ich es aus dem Datenbankbereich kenne?

Dateioperationen würde ich natürlich nach Möglichkeit anders gestalten, aber es könnte ja sein, dass man z.B. von Datei 1 etwas in Datei 2 schreiben möchte und nachdem das in Datei 2 geschrieben wurde stürzt das NAS ab, auf dem Datei 1 lag und ich konnte den das was ich rüber kopiert habe nicht mehr aus Datei 1 entfernen z.B. einen Umsatz o.Ä. Ist ein blödes Beispiel, aber Ihr wisst was ich meine :-)

 

[KitKat::new()]

Einmal kurz gegoogled:
https://docs.microsoft.com/de-de/windows/win32/fileio/transactional-ntfs-portal

 

[gymfan]

ist es mit C# eigentlich möglich Transaktionsgestützten Dateioperationen durchzuführen?

Da Du mit C# (unter Windows) jede Win32 API aufrufen kannst, kannst Du Dir auch entsprechende Funktionen/Wrapper erstellen, die TxF nutzen.

Solche Warnungen muss man dann halt einfach ignorieren und nicht damit rechnen, dass irgendwann bei einer solchen Aktion der Strom ausfällt oder das Programm selber bzw. das System (auch aus ganz anderen Gründen) abstützt.
https://docs.microsoft.com/de-de/windows/win32/fileio/deploying-transactional-ntfs

NTFS unterstützt dies ja prinzipiell, jedoch wird es wohl nicht mehr empfohlen, so wie ich das
gelesen habe, aber hier habe ich auch nur gefährliches Halbwissen.

Mehr wie das Wissen aus der MSDN habe ich dazu auch nicht, mir war noch nicht einmal klar, dass MS sowas implementiert hat (aber NTFS kann so einiges, das mich bisher weder kenne noch jemals vermisst habe).

Drittanbieter Bibliotheken möchte ich nicht verwenden.

Dann musst Du Dir wohl alle Win32-Funktionen selber mappen und alle Dateioperationen darüber abbilden. Spass macht das vermutlich nicht (die Prüfung, ob die Dateien überhaupt auf einem NTFS Laufwerk liegen, sollte man auch nicht vergessen, wenn das ganze kein 100% geschlossenes System ohne Konfigurationsmöglichkeiten ist).

Wenn du das Programm selbst schreibst, dann hast ja auch den Programmfluss selbst im Griff.

Genau dafür liefert MS sogar ein paar schöne Beispiele, bei denen man Transaktionen auf Dateisystemeben durch sinnvoll einsetzen könnte. Und wenn es nur das gleichzeitige Update von mehreren Dateien ist, die man konsistent ändern möchte, deren Lesezugriff durch andere Programme man aber nicht steuern kann (Update einer rein textbasierten Webseite auf dem produktiven Server).

Dateioperationen würde ich natürlich nach Möglichkeit anders gestalten, aber es könnte ja sein, dass man z.B. von Datei 1 etwas in Datei 2 schreiben möchte und nachdem das in Datei 2 geschrieben wurde stürzt das NAS ab, auf dem Datei 1 lag und ich konnte den das was ich rüber kopiert habe nicht mehr aus Datei 1 entfernen z.B. einen Umsatz o.Ä. Ist ein blödes Beispiel, aber Ihr wisst was ich meine :-)

Das NAS läuft also mit NTFS und das Laufwerk ist auf dem Client auch als NTFS eingebunden?

 

[Ghost_Rider_R]

Das war nur ein fiktives Beispiel und ich hatte da tatsächlich daran gedacht mir einen eigenen Wrapper zu schreiben, jedoch macht mich die Tatsache stutzig, dass MS hier selbst auf ,,andere" Techniken verweist und TxF scheinbar aufs Abstellgleis stellt, zumindest hört es sich für mich so an, daher frage ich mich, ob es der Aufwand (wäre nur Just 4 Fun gewesen) überhaupt wert ist oder ob es nicht eine bessere ,,Nachfolge"-Technik gibt. Wenn ja, was wäre das Stichwort hierzu oder wie wäre die empfohlene Vorgehensweise?

 

[gymfan]

Mir ist völlig unklar, was MS an Voraussetzungen an die HW hat und warum sie selber schreiben, dass sie dem ganzen nur auf Server-HW (SAS Platten) trauen. Vermutlich geht es u.A. darum, dass diese Laufwerke auch bei Stromausfall noch ihren Schreibcache auf die HDD/SSD schreiben.

Und da es eben nur mit NTFS funktioniert, wäre das für meine Anwendungen nichts, dafür nutze ich selber viel zu häufig ExFAT oder Samba-Shares. Damit bliebe nur übrig, sich selber etwas auszudenken, was dann vermutlich nur mit der eigenen Anwendung hinreichend gut funktioniert. Ohne die Unterstützung des OS (also elementare Dateioperationen beim Schließen einer Transaktion) wird das ohne Einschränkungen/Randbedingungen nicht funktionieren. Als Anwendung ist es unmöglich, mehrere Dateien zeitgleich (aus dem Blickwinkel anderer Applikationen) auf dem Laufwerk zu aktualisieren.

Das mag für Deine Anwendung aber völlig irrelevant sein, wenn es darum geht, mehrere Datein, über welche Du exklusiv die volle Kontrolle hast, synchron zu ändern/löschen. Dein Beispiel kann damit aber immer noch auftreten, da Du am Ende der Transaktion als Anwendung nur hoffen kannst, dass das NAS alle Dateien auch schreibt und nicht mittendrin abstürtzt.

Mir ist kein Dateisystem bekannt, das Transaktionen (vergleichbar zu Datenbanken) bieten würde. Auch Systeme mit Copy-on-Write (z.B. BTRFS) sorgen damit nur dafür, dass einzelne Dateien garantiert nicht überschrieben werden. Transaktionen über mehrere Daten kennt das m.W.n. aber nicht.

 

[Zonk91]

Ich hatte mal einen ähnlichen Anwendungsfall. Ich hab das dann so gebaut, dass ich beim Start der "Transaktion" entsprechend die Datei über den Namen markiert habe (z.B. myfile.txt.deleted, .editstarted, .editfinished etc.). Und beim Abschluss aller anderen Operationen dann erst beispielsweise gelöscht und dann die Dateinamen finalisiert. Müsste man sich natürlich im Einzelfall anschauen ob das den Anforderungen genügt. Wenn der Strom dann an neuralgischen Stellen ausfällt, ist das natürlich trotzdem ein Problem.