Warum kann ich In-Use-Dateien unter Windows nicht wie unter Linux und OS X ändern?

Wenn Sie Linux und OS X verwenden, wird das Betriebssystem Sie nicht daran hindern, eine Datei zu löschen, die derzeit unter Windows verwendet wird. Dies wird ausdrücklich untersagt. Was gibt? Warum können Sie verwendete Dateien auf Unix-Systemen, nicht jedoch Windows, bearbeiten und löschen??

Die heutige Question & Answer-Sitzung wird dank SuperUser zur Verfügung gestellt - einer Unterteilung von Stack Exchange, einer Community-basierten Gruppierung von Q & A-Websites.

Die Frage

SuperUser-Leser the.midget möchte wissen, warum Linux und Windows verwendete Dateien unterschiedlich behandeln:

Seit ich Linux zum ersten Mal benutzt habe, hat es mich verwirrt, dass man den Namen einer Datei ändern oder sogar löschen kann, während sie gelesen wird. Ein Beispiel ist, wie ich versehentlich versucht habe, ein Video während der Wiedergabe zu löschen. Ich hatte Erfolg und war überrascht, als ich erfuhr, dass Sie fast alles in einer Datei ändern können, ohne sich darum zu kümmern, ob sie gerade verwendet wird oder nicht.

Was passiert also hinter den Kulissen und verhindert, dass er unter Windows mutwillig Dinge löscht, wie er es unter Linux kann??

Die Antwort

Die Mitwirkenden von SuperUser haben die Situation für the.midget beleuchtet. Erstaunt schreibt:

Immer, wenn Sie eine Datei in Windows öffnen oder ausführen, sperrt Windows die Datei (dies ist eine Vereinfachung, aber normalerweise wahr.) Eine Datei, die von einem Prozess gesperrt ist, kann erst dann gelöscht werden, wenn dieser Prozess sie freigibt. Aus diesem Grund müssen Sie jedes Mal, wenn Windows sich selbst aktualisieren muss, einen Neustart durchführen.

Auf der anderen Seite sperren Unix-ähnliche Betriebssysteme wie Linux und Mac OS X nicht die Datei, sondern die zugrunde liegenden Festplattensektoren. Dies scheint eine triviale Unterscheidung zu sein, bedeutet jedoch, dass der Datensatz der Datei im Inhaltsverzeichnis des Dateisystems gelöscht werden kann, ohne dass ein Programm gestört wird, das die Datei bereits geöffnet hat. Sie können also eine Datei löschen, während sie noch ausgeführt wird oder anderweitig verwendet wird, und sie bleibt auf der Festplatte vorhanden, solange ein Prozess ein offenes Handle für sie hat, obwohl der Eintrag in der Dateitabelle nicht mehr vorhanden ist.

David Schwartz erläutert die Idee und zeigt auf, wie die Dinge ideal sein sollten und wie sie in der Praxis sind:

Windows verwendet standardmäßig die automatische obligatorische Dateisperre. UNIXes verwenden standardmäßig das manuelle, kooperative Sperren von Dateien. In beiden Fällen können die Standardwerte überschrieben werden, in beiden Fällen jedoch normalerweise nicht.

Viele alte Windows-Codes verwenden die C / C ++ - API (Funktionen wie fopen) und nicht die native API (Funktionen wie CreateFile). Mit der C / C ++ - API können Sie nicht festlegen, wie das obligatorische Sperren funktionieren soll. Sie erhalten also die Standardwerte. Der voreingestellte "Share-Modus" verbietet normalerweise "Konflikt" -Operationen. Wenn Sie eine Datei zum Schreiben öffnen, wird davon ausgegangen, dass Schreibvorgänge in Konflikt stehen, selbst wenn Sie niemals in die Datei schreiben. Dito für Umbenennungen.

Und hier wird es schlimmer. Abgesehen vom Öffnen zum Lesen oder Schreiben bietet die C / C ++ - API keine Möglichkeit, anzugeben, was Sie mit der Datei tun möchten. Die API muss also davon ausgehen, dass Sie einen legalen Vorgang ausführen werden. Da das Sperren obligatorisch ist, wird ein Open, das eine Konfliktoperation zulässt, abgelehnt, selbst wenn der Code niemals die Konfliktoperation ausführen wollte, sondern die Datei nur für einen anderen Zweck öffnete.

Wenn der Code also die C / C ++ - API oder die native API verwendet, ohne sich speziell mit diesen Problemen zu beschäftigen, wird letztendlich die maximale Anzahl möglicher Operationen für jede geöffnete Datei verhindert, und es ist nicht möglich, eine Datei zu öffnen, es sei denn, bei jeder möglichen Operation Wenn es geöffnet werden kann, ist es unbestritten.

Meiner Meinung nach würde die Windows-Methode viel besser funktionieren als die UNIX-Methode, wenn jedes Programm seine Share-Modi und Open-Modi mit Bedacht auswählt und Fehlerfälle auf sanfte Weise behandelt. Die UNIX-Methode funktioniert jedoch besser, wenn sich der Code nicht mit diesen Problemen beschäftigt. Leider kann die grundlegende C / C ++ - API nicht so gut auf die Windows-Datei-API abgebildet werden, dass Freigabemodi gehandhabt werden und Konflikte gut geöffnet werden. Das Nettoergebnis ist also etwas chaotisch.

Da haben Sie es: Zwei unterschiedliche Ansätze zur Dateibehandlung führen zu zwei unterschiedlichen Ergebnissen.

Haben Sie der Erklärung etwas hinzuzufügen? Ton aus in den Kommentaren. Möchten Sie mehr Antworten von anderen technisch versierten Stack Exchange-Benutzern lesen? Hier geht es zum vollständigen Diskussionsthread.