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

[jobo]

Zitat von Assarbad:

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 von jobo:

"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 von jobo:

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 von jobo:

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 von API:

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

[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 von Assarbad:

..

Zitat von jobo:

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 von jobo:

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

Asynchron (zumindest bei NTFS).

Zitat von jobo:

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 von jobo:

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

Stimmt

Zitat von jobo:

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

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