Mini-Umfrage: Wer von euch benutzt Transactions auf Windows?

[Assarbad]

Mit Windows Vista wurden Transactions für verschiedene Dateisystemoperationen eingeführt. Wer von euch benutzt die aktiv in Programmen die von anderen Leuten als euch selbst benutzt werden? Beispiel DeleteFileTransacted ...

Das Lustige ist ja, daß Microsoft die seit Windows 8 oder so schon wieder als "Deprecated" führt.

[EWeiss]

Zitat:

Das Lustige ist ja, daß Microsoft die seit Windows 8 oder so schon wieder als "Deprecated" führt.

Dann macht es keinen sinn weiterhin darüber nachzudenken, geschweige denn zu diskutieren.

gruss

[Assarbad]

Zitat:

Zitat von EWeiss (Beitrag 1417545)

Zitat:

Das Lustige ist ja, daß Microsoft die seit Windows 8 oder so schon wieder als "Deprecated" führt.

Dann macht es keinen sinn weiterhin darüber nachzudenken, geschweige denn zu diskutieren.

Doch, denn ein angeblicher Grund für die schnelle Abschaffung ist, daß es zu selten benutzt wurde. Daher diese Mini-Umfrage. Wenn du kein Interesse daran hast, brauchst du dich ja nicht beteiligen :zwinker:

[jaenicke]

Wir benutzen eine der genannten Alternativen, nämlich simples Ersetzen der Dateien. Sprich wir schreiben in eine temporäre Datei und benennen diese dann am Ende in den richtigen Dateinamen um. Ich sehe auch sonst in dafür in Frage kommenden Projekten niemanden, der dafür diese Transaktionen benutzt.

[hoika]

Hallo,
zusätzlich sollte man eine leere Datei mit dem richtigen Dateinamen erzeugen und exclusiv öffnen,
um zu verhindern, dass jemand während der Dateiarbeit den Dateinamen "kapert".
So macht es u.a. Firefox beim Download.

[jobo]

Ich nutze es nicht, ich kenne niemand, der es tut, aber:
bei dem Begriff "Transaction" zuckt es ja bei mir. Für mich ist das jedoch ein Datenbankbegriff. Darf man sich das unter Windows funktional ebenso vorstellen? Scheinbar nicht ganz, die API Doku aus dem Link scheint mir jedenfalls schon inkonstitente Zustände zu beschreiben:
The file is deleted after the last transacted writer handle to the file is closed, provided that the transaction is still active. If a file has been marked for deletion and a transacted writer handle is still open after the transaction completes, the file will not be deleted.
Vielleicht ist es auch noch zu früh für mich, aber der Grund der Abschaffung könnte ja auch ein Designproblem/ Fehlkonstruktion sein.

[Whookie]

Ich benutze die auch nicht und mache das so wie jaenicke.

[Der schöne Günther]

Als ich es fand war ich auch interessiert, aber schon vor Jahren war klar: Nein.

Schon vor vier Jahren sagte bereits ein schlauer Mann:

Zitat:

Zitat von himitsu (Beitrag 1279799)

ich ab nur noch nie gesehn, daß das wirklich jemand mal benutzt hätte

Ich denke die sind allerdings nicht erst seit Windows 8 deprecated. Und dass Microsoft etwas strongly recommended sehe ich auch nicht oft. Bei der Geschwindigkeit wie sich Windows in den letzten Jahren ändert würde ich mich auch nie im Leben darauf verlassen dass so etwas noch lange verfügbar bleibt.

[Assarbad]

Zitat:

Zitat von jaenicke (Beitrag 1417551)

Wir benutzen eine der genannten Alternativen, nämlich simples Ersetzen der Dateien. Sprich wir schreiben in eine temporäre Datei und benennen diese dann am Ende in den richtigen Dateinamen um. Ich sehe auch sonst in dafür in Frage kommenden Projekten niemanden, der dafür diese Transaktionen benutzt.

Nun wäre die Frage wie ihr die Dateien umbenennt. MoveFileEx / MoveFile wäre zwar scheinbar richtig, aber nur scheinbar. Denn wenn das fehlschlägt, wird intern ne Kopie versucht. Und schwupp ist deine vermeintlich atomare Aktion nicht mehr atomar. Das hier ist die einzige Methode wenn man sich an die Win32-API hält, wie man hier atomares Verhalten erreicht. Einzige Alternative dazu ist der Rückgriff auf die NT Native API an deren Verfügbarkeit für Delphianer ich selbst vor vielen Jahren gearbeitet habe.

ReactOS versucht das Verhalten von Windows bestmöglich nachzuempfinden und hier findest du die Implementierung von MoveFileExW ohne daß du WinDbg oder nen Disassembler bemühen müßtest. Speziell geht es um diese Zeile.

Das einzige Delphi was ich noch installiert habe ist in einer abgewrackten alten XP VM und das ist ein Delphi 7. Jetzt weeß ick natürlich nich ob sich das geändert hat, aber mit RenameFile in SysUtils.pas aus Delphi-7-Zeiten benutzt du auch MoveFile. Haste also auch den Hut auf ...

Zitat:

Zitat von jobo (Beitrag 1417555)

Ich nutze es nicht, ich kenne niemand, der es tut, aber:
bei dem Begriff "Transaction" zuckt es ja bei mir. Für mich ist das jedoch ein Datenbankbegriff. Darf man sich das unter Windows funktional ebenso vorstellen? Scheinbar nicht ganz, die API Doku aus dem Link scheint mir jedenfalls schon inkonstitente Zustände zu beschreiben:
The file is deleted after the last transacted writer handle to the file is closed, provided that the transaction is still active. If a file has been marked for deletion and a transacted writer handle is still open after the transaction completes, the file will not be deleted.

Hmm, erstens: was anderes ist ein Dateisystem als eine Datenbank? Es ist eine domänenspezifische Datenbank, aber es ist eine Datenbank. Und bei der Registry (TxR) wärst du damit vielleicht auch ohne diese Erklärung damit d'accord gegangen. TxR scheint übrigens im Gegensatz zu den Dateisystemfunktionen nach wie vor ein Ding zu sein.

Zweitens: mir scheint du mißverstehst wie das normale DeleteFile funktioniert. DeleteFile löscht nicht etwa, wie der Name es suggeriert, die Datei. Stattdessen setzt diese Funktion - übrigens mit der gleichen Methode die ich oben schon erwähnte (SetFileInformationByHandle) - ein Flag. Wenn die Funktion zum Aufrufer zurückkehrt muß die Datei noch lange nicht gelöscht sein (in NTFS kann das durchaus mal ein paar Sekunden dauern, wenn das System gerade "zu tun" hat). Wer mehr wissen will, schaut sich das hier an. Unter der Haube werkelt da NtSetInformationFile, welches Treiberentwicklern ein Begriff sein dürfte. SetFileInformationByHandle ist meines Wissens für die unterstützten Klassen eine 1:1-Abbildung der darunterliegenden NT Native API.

Kurzum DeleteFile ist ebensowenig atomar wie MoveFileEx. Hammer, oder? ;)

Und "schlimmer" noch, bei näherer Betrachtung ist die vermeintliche Inkonsistenz nicht so inkonsistent wie du meinst. Transaktionen geben ja Garantien. Wenn nun also eine Datei, bspw. durch einen anderen Prozeß, zum Löschen vorgemerkt wird, dann

(Ach ja, intern benutzt MoveFile MoveFileEx, also falls hier jemand mitliest und MoveFile benutzt und sich in Sicherheit wog, dem kann ich diesen Zahn umgehend ziehen :zwinker: ... siehe oben)

Zitat:

Zitat von jobo (Beitrag 1417555)

Vielleicht ist es auch noch zu früh für mich, aber der Grund der Abschaffung könnte ja auch ein Designproblem/ Fehlkonstruktion sein.

Jain. Aber ReFS unterstützt keine Transaktionen, somit sind sie allein auf NTFS beschränkt. Wenn man das als Fehlkonstruktion von ReFS sehen will, dann wäre das halt eine mögliche Sichtweise.

Zitat:

Zitat von Der schöne Günther (Beitrag 1417565)

Ich denke die sind allerdings nicht erst seit Windows 8 deprecated.

Quellen? Da es mit Windows Vista eingeführt wurde, bliebe dazwischen ja nur Windows 7.

Zitat:

Zitat von Der schöne Günther (Beitrag 1417565)

Und dass Microsoft etwas strongly recommended sehe ich auch nicht oft.

Dann mußt du mehr Doku lesen :zwinker:

Zitat:

Zitat von Der schöne Günther (Beitrag 1417565)

Bei der Geschwindigkeit wie sich Windows in den letzten Jahren ändert würde ich mich auch nie im Leben darauf verlassen dass so etwas noch lange verfügbar bleibt.

Das ist nun auch wieder wahr, jupp.

Okay, also bisher keiner der es benutzt. Alles klar. Danke für die Rückmeldungen! :thumb:

[API]

Ich würde gerne wissen, wozu diese Umfrage dient? Danke für eine kurze Info.

[jobo]

Zitat:

Zitat von Assarbad (Beitrag 1417597)

Zweitens: mir scheint du mißverstehst wie das normale DeleteFile funktioniert. DeleteFile löscht nicht etwa, wie der Name es suggeriert, die Datei. Stattdessen setzt diese Funktion - übrigens mit der gleichen Methode die ich oben schon erwähnte (SetFileInformationByHandle) - ein Flag. Wenn die Funktion zum Aufrufer zurückkehrt muß die Datei noch lange nicht gelöscht sein (in NTFS kann das durchaus mal ein paar Sekunden dauern, wenn das System gerade "zu tun" hat).

Kurzum DeleteFile ist ebensowenig atomar wie MoveFileEx. Hammer, oder? ;)

Und "schlimmer" noch, bei näherer Betrachtung ist die vermeintliche Inkonsistenz nicht so inkonsistent wie du meinst. Transaktionen geben ja Garantien. Wenn nun also eine Datei, bspw. durch einen anderen Prozeß, zum Löschen vorgemerkt wird, dann ..

"Transaktionen geben ja Garantien", das ist für mich der entscheidende Satz. In "Datenbanken" die ich meine -ACID konform- wird das tatsächlich eingehalten. Ein Operation funktioniert ganz oder gar nicht. Punkt.
Im oberen Teil Deines Zitats sieht die Darstellung des Löschvorgangs allerdings so aus, als sei dies gar nicht garantierbar, damit neigt sich für mich die Waage Richtung Designfehler. Vielleicht ist das auch zu drastisch ausgedrückt. Das Delete müsste ja nicht zurückkommen, bevor es seine Arbeit wirklich gemacht hat. Wäre es so, dann würden alle stöhnen, wie lahmar...ig das System ist. (Wahrscheinlich ist diese Hase und Igel Nummer eine Auflage aus der User Experience Abteilung.) Und wer schon mal "Dateien zum Löschen vormerkt", schubst wahrscheinlich auch alte Omas ins Hafenbecken oder stellt ihnen wenigstens ein Bein.

Windows will aber ja flink und nett sein und alles automatisch richtig machen. Leider kann man es halt nicht allen recht machen.

[Assarbad]

Zitat:

Zitat von jobo (Beitrag 1417628)

"Transaktionen geben ja Garantien", das ist für mich der entscheidende Satz. In "Datenbanken" die ich meine -ACID konform- wird das tatsächlich eingehalten. Ein Operation funktioniert ganz oder gar nicht. Punkt.

Richtig. Aber du könntest nicht innerhalb einer Transaktion nach dem atomaren Löschen nochmal was mit der Datei machen (also zumindest nicht mit dem vorher existierenden Inhalt). Wenn aber ein anderer Prozeß dazwischengrätscht und per DeletFile eine Datei zum Löschen markiert, finde ich es sinnvoll, daß die Garantie der Transaktion aufrechterhalten wird, sobald die Transaktion abgeschlossen wird. Und für diese Garantie muß sich das OS dann eben leider über die Markierung zum Löschen von außerhalb der Transaktion hinwegsetzen (wenn das DeleteFile von außerhalb überhaupt glückt, wäre mal interessant das zu testen). Ist doch sinnvoll, oder hab ich hier komplett was verpeilt? Priorisierung gibt es in allen möglichen Operationen (denk mal an ACEs in ACLs), bei einem inhärent asynchronen Dateisystem ist dies die - zumindest für mich und scheinbar auch die Designer von NTFS - logischste Vorgehensweise.

Zitat:

Zitat von jobo (Beitrag 1417628)

Im oberen Teil Deines Zitats sieht die Darstellung des Löschvorgangs allerdings so aus, als sei dies gar nicht garantierbar, damit neigt sich für mich die Waage Richtung Designfehler.

Das verstehe ich gerade nicht. Dein zitiertes Beispiel geht ja davon aus, daß von außen während einer laufenden Transaktion eine Datei zum Löschen markiert wird. Aber innerhalb der Transaktion wird mir ja garantiert, daß bspw. ein Schreibvorgang ausgeführt wird oder gelesene Daten konsistent sind. Ich fände es also eher befremdlich wenn die Markierung von außen Vorrang genießen würde und bei Abschluß meiner Transaktion die Datei das zeitliche segnet, weil die Löschmarkierung jetzt plötzlich greift. Aber vielleicht verpeile ich ja etwas vollkommen?

Zitat:

Zitat von jobo (Beitrag 1417628)

Das Delete müsste ja nicht zurückkommen, bevor es seine Arbeit wirklich gemacht hat. Wäre es so, dann würden alle stöhnen, wie lahmar...ig das System ist.

Eben.

Zitat:

Zitat von API (Beitrag 1417621)

Ich würde gerne wissen, wozu diese Umfrage dient? Danke für eine kurze Info.

Vor allem dazu meine Neugier zu dem Thema zu stillen. Auf ner Q&A-Seite wie StackOverflow könnte man so eine Frage nicht stellen. Daher ist sie auch unter K&T und nicht bei Win32 untergebracht. Bitte, gern :zwinker:

[Namenloser]

Es gab vor einigen Jahren mal einen "Leak" eines Microsoft-Mitarbeiters über die Zustände bei Microsoft. Dort ging es unter anderem auch um den NTFS-Code, der wohl sehr kompliziert sein soll. Es gibt wohl einfach niemanden mehr, der den Code versteht. Deswegen war man wohl bemüht, die Komplexität zu reduzieren. Das dürfte der eigentliche Grund sein, warum man Transaktionen deprecated hat.

Ich finde das zwar auch schade, da ich Transaktionen eigentlich für ein sehr gutes Feature halte – ich hatte mir das vor Jahren mal angeschaut, als es noch nicht deprecated war – verwendet habe ich es letztendlich aber auch nie.

Zitat:

Oh god, the NTFS code is a purple opium-fueled Victorian horror novel that uses global recursive locks and SEH for flow control. Let's write ReFs instead. (And hey, let's start by copying and pasting the NTFS source code and removing half the features! Then let's add checksums, because checksums are cool, right, and now with checksums we're just as good as ZFS? Right? And who needs quotas anyway?)

http://blog.zorinaq.com/i-contribute...an-other-oper/

[jobo]

Zitat:

Zitat von Assarbad (Beitrag 1417629)

..

Zitat:

Zitat von jobo (Beitrag 1417628)

Im oberen Teil Deines Zitats sieht die Darstellung des Löschvorgangs allerdings so aus, als sei dies gar nicht garantierbar, damit neigt sich für mich die Waage Richtung Designfehler.

Das verstehe ich gerade nicht. Dein zitiertes Beispiel geht ja davon aus, daß von außen während einer laufenden Transaktion eine Datei zum Löschen markiert wird. ..

Das Problem ist wahrscheinlich eher, dass ich nicht verstehe. Schon das "Wording" in dem Thread.
Löschen = eigentlich nur markieren (aber nicht physikalisch gelöscht, ok, irgendwie kennt man das seit der Sache mit dem Fragezeichen im Dateinamen - FAT Dateisystem)
Nur als "gelöscht" markiert = Wird aber dann wenigstens so behandelt und dargestellt (dem Anwender) und zwar synchron?
Oder eher nicht? > Wahrscheinlich, denn das angezeigte Dateien nicht mehr auffindbar sind usw. kennt man ja. (Eigentlich falsch, denn das kennt man auch aus DB, wo man eine OP mit veralteten Daten startet)
An der Stelle würde ich aus Datenbanksicht am ehesten von expliziten oder impliziten Locks sprechen, die vielleicht genutzt werden (könnten, aber wohl nicht unbedingt werden).

Der Designfehler ist vielleicht schon, dass man die transaktionsbasierte Datei OP wahlweise anwenden kann. Das ist in einer DB nicht möglich. Alles sind Transaktionen (man kann - aus was für Gründen auch immer- lediglich sagen, das man mit einem anderen Isolationlevel auf die Daten schauen möchte- was an der Transaktion nichs ändert, sondern m.E. eher zu einer Art Illuminatenwissen führt).

Ich habe also ein System, in dem erstmal egal ist, wer, was, wann ändert, löscht, erzeugt. Das funktioniert, wenn es von einem Menschen halbwegs sinnvoll bedient wird und darunter die Abläufe schnell genug sind, dem Bedienfortschritt zu folgen (und die Dateien klein genug und der freie Platz groß genug). Es erinnert mich etwas an das Reißverschlusssystem im Straßenverkehr, dass ich neulich im Urlaub auch beim Linksabbiegen erleben durfte.
Darauf setze ich ein Transaktions-System. Das kann offenbar seine Garantien nur erfüllen, in dem es andere ("normale") Prozesse im Zweifel schlicht auflaufen lässt.
Hier irgendwo sehe ich ein Designproblem.
Auch wenn es interessant ist, die Diskussion ist eigentlich müßig, spätestens angesichts des nahen Todes des Systems.

Interessant dagegen scheint mir immer wieder der Umgang mit diesen Dingen. Was war an der Funktion nun das Problem? Niemand brauchte sie? Niemand glaubte, sie zu brauchen? Niemand, der sie gebrauchte, hatte damit den gewünschten Erfolg? Niemand, der sie hätte gebrauchen können, hat der Funktion die nötige Standing zugetraut (Die zumindest haben Recht behalten). Damit bin ich über 7 Ecken an meinem Windows Dauerkritikpunkt angelangt. Der gleichzeitig mein Pluspunkt bei Delphi ist, hier sehe ich mehrheitlich Kontinuität.

[Assarbad]

Zitat:

Zitat von jobo (Beitrag 1417649)

Nur als "gelöscht" markiert = Wird aber dann wenigstens so behandelt und dargestellt (dem Anwender) und zwar synchron?

Asynchron (zumindest bei NTFS).

Zitat:

Zitat von jobo (Beitrag 1417649)

Ich habe also ein System, in dem erstmal egal ist, wer, was, wann ändert, löscht, erzeugt. Das funktioniert, wenn es von einem Menschen halbwegs sinnvoll bedient wird und darunter die Abläufe schnell genug sind, dem Bedienfortschritt zu folgen (und die Dateien klein genug und der freie Platz groß genug). Es erinnert mich etwas an das Reißverschlusssystem im Straßenverkehr, dass ich neulich im Urlaub auch beim Linksabbiegen erleben durfte.
Darauf setze ich ein Transaktions-System. Das kann offenbar seine Garantien nur erfüllen, in dem es andere ("normale") Prozesse im Zweifel schlicht auflaufen lässt.
Hier irgendwo sehe ich ein Designproblem.

Okay, ich nicht. Weil ich einsehen kann, warum im Sinne der Vorhersehbarkeit eine der Operationen Vortritt bekommt. Aber es gibt definitiv ein Dokumentationsproblem bei DeleteFile: Deletes an existing file ist eben mal ne fette Lüge, auch wenn das bei hinreichender Geschwindigkeit des Systems üblicherweise danach aussieht.

Zitat:

Zitat von jobo (Beitrag 1417649)

Auch wenn es interessant ist, die Diskussion ist eigentlich müßig, spätestens angesichts des nahen Todes des Systems.

Stimmt :)

Zitat:

Zitat von jobo (Beitrag 1417649)

Interessant dagegen scheint mir immer wieder der Umgang mit diesen Dingen. Was war an der Funktion nun das Problem? Niemand brauchte sie? Niemand glaubte, sie zu brauchen? Niemand, der sie gebrauchte, hatte damit den gewünschten Erfolg? Niemand, der sie hätte gebrauchen können, hat der Funktion die nötige Standing zugetraut (Die zumindest haben Recht behalten). Damit bin ich über 7 Ecken an meinem Windows Dauerkritikpunkt angelangt. Der gleichzeitig mein Pluspunkt bei Delphi ist, hier sehe ich mehrheitlich Kontinuität.

Als bekennender Ex-Delphianer lasse ich mich auf die Diskussion lieber nicht ein, sonst muß die Feuerwehr anrücken :lol:

@Namenloser: Danke für den interessanten Link! Könnte durchaus auch eine Rolle spielen, die Komplexität wieder herunterzuschrauben, stimmt.