Ob ausgeführter Code in einer Datei gesperrt werden soll oder nicht, ist eine Entwurfsentscheidung, und MS hat sich einfach für das Sperren entschieden, da dies in der Praxis klare Vorteile bietet: Auf diese Weise müssen Sie nicht wissen, welcher Code in welcher Version von welcher Anwendung verwendet wird. Dies ist ein großes Problem mit dem Standardverhalten von Linux, das von den meisten Menschen einfach ignoriert wird. Wenn systemweite Bibliotheken ersetzt werden, können Sie nicht leicht erkennen, welche Apps den Code solcher Bibliotheken verwenden. In den meisten Fällen ist das Beste, was Sie erhalten können, dass der Paketmanager einige Benutzer dieser Bibliotheken kennt und sie neu startet. Aber das funktioniert nur für allgemeine und gut bekannte Dinge wie vielleicht Postgres und seine Bibliotheken oder so. Die interessanteren Szenarien sind, wenn Sie Ihre eigene Anwendung für einige Bibliotheken von Drittanbietern entwickeln und diese ersetzt werden, da der Paketmanager Ihre App meistens einfach nicht kennt. Und das' Dies ist nicht nur ein Problem mit nativem C-Code oder Ähnlichem, sondern kann auch bei fast allem auftreten: Verwenden Sie einfach httpd mit mod_perl und einigen Perl-Bibliotheken, die mit einem Paketmanager installiert wurden, und lassen Sie den Paketmanager diese Perl-Bibliotheken aus irgendeinem Grund aktualisieren. Ihr httpd wird nicht neu gestartet, nur weil er die Abhängigkeiten nicht kennt. Es gibt viele Beispiele wie dieses, einfach weil jede Datei möglicherweise Code enthalten kann, der zu jeder Laufzeit im Speicher verwendet wird. Denken Sie an Java, Python und all diese Dinge.
Es gibt also einen guten Grund, die Meinung zu vertreten, dass das Sperren von Dateien standardmäßig eine gute Wahl sein kann. Sie müssen diesen Gründen jedoch nicht zustimmen.
Was hat MS getan? Sie haben einfach eine API erstellt, mit der die aufrufende Anwendung entscheiden kann, ob Dateien gesperrt werden sollen oder nicht. Sie haben jedoch entschieden, dass der Standardwert dieser API darin besteht, der ersten aufrufenden Anwendung eine exklusive Sperre bereitzustellen. Schauen Sie sich die API rund um CreateFile und seine andwShareMode Argumente an. Dies ist der Grund, warum Sie möglicherweise nicht in der Lage sind, Dateien zu löschen, die von einer Anwendung verwendet werden. Ihr Anwendungsfall ist einfach egal, Sie haben die Standardwerte verwendet und daher von Windows eine exklusive Sperre für eine Datei erhalten.
Bitte glauben Sie nicht an Leute, die Ihnen etwas über Windows erzählen. Sie verwenden keine Ref-Zählung für GRIFFE oder unterstützen keine Hardlinks oder ähnliches, das ist völlig falsch. Fast jede API, die HANDLEs verwendet, dokumentiert ihr Verhalten in Bezug auf das Ref-Zählen, und Sie können in fast jedem Artikel über NTFS leicht lesen, dass es in der Tat Hardlinks unterstützt und dies immer getan hat. Seit Windows Vista werden auch Symlinks unterstützt, und die Unterstützung für Hardlinks wurde verbessert, indem APIs bereitgestellt wurden, mit denen alle für eine bestimmte Datei gelesen werden können usw. .
Darüber hinaus möchten Sie vielleicht einfach einen Blick auf die Strukturen werfen, die zur Beschreibung einer Datei in z. B. Ext4 verwendet werden, im Vergleich zu denen von NTFS , die viel gemeinsam haben. Beide arbeiten mit dem Konzept von Extents, das Daten von Attributen wie Dateinamen trennt, und Inodes sind so ziemlich nur ein anderer Name für ein älteres, aber ähnliches Konzept. Sogar Wikipedia listet beide Dateisysteme in seinem Artikel auf .
Im Vergleich zu anderen Betriebssystemen im Internet gibt es in Windows wirklich viel FUD beim Sperren von Dateien, genau wie bei der Defragmentierung. Einige dieser FUD können durch einfaches Lesen in der Wikipedia ausgeschlossen werden .