Das Problem bei "$line =~ /irgendwas/ ? $bool = 0 : $bool = 1;" ist aber, daß $bool wieder zurück gesetzt wird wenn in $line nicht das gesuchte Wort drin ist. Wenn nun die letzte Zeile der Datei das Suchwort nicht enthält, aber irgendeine Zeile darüber schon, wird die Datei nicht gelöscht.

[quote=yasukatakaya,06.06.2007, 08:36]doch wenn ich unlink nach dem open(.....); schreibe, löscht er die Datei nicht, heisst es, dass geöffnete Dateien nicht gelöscht werden können[/quote]
Ich weiss nicht, wie das bei gewissen selbsternannten Betriebssystemen ist, aber unter Un*x kann man sehr wohl Dateien unlinken, die man noch geoeffnet hat.  Danach kann sie niemand mehr ueber ihren ehemaligen Dateinamen erreichen, aber man kann den Dateideskriptor noch benutzen.  Wenn die Datei dann geschlossen wird, wird der Inhalt endgueltig von der Platte geloescht.  Zitat aus "man 2 unlink":

Quote

If  the  name  was the last link to a file but any processes still have
the file open the file will remain in existence  until  the  last  file
descriptor referring to it is closed.

In Deinem urspruenglichen Code wird die Datei allerdings nach dem Unlinken geoeffnet. Das sollte nie gehen.\n\n

<!--EDIT|betterworld|1181186595-->

@topeq, mir gefällt das nachgestellte-if sowieso besser ;)

[quote=betterworld,07.06.2007, 05:08][quote=yasukatakaya,06.06.2007, 08:36]doch wenn ich unlink nach dem open(.....); schreibe, löscht er die Datei nicht, heisst es, dass geöffnete Dateien nicht gelöscht werden können[/quote]
Ich weiss nicht, wie das bei gewissen selbsternannten Betriebssystemen ist, aber unter Un*x kann man sehr wohl Dateien unlinken, die man noch geoeffnet hat.[/quote]
Unter Win32 ist es tatsächlich so wie von OP geschrieben.

Bei Win32 kann man die Datei nicht unlink'en, solang sie von einem anderen Prozess angesprochen wird. Was bei Windows u.a. auch zur Sicherheit ist.\n\n

<!--EDIT|RPerl|1181215609-->

[quote=RPerl,07.06.2007, 13:26]Bei Win32 kann man die Datei nicht unlink'en, solang sie von einem anderen Prozess angesprochen wird. Was bei Windows u.a. auch zur Sicherheit ist.[/quote]
... allerdings ist gerade dieses Verhalten von Windows ein großer Unsicherheitsfaktor.

Bei temporären Dateien ist es zum Beispiel sinnvoll, den Dateinamen gleich wieder zu löschen, bevor ein anderer Prozess möglicherweise auch Zugriff darauf erhält. Gerade bei Windows, wo in den meisten Fällen kein ordentliches Rechtemanagement für das Dateisystem existiert, wäre das wichtig. Außerdem kann man so auch sicherstellen, dass die temporäre Datei nicht länger lebt als der Prozess, der sie benutzt. Unter Windows muss man dafür hässliche Workarounds benutzen.

Ja, Stichwort Race-Condition. Aber weil es kein richtiges Rechtesystem gibt bei Windows, ist es noetig, dass man z. B. spezielle DLLs nicht loeschen kann, weil der prozess darauf zugreift. Wenn man das koennte, koennte man u.U. das System crashen.

[quote=RPerl,07.06.2007, 18:48]Ja, Stichwort Race-Condition. Aber weil es kein richtiges Rechtesystem gibt bei Windows, ist es noetig, dass man z. B. spezielle DLLs nicht loeschen kann, weil der prozess darauf zugreift. Wenn man das koennte, koennte man u.U. das System crashen.[/quote]
Wenn jeder alle Dateien loeschen darf, kann immer Schaden angerichtet werden, und da von "Sicherheitsmaßnamen" zu reden, ist ziemlich unangebracht. Selbst wenn ich den geringen Teil der gerade geoeffneten Dateien nicht loeschen kann, kann ich z. B. irgend eine Datei loeschen, die zum Booten dringend gebraucht wird. Das ist unter Umstaenden noch schlimmer, als wenn ich einen einmaligen Crash hervorrufe.

Wenn man DLLs massenweise loescht, ist das kein "einmaliger" Crash.
Der Rest ist so richtig.

[quote=RPerl,07.06.2007, 18:48]Ja, Stichwort Race-Condition. Aber weil es kein richtiges Rechtesystem gibt bei Windows, ist es noetig, dass man z. B. spezielle DLLs nicht loeschen kann, weil der prozess darauf zugreift. Wenn man das koennte, koennte man u.U. das System crashen.[/quote]
So, wie es bei den Unices, die ich kenne, gelöst ist, gibt es keine Probleme, wenn man einem Prozess irgendwelche dynamischen Bibliotheken "unter dem Hintern weglöscht". Da der dynamische Linker die Bibliotheken noch geöffnet hat, funktioniert das Programm problemlos weiter, bis es beendet wird -- erst dann verschwinden die Daten der Bibliotheken aus dem Dateisystem.

Dass man natürlich keine neuen Programme mehr starten kann, wenn man meinetwegen die C-Laufzeitbibliothek löscht, ist klar. Das gleiche Problem bekommt man aber unter jedem System, wenn man wichtige Bibliotheken löscht. Nur unter Unix laufen wenigstens alle Programme die noch im Speicher sind weiter.

Praktisch ist dieses Verhalten zum Beispiel dann, wenn man Bibliotheken durch aktualisierte binärkompatible Versionen ersetzen will -- dazu muss man dann nämlich keine laufenden Programme beenden oder gar neu booten, wie das bei Windows so oft der Fall ist.

Außerdem kann man bei Windows problemlos auch verwendete Bibliotheken löschen, indem man sie zuerst entläd. Ein altes Kompatibilitätsfeature, das wirklich maximal unsicher designt ist, erlaubt es nämlich beliebige Bibliotheken auch fremder Prozesse aus dem Speicher zu kicken...