Welches Betriebssystem hast du denn?
Unter Unix/Linux ist es kein Problem, wenn ein Prozess eine Datei löscht, während ein anderer Prozess noch ein Filehandle auf diese Datei auf hat: Der Verzeichniseintrag für die Datei wird direkt gelöscht, aber der Speicherplatz wird erst dann freigegeben, wenn das letzte Filehandle geschlossen ist.

Das wird einerseits gerne ausgenutzt für temporäre Dateien, die automatisch bei Programmende verschwinden: Ich öffne eine Datei und lösche sie gleich wieder; jetzt kann ich weiter das Filehandle zum Lesen und Schreiben benutzen, aber die Datei ist nicht im Filesystem zu sehen. Wenn mein Programm aus irgendwelchen Gründen abbricht, wird auch der Plattenplatz automatisch wieder freigegeben, ohne dass ich einen Interrupthandler zum Löschen bräuchte.

Andererseits kann es zu merkwürdigen Problemen führen: Die Festplatte ist fast voll. Ich suche nach Dateien, die gelöscht werden können. Eine große Logdatei brauche ich nicht mehr und lösche sie. Trotzdem nimmt der freie Speicherplatz nicht zu. Lösung des Rätsels: Der Prozess, der die Logdatei beschreibt, hält sie geöffnet. Erst wenn dieser Prozess die Datei schließt, wird auch der Speicherplatz freigegeben.

Das macht es unter Linux auch möglich, dass man Programme und Systembibliotheken aktualisiert, während sie benutzt werden. Deshalb empfiehlt es sich, nach einem Update wichtiger Bibliotheken nachzuschauen, ob irgendwelche Prozesse neu gestartet werden müssen. (Debian macht das meist automatisch, wenn die Dependencies stimmen.) Dies kann man z.B. mit lsof | grep '(deleted)' (lsof steht für "list open files").

Aber ich schweife ab...

Dein Test auf Existenz der Datei mit "-e" unterliegt selber wieder einer Race Condition: Ein anderer Prozess kann die Datei nach dem Test und vor dem Öffnen trotzdem löschen.

Mich würde aber interessieren, wie es unter Windows ist. Bricht da ein Programm ab, wenn es aus dem Filehandle einer gelöschten Datei liest?