Ist es möglich eine Datei zu lesen ohne das Löschen der Datei zu blockieren?

[HeZa]

Hallo,

Die Situation:
Verschiedene Programme auf die ich keinen Einfluss habe, legen eine Datei an um zu signalisieren, dass eine bestimmte Resource gesperrt ist. In der Datei steht dann das Programm und der Benutzer der gesperrten Resource.
Ich habe einen DirectoryWatch laufen, der mir mitteilt, dass so eine Datei angelegt wurde. Dann möchte ich den Inhalt lesen und auswerten.

Problem:
Lese ich gerade die Datei wenn das Programm, dass diese Datei angelegt hat, diese löschen möchte, weil die Resource nicht mehr gesperrt ist, erhält das Programm einen Fehler zurück und bricht das Löschen ab, mit der Auswirkung, dass die Sperrdatei nicht gelöscht wird.

Mein Wunsch:
Wenn während meines Leseversuchs versucht wird die Datei zu löschen, soll mein Leseversuch scheitern, das Löschen aber erfolgreich sein. Ist so etwas (entgegen meinen Erwartungen) realisierbar?

[BUG]

Es gibt unter (afaik) Windows die Möglichkeit, Dateien "unterbrechbar" zu öffnen. Mir fällt jetzt adhoc nicht das Stichwort ein.

[HeZa]

Zitat:

Zitat von BUG (Beitrag 1343752)

Es gibt unter Windows die Möglichkeit, Dateien "unterbrechbar" zu öffnen

Danke. Das klingt ja schon mal sehr verheißungsvoll.

Vielleicht findet sich ja noch jemand der entsprechende Stichwort kennt (am besten auf englisch). ;-)

[BUG]

Zitat:

Zitat von HeZa (Beitrag 1343754)

Das klingt ja schon mal sehr verheißungsvoll.

Ich hoffe ich habe es mir nicht nur eingebildet. Unter ein paar naheliegenden Stichwörtern hab ich leider nichts wiedergefunden :?

[p80286]

Ich denke das geht nicht.
Was möglich wäre, daß Du eine Kopie des Inhalts erstellst(tstrings.LoadFile) und dann damit arbeitest.

Gruß
K-H

[nahpets]

Es muss gehen (zumindest bis Windows XP).

Wenn ich im Windows-Commander eine Datei mit der internen Ansicht (Taste F3) anzeige, kann sie von einem anderen Prozess problemlos gelöscht werden.

Such bitte mal nach FileMode und Zugriffsmodus-Konstanten (müsste in der System.pas zu finden sein).

Vermutlich brauchst Du den FileMode fmShareDenyNone (Andere haben uneingeschränkten Zugriff).

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1343761)

Was möglich wäre, daß Du eine Kopie des Inhalts erstellst(tstrings.LoadFile) und dann damit arbeitest.

Auch in diesem Fall gibt es einen kurzen Zeitraum, in dem die Datei zum Lesen gesperrt ist.
Unabhängig davon ist das aber der richtige Ansatz. Eventuell macht das löschende Programm ja mehrere Versuche oder verwendet einen Timeout.

[himitsu]

CreateFile + FILE_SHARE_DELETE


Und es kommt drauf an, wie die Datei geladen/Angezeigt wird.
* Man kann die Datei kurz öffnen, laden, anzeigen und die Datei gleich wieder schließen (siehe MS Paint, Notepad, WordPad)
* und man kann die Datei die ganze Zeit geöffnet halten, so lange man sie Anzeigt. (siehe MS Office)

[BUG]

Gefunden! :dance:
Ich wusste doch, dass ich es auf The Old New Thing gelesen habe: Using opportunistic locks to get out of the way if somebody wants the file.
Das ist wahrscheinlich nicht so bekannt, weil es aus der Netzwerk-Dateisystem-Ecke kommt.

EDIT: So richtig toll ist das für den Zweck aber auch nicht, es gibt noch das Race zwischen dem Löschen und dem Anfordern des Locks.

[HolgerX]

Hmm..

Eine Alternative gäbe es vielleicht noch...

ShadowCopy...

[Mikkey]

Relativ simple Umgehung des Problems:

Klappt das Löschen nicht, wird die Datei nach einem bestimmten Muster umbenannt. Dein Watcher beseitigt regelmäßig die so entstandenen Dateileichen.

Edit:
Das (nicht löschen sondern umbenennen) könnte auch zum Standardverhalten werden, dann werden die Worker-Prozesse nicht unnötig mit "Dateisystem-Geraffel" aufgehalten.

[BUG]

Zitat:

Zitat von Mikkey (Beitrag 1343789)

Klappt das Löschen nicht, wird die Datei nach einem bestimmten Muster umbenannt. Dein Watcher beseitigt regelmäßig die so entstandenen Dateileichen.

Er löscht ja nicht selbst, sondern unbeeinflussbare Drittprogramme.

[nahpets]

Andere Möglichkeit:

Kopie der Datei erstellen, die man lesen will und die Kopie löschen, wenn man sie nicht mehr benötigt.

[himitsu]

Zitat:

Zitat von nahpets (Beitrag 1343811)

und die Kopie löschen, wenn man sie nicht mehr benötigt.

Oder gleich die Kopie so erstellen, dass sie sich selber löscht.
CreateFile + FILE_ATTRIBUTE_TEMPORARY

Oder garkeine physische Datei erstellen (in den Arbeitsspeicher einlesen).

Im Grunde aber egal, denn die Originaldatei müsste man dennoch öffnen und so lange warten, bis der Inhalt ausgelesen/kopiert wurde.

[tcoman]

Da ich kein Experte bin sondern nur anwendenter Laie,
lese / lade ich Dateien immer mit BlockRead();

Wenn ich den FileMode richtig setze, kann ich die geladene
Datei in einem Drittprogramm loeschen.

Delphi-Quellcode:

function _readfile: boolean;
var F : File Of Byte;
    ior : integer; 
begin
ior:=0;
AssignFile(F, 'X:\Dir\Filename.ext');
FileMode:=fmOpenRead; //alternate: fmOpenReadWrite
{$I-} Reset(F);
{$I+} inc(ior, IORESULT);
...
{$I-} BlockRead();
{$I+} inc(ior, IORESULT);
...
{$I-} CloseFile(F);
{$I+} inc(ior, IORESULT);
...
result:=(ior = 0);
end;

Alles ohne Gewehr.
MfG,
Terence

[p80286]

Zitat:

Zitat von HeZa (Beitrag 1343751)

Mein Wunsch:
Wenn während meines Leseversuchs versucht wird die Datei zu löschen, soll mein Leseversuch scheitern, das Löschen aber erfolgreich sein. Ist so etwas (entgegen meinen Erwartungen) realisierbar?

und der Vorschlag aus #8
FILE_SHARE_DELETE

Wobei, wenn das Delete in Deinen Lesevorgang läuft, Du nur Schrott gelesen hast.

Gruß
K-H

[HeZa]

Hallo,

erst einmal Danke für die Tipps und Infos.

Wie ich bereits im Anfangsposting erklärte, habe ich keinen Einfluss auf die Programme die diese Sperrdateien erzeugen und löschen. Diese Programme und insbesondere der Umgang mit den Sperrdateien ließen sich bestimmt verbessern, leisten aber trotzdem wertvolle Arbeit für uns. Die Änderung dieser Programme liegt aber außerhalb meiner Möglichkeiten.

Tatsache bleibt, dass ein Leseversuch das Löschen einer Sperrdatei durch diese Programm scheitern lässt und diese Programme darauf nicht sinnvoll reagieren und somit die Sperrdatei erhalten und die Resourcen gesperrt bleiben.

Die einzige machbare Möglichkeit ist mit (hier erwähnten) ShadowCopy zu arbeiten. Das ist für meine Verwendung, aber wie mit Kanonen auf Spatzen schließen. Also werde ich auf das Lesen der Daten verzichten (das wäre eine sinnvolle/interessante Ergänzung gewesen, aber nicht zwingend notwendig) und wende mich anderen Aufgabenstellungen zu.

Ciao HeZa

[Daniel]

Danke für die abschließende Rückmeldung. :-)

[himitsu]

Man hätte es vielleicht auch noch mit einer Transaction versuchen können, aber ich hab keine Ahnung, ob und wie sich das auf Schreib-/Löschversuche durch andere Programme auswirkt.
Allerdings würde ich "vermuten", dass sich für die Anderen nichts ändert, gegenüber einem "normalen" CreateFile und dessen Sperren/Freigaben.

CreateFile CreateFileTransacted


Meine Interpretation
Transaction = schütze Andere und die Datei vor mir
ShadowCopy = schütze mich vor den Anderen


Und die ganz harte Variante (Thread-Priorität = Critical) wäre vielleicht möglich, aber auch keine gute Lösung.
> der eigene Prozess nimmt die CPU voll in Besitz, während sie auf die Datei zugreift ... andere Programme kommen währenddessen zu nichts und kommen erst nach dem Zugriff wieder zu sonstwas, wie z.B. um die Datei dann zu löschen.