Offene Bezüge killen

[Roland Wind]

Hallo Leute

Folgendes Problem: Durch unsachgemäße Verwendung (Rausziehen ohne Abmeldung) von Wechseldatenträgern bleiben offene Bezüge auf Dateien. Diese kann man dann nicht mehr löschen. Wie kann ich nun von Delphi aus offene Bezüge auf Dateien feststellen (Angabe eines Volumes oder einer Datei) und diese auch killen ??

[Robert Marquardt]

Ich glaube das geht einfach nicht

[Hagen Reddmann]

Wenn dann kann man höchsten das OS veranlassen alle Bezüge zu schreiben, über ein Flush(). Wird danach das Device entfernt so gibt es keine offenen Bezüge mehr. Das Flush() muß dann demzufolge präventiv, nach jeder Aktion aufgerufen werden.

Gruß Hage

[Robert Marquardt]

Bei Wechseldatentraegern 8USB Sticks) ist das Problem sogar noch groesser. Dieses "Unsafe Removal" wurde eingefuehrt um dem Treiber zu erlauben zu cachen. Auch bei geschlossenen Bezuegen kann aso die Filestruktur auf dem Laufwerk inkonsistent sein

[Roland Wind]

Unter WindowsXP funktioniert es jedoch. Wenn ich den Datenträger formatieren will, auf dem offene Bezüge sind, erhalte ich die Meldung "Offene Bezüge gefunden" und kann diese dann auch killen.
Bei allen anderen OS geht das gar nicht und ich kann das Medium nicht mehr formatieren.
Das mit dem Flush klingt interessant. Kann man das auch im Nachhinein veranlassen ?? Sozusagen eine Funktion "Offene Bezüge schreiben". Was ist dann eigentlich mit Dateien, die nicht mehr auf dem Quelldatenträger vorhanden sind ?

[Hagen Reddmann]

Ein Flush sollte eigentlich alle "öffenen Bezüge", Änderungen, Screib-/Lese-Operationen, die noch im Cache sind auf den Datenträger übertragen. D.h. danach sollte man den Datenträger ohne Probleme entfernen können. Natürlich muß das OS und der Treiber des Gerätes und die Hardware des Gerätes mitspielen. Beim OS sehe ich keine Probleme. Der Treiber muß korrekt flushen und diesen Befehl auch an einen eventuellen Hardwarecache durchreichen.<br>

So, nun frage MICHT NICHT wie man einen solchen Flush bei Wecheldatenträgern im speziellen auslösst, ich weiß es nicht! <br>

Normalerweise müsste DeviceIOControl() mit IOCTL_FLUSH o.ä. das machen, es gibt aber auch API für's Flush.<br>

Es läuft aber damit auf eine Präventivmaßnahme raus, d.h. einmal entstandene Fehler können so nicht entfernt werden.<br>
Dies ist eher die Aufgabe eines "Recovering-Tools".<br>
Normalerweise müsste man beim OS einstellen können, das bei solchen Datenträgern jede Aktion sofort und richtig ausgeführt wird. Bei der heutigen Power muß ein Cache nicht mehr sein, beim USB 1.1 z.b. ereicht man 1Mb/sec mehr/weniger nicht. Ein Cache ändert daran herzlichst wenig. (meine bescheidene Meinung)<br>

Gruß Hage

[Roland Wind]

Was hältst du von dieser Möglichkeit ??

mov ax, 710Dh ; Reset Drive
mov cx, Flag ; see below
mov dx, DriveNum ; see below
int 21h
jc error

0000h Resets the drive and flushes the file system buffers for the given drive.
0001h Resets the drive, flushes the file system buffers, and flushes and invalidates the cache for the specified drive.
0002h Remounts the drivespace volume.

The Flag value of 0002h is only supported on drivespace volumes. You should specify this value when the on-media format of the drivespace volume has changed and you want the file system to reinitialize and read the new format.

DriveNum

Drive to reset. This parameter can be 0 for the default drive, 1 for A, 2 for B, and so on

[Roland Wind]

Weiters gibt es auch noch die Funktion "FlushFileBuffers".

Man müßte eine Funktion schreiben, die alle FileHandles der Dateien ermittelt, überprüft, ob diese GENERIC_WRITE Access besitzen und diese Funktion für alle aufrufen

[Hagen Reddmann]

Int 21h ist der MS-Dos Service Interrupt, und er funktioniert nur noch sinnvoll weil das OS noch kompatibel bleibe will, soll oder hofft.<br>
Ich würde diesen nicht nutzen.<br>
Du musst nach DeviceIOControl() suchen, ich sage dir aber gleich im vorhinein: nimm dir Zeit um dich durch den Wuscht durchzuarbeiten.<br>

Gruß Hage

[Roland Wind]

Hallo Hagen

Mann, bist du aber ein Frühaufsteher. Um 5 Uhr morgens aufzustehen und dann noch ins Forum zu gehen ist ja brutal.
Vielen Dank für deinen Tip. Ich habe mir mal DeviceIOControl in der Win32SDK angesehen. Dort habe ich aber leider IOCTL_FLUSH nicht gefunden. Hast du vielleicht neuere oder bessere Unterlagen ?

[Hagen Reddmann]

Hm, so kann man es auch sehen, nur mit dem Hacken das ich dann 2 Tage nicht mehr geschlafen hätte. Nee: ich bin ein spät ins Bett-Geher, bzw. Programmierer <br>
Und wenns eng wird, weil das PalmOS eine shit Net Library hat mit der man keine ordentliche Connections bekommt, dann muß man auch schon mal länger klotzen.<br>
Zur Entspannung und zum Abschluß eines erfolglosen Tages, gehe ich dann in Entwicklerforum.<br>

Gruß Hagen<br>

PS: um 10Uhr heut morgen hatte ich meine nächsten Termin, kannst Dir ja selber ausrechnen wieviel Schlaf ich hatte. Aber so ist das mit einem Freelancer