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

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

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

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

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.