| Zeile 14: | Zeile 14: | ||
Auf der Treiberseite baut LostIO auf einem Dateisystem-Baum (Intern als vfstree benannt) im Speicher auf. Dieser Baum besteht aus sogenannten Knoten(engl. nodes), die alle wieder Kinderknoten haben können. Jeder dieser Knoten hat einen bestimmten Typ, der für die Handhabung dessen eine zentrale Rolle spielt. Dabei ist ein Verzeichnis vom Prizip her genau das selbe wie jede andere Datei. werden muss. In den Knoten wird dabei nur eine Typen-ID abgespeichert. Wird nun von einem Prozess versucht irgend eine Datei oder ein Verzeichnis zu öffnen und auszulesen, wird intern in der Typendatenbank nach dem Typen des zu öffnenden Knotens gesucht, um herauszufinden, wie die Aktion gehandhabt. | Auf der Treiberseite baut LostIO auf einem Dateisystem-Baum (Intern als vfstree benannt) im Speicher auf. Dieser Baum besteht aus sogenannten Knoten(engl. nodes), die alle wieder Kinderknoten haben können. Jeder dieser Knoten hat einen bestimmten Typ, der für die Handhabung dessen eine zentrale Rolle spielt. Dabei ist ein Verzeichnis vom Prizip her genau das selbe wie jede andere Datei. werden muss. In den Knoten wird dabei nur eine Typen-ID abgespeichert. Wird nun von einem Prozess versucht irgend eine Datei oder ein Verzeichnis zu öffnen und auszulesen, wird intern in der Typendatenbank nach dem Typen des zu öffnenden Knotens gesucht, um herauszufinden, wie die Aktion gehandhabt. | ||
| − | Die Typendatenbank beinhaltet die sogenannten Typehandles. Darin sind Pointer auf die Funktionen, die ausgeführt werden, wenn ein Prozess zum Beispiel versucht Daten von einem Knoten dieses Typs zu lesen. | + | Die Typendatenbank beinhaltet die sogenannten Typehandles. Darin sind Pointer auf die Funktionen, die ausgeführt werden, wenn ein Prozess zum Beispiel versucht Daten von einem Knoten dieses Typs zu lesen. Momentan können Handler (eben diese Funktionen) für die folgenden Aktionen eingetragen werden: |
* pre_open | * pre_open | ||
* post_open | * post_open | ||
| Zeile 24: | Zeile 24: | ||
===pre_open und post_open=== | ===pre_open und post_open=== | ||
| − | Als unklar und nicht unbedingt sinnvoll könnte ''pre_open'' und ''post_open'' aufgefasst werden. Warum 2 Funktionen für Open? Nun zuerst zur Funktionsweise: ''pre_open'' wird, wie der Name schon ahnen lässt, vor dem eigentlichen | + | Als unklar und nicht unbedingt sinnvoll könnte ''pre_open'' und ''post_open'' aufgefasst werden. Warum 2 Funktionen für Open? Nun zuerst zur Funktionsweise: ''pre_open'' wird, wie der Name schon ahnen lässt, vor dem eigentlichen Öffnungs-Vorgang aufgerufen. Das geschieht auch, wenn der Knoten mit dem angegebenen Pfad nicht existiert. ''post_open'' wird erst nach dem Öffnen gestartet. Von ''post_open'' aus kann der Vorgang nicht mehr einfach so gestoppt werden, was aus ''pre_open'' problemlos möglich ist. |
Bei “echten” Dateisystemen wie zum Beispiel auf Disketten hat ''pre_open'' noch eine spezielle Aufgabe. Da die Verzeichnisbäume von physikalischen Dateisystemen extreme Ausmasse annehmen können, sodass es belastend, oder sogar unmöglich wäre, diese vollständig im Arbeitsspeicher zu haben, besteht die Möglichkeit nur einen Teil davon im Arbeitsspeicher zu haben, und andere Teile nach gebrauch wieder zu entfernen. Und genau hier kommt ''pre_open'' wieder ins Spiel. Da er angesprungen wird, egal ob der Pfad existiert oder nicht, kann daraus bei Bedarf ein Teil des Verzeichnisbaumes geladen werden. | Bei “echten” Dateisystemen wie zum Beispiel auf Disketten hat ''pre_open'' noch eine spezielle Aufgabe. Da die Verzeichnisbäume von physikalischen Dateisystemen extreme Ausmasse annehmen können, sodass es belastend, oder sogar unmöglich wäre, diese vollständig im Arbeitsspeicher zu haben, besteht die Möglichkeit nur einen Teil davon im Arbeitsspeicher zu haben, und andere Teile nach gebrauch wieder zu entfernen. Und genau hier kommt ''pre_open'' wieder ins Spiel. Da er angesprungen wird, egal ob der Pfad existiert oder nicht, kann daraus bei Bedarf ein Teil des Verzeichnisbaumes geladen werden. | ||