DE69838756T2 - Die verarbeitung von eingabe/ausgabeanforderungen von mehreren treibern ermöglichen dateisystem-primitivroutine in einem mehrschicht-treiber-e/a-system - Google Patents

Die verarbeitung von eingabe/ausgabeanforderungen von mehreren treibern ermöglichen dateisystem-primitivroutine in einem mehrschicht-treiber-e/a-system Download PDF

Info

Publication number
DE69838756T2
DE69838756T2 DE69838756T DE69838756T DE69838756T2 DE 69838756 T2 DE69838756 T2 DE 69838756T2 DE 69838756 T DE69838756 T DE 69838756T DE 69838756 T DE69838756 T DE 69838756T DE 69838756 T2 DE69838756 T2 DE 69838756T2
Authority
DE
Germany
Prior art keywords
driver
request
processing
file
reparse point
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69838756T
Other languages
English (en)
Other versions
DE69838756D1 (de
Inventor
Luis Felipe Bellevue Cabrera
Gary D. Kirkland KIMURA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority claimed from PCT/US1998/007595 external-priority patent/WO1998047074A1/en
Publication of DE69838756D1 publication Critical patent/DE69838756D1/de
Application granted granted Critical
Publication of DE69838756T2 publication Critical patent/DE69838756T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

  • 1. GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft Systeme und Verfahren, um zahlreichen Treibern in einem E/A-System die Beteiligung an der Verarbeitung einer E/A-Anforderung zu gestatten. Insbesondere gestattet die vorliegende Erfindung einem Treiber, die normale Abfolge beim Verarbeiten einer E/A-Anforderung zu unterbrechen, um die Steuerung an einen anderen Treiber zur weiteren Verarbeitung der E/A-Anforderung zu übergeben.
  • 2. STAND DER TECHNIK
  • Ein funktionsfähiges Computersystem besteht im Allgemeinen aus drei grundlegenden Komponenten. Die erste Komponente ist die Computer-Hardware. Die Computer-Hardware umfasst solche Vorrichtungen wie beispielsweise eine Zentraleinheit (CPU), einen Systemspeicher wie beispielsweise RAM oder ROM, einen Massenspeicher wie beispielsweise einen Magnet- oder Bildplattenspeicher, eine Tastatur oder andere Eingabevorrichtung und eine Anzeige- oder andere Ausgabevorrichtung. Benutzer von Computersystemen wirken im Allgemeinen mit Benutzer- oder Anwendungsprogrammen zusammen. Solche Programme umfassen die bekannten Textverarbeitungsanwendungen, Tabellenkalkulationsanwendungen, Datenbankanwendungen und so weiter. Die letzte Komponente eines modernen funktionsfähigen Computersystems ist ein Betriebssystem. Das Computer-Betriebssystem führt viele Funktionen durch, wie beispielsweise, dass es einem Benutzer gestattet, die Ausführung eines Anwendungsprogramms zu initiieren. Außerdem stellen moderne Betriebssysteme auch eine Schnittstelle zwischen einem Anwendungsprogramm und der Computersystem-Hardware bereit. Während es früher für ein Anwendungsprogramm allgemein üblich war, direkt auf die Computersystem-Hardware zuzugreifen, stellen moderne Betriebssysteme standardisierte, konsistente Schnittstellen bereit, die es Benutzeranwendungen gestatten, mit Computer-Hardware Schnittstellen zu bilden oder auf diese in standardisierter Weise zuzugreifen.
  • Um eine konsistente Schnittstelle zwischen einem Prozess, wie beispielsweise einer Benutzeranwendung, und einem bestimmten Typ von Hardware-Vorrichtungen bereitzu stellen, können mehrere Software-Schichten zwischen der eigentlichen Hardware und dem Prozess vorhanden sein. Zum Beispiel kann ein Prozess einen Aufruf in das Betriebssystem vornehmen. Das Betriebssystem kann seinerseits die Dienste nutzen, die von einer Hardware-Treiberschicht bereitgestellt werden. Die Hardware-Treiberschicht bildet dann direkt eine Schnittstelle mit der Hardware. Ein primärer Vorteil eines solchen Ansatzes der Schichtenbildung besteht darin, dass Schichten hinzugefügt oder ersetzt werden können, ohne dadurch eine enorme Auswirkung auf die restlichen Schichten zu verursachen. Wenn zum Beispiel eine neue Hardware-Vorrichtung zu einem System hinzugefügt wird, kann ein neuer Treiber hinzugefügt werden, der es dem Betriebssystem gestattet, auf die Hardware zuzugreifen. Alle diese Änderungen können mit minimaler oder gar keiner Auswirkung auf bestehende Anwendungsprozesse stattfinden.
  • Wenn Treiber verwendet werden, um mit Hardware-Vorrichtungen Schnittstellen zu bilden, ging der Trend herkömmlicherweise dahin, monolithische Treiber zu erstellen, die jede Funktionalität integrieren, die für die Schnittstellenbildung eines Betriebssystems mit einer bestimmten Hardware-Vorrichtung benötigt wird. In letzter Zeit wurden Betriebssysteme entwickelt, die mehrere Treiber zum Durchführen von E/A-Aufgaben verwenden. Beispiele dafür sind besonders häufig, wenn es sich um E/A-Anforderungen an Platten- oder andere Massenspeicher handelt.
  • Daten werden typischerweise hierarchisch in Massenspeichervorrichtungen gespeichert, wobei Verzeichnisse und Dateien in einer Hierarchie aufgebaut sind, die einer Baumstruktur ähneln. Der Speicherplatz jeder Datei bzw. jedes Verzeichnisses wird üblicherweise durch einen Datei-Pfadnamen angegeben. Der Pfadname beginnt typischerweise mit einem Stamm- oder Anfangsverzeichnis und benennt jedes Unterverzeichnis, bis die gewünschte Datei bzw. das gewünschte Verzeichnis erreicht ist. Zum Beispiel kann eine Datei mit der Bezeichnung "file.dat" im Verzeichnis "temp" gespeichert sein, das ein Unterverzeichnis des Stammverzeichnisses "root" ist. Der Pfadname würde somit /root/temp/file.dat lauten. Das Auflösen von Dateinamen in einem Dateisystem ist üblicherweise eine mehrstufige Prozedur. Im Allgemeinen beginnt sie mit der Stufe, die alle der benannten Komponenten decodiert, die von dem Dateisystem erfolgreich identifiziert werden müssen. Die Prozedur fährt dann mit einem iterativen Prozess, üblicherweise von links nach rechts, zum Identifizieren der nachfolgenden Komponenten in dem Dateinamen fort. Die Prozedur endet mit einer erfolgreichen oder fehlgeschlagenen Auflö sung jeder dieser Namen. In dem oben genannten Beispiel würde der Pfadname daher in aufeinander folgende Komponenten gegliedert, und der Auflösungsprozess würde seinerseits das Stammverzeichnis, das temp-Unterverzeichnis und die Datei file.dat identifizieren.
  • Die meisten UNIX-System gestatten, dass mehrere Datenmanager in einer Installation nebeneinander vorhanden sind. Um dies zu erreichen, wird der hierarchische Datennamenraum in Unterbäume von Datei- und Verzeichnisnamen unterteilt. Ein zweckbestimmter Datenmanager verwaltet dann jeden Unterbaum. Wenn eine E/A-Anforderung vorgenommen wird, löst der Namen-Auflösungsprozess den Namen zu einem bestimmten Unterbaum auf, und die E/A-Anforderung kann von dem Datenmanager für diesen Unterbaum abgewickelt werden. Der Datenmanager kann dann das eingebaute UNIX-Dateisystem aufrufen, um das eigentliche Speichern und Abrufen von Daten durchzuführen. Somit wirken die Datenmanager als eine Mehrwertkomponente, die die Fähigkeiten eines bestimmten Dateisystems erweitert.
  • Wenn mehrere Datenmanager in einem UNIX-E/A-System vorhanden sind, wird das Weiterleiten der Anforderung zum richtigen Datenmanager durch den Mechanismus von "Einhängepunkten" (mount points) erreicht. Ein Einhängepunkt wird in dem Namensraum eingerichtet, um jeden der Unterbäume darzustellen. Wenn während des Namen-Auflösungsprozesses ein Einhängepunkt angetroffen wird, leitet das UNIX-E/A-System die Anforderung zum entsprechenden Datenmanager, der für die Verwaltung des Unterbaums verantwortlich ist, der durch den Einhängepunkt dargestellt wird. Der entsprechende Datenmanager fährt dann mit dem Namen-Auflösungsprozess fort.
  • Das standardmäßige UNIX-Dateisystem unterstützt auch symbolische Verknüpfungen. Symbolische Verknüpfungen stellen einen eingebauten Fall dar, in dem die Prozedur zum Auflösen eines Namens unter Verwendung eines zweiten Namens von neuem begonnen wird. Wenn eine symbolische Verknüpfung angetroffen wird, wird ein Dateiname blind durch einen anderen ersetzt, und der Namen-Auflösungsprozess beginnt mit dem ersetzten Namen von vorne.
  • "A Comparison of Three Distributed File System Architectures: Vnode, Sprite and Plan 9", Computing Systems, Bd. 7, Nr. 2, Frühjahr 1994, XP 000577569 beschreibt die Pfadnamenauflösung durch das verteilte Dateisystem von Sprite. Das Betriebssystem eines Client gleicht Pfadnamen mit einem Cache von Pfadnamen-Präfixen ab, und der längste übereinstimmende Eintrag legt den Server für den Pfadnamen fest. Der restliche Teil des Pfadnamens wird diesem Server zur Verarbeitung übergeben. Wenn der Pfadname den Unterbaum übrig lässt, der durch diesen Server implementiert wurde, dann wird eine symbolische Verknüpfung an Punkten angeordnet, an denen andere Unterbäume, (d. h. Einhängepunkte), angefügt sind, deren Inhalt der absolute Pfadname des entsprechenden Servers ist und der das Präfix für Namen unter diesem Punkt ist. Wenn ein Server auf eine entfernte Verknüpfung trifft, kombiniert er den Verknüpfungswert mit dem restlichen Pfadnamen, um einen neuen Pfadnamen zu erstellen, der zusammen mit einer Angabe, welcher Teil des Pfadnamens das gültige Präfix ist, an den Client zurückgegeben wird. Wenn ein neues Präfix an den Client zurückgegeben wird, nimmt der Client ein Rundsenden vor, um den Server für dieses Präfix ausfindig zu machen. Sobald der Server gefunden ist, wird der Suchlauf erneut gestartet, und der Pfadname stimmt auf dem neuen längeren Präfix überein, so dass der Suchlauf an den richtigen Server gerichtet wird.
  • Systeme des bisherigen Stands der Technik haben daher mehrere Datenmanager eingesetzt, um verschiedene Teile des Adressraums zu verwalten. Diese Datenmanager waren auch in der Lage, mit dem Standard-Dateisystem zusammenzuwirken, um eine E/A-Anforderung zu verarbeiten. Das in Systemen des bisherigen Stands der Technik verwendete Modell war jedoch relativ deterministisch und konnte nicht erweitert werden, um Szenarios abzudecken, die ihre Entwicklern nicht vorgesehen hatten. Mit anderen Worten, die Interaktion zwischen einem Datenmanager und dem Dateisystem ist relativ festgelegt, wobei beide eine definierte Aufgabe durchführen. Es wäre schwierig, entweder den Datenmanager oder das Dateisystem zu entfernen und sie durch eine andere Komponente zu ersetzen, um eine andere Funktion durchzuführen. Zu versuchen, einen anderen Manager in dem System zu platzieren, um eine andere Funktion als die Verwaltung eines Unterbaums durchzuführen, wäre unter Verwendung der vorhandenen Treibermodelle desgleichen ebenfalls schwierig, wenn nicht unmöglich. Es wäre deshalb wünschenswert, ein Verfahren bereitzustellen, das es mehreren Komponenten gestattet, bei der Verarbeitung einer E/A-Anforderung zusammenzuarbeiten, wobei die Anzahl von Komponenten nicht festgelegt ist und erweitert oder beliebig modifiziert werden kann, um neue Komponenten hinzuzufügen, die Funktionen abwickeln, die nicht vorgesehen waren, als das System eingerichtet wurde. Es wäre auch wünschenswert, das Ersetzen einer beliebigen Komponente zu gestatten, ohne damit für die restlichen Komponenten eine größere Unterbrechung zu verursachen.
  • Ein weiteres Problem beim bisherigen Stand der Technik besteht darin, dass, obwohl mehrere Datenmanager verwendet werden, ihre Beteiligung an dem Namen-Auflösungsprozess auf den Namensraum begrenzt ist, über den sie die Kontrolle haben. Mit anderen Worten, wenn mehrere Einhängepunkte identifiziert werden müssen, müssen mehrere Datenmanager installiert sein, von denen jeder einen bestimmten Einhängepunkt abwickelt. Es wäre wünschenswert, es einem einzigen Datenmanager zu gestatten, mehrere Einhängepunkte oder Unterbäume von Informationen zu verwalten.
  • Was deshalb benötigt wird, ist ein Mechanismus zum dynamischen Erweitern und Neukonfigurieren eines E/A-Systems, das eine Vielzahl von Datenmanagern oder Treibern zum Verarbeiten von E/A-Anforderungen verwendet. Es wäre ebenfalls wünschenswert, einer solchen Neukonfiguration eine Erweiterung mit minimaler Auswirkung auf die anderen Datenmanager oder Treiber in dem System zu gestatten.
  • KURZDARSTELLUNG DER ERFINDUNG
  • Die vorgenannten Probleme beim bisherigen Stand der Technik wurden durch die vorliegende Erfindung erfolgreich gelöst, die ein System und ein Verfahren zum Unterbrechen der normalen Verarbeitungsfolge in einem E/A-System und das Übertragen der Steuerung von einem Datenmanager oder Treiber zu einem anderen Datenmanager oder Treiber betrifft. Die vorliegende Erfindung ist insbesondere nützlich in einem E/A-System, das eine Vielzahl von Treibern oder Datenmanagern zum Durchführen verschiedener Verarbeitungsfunktionen beim Ausführen einer E/A-Anforderung verwendet.
  • Gemäß der vorliegenden Erfindung wird ein Verfahren zum Unterbrechen der Verarbeitungsfolge in einem E/A-System bereitgestellt, das eine Vielzahl von in Schichten angeordneten Treibereinrichtungen zur Verarbeitung von E/A-Anforderungen verwendet, wobei die Vielzahl von in Schichten angeordneten Treibereinrichtungen eine erste Treibereinrichtung und eine zweite Treibereinrichtung umfassen, wobei das Verfahren die folgenden Schritte aufweist: Empfangen einer E/A-Anforderung durch eine erste Treiber einrichtung, um eine angegebene E/A-Operation auszuführen; und Bestimmen durch die erste Treibereinrichtung, ob die E/A-Anforderung eine zumindest teilweise Verarbeitung durch eine andere Treibereinrichtung erfordert, indem bestimmt wird, ob die E/A-Anforderung zumindest eines von einer Datei oder einem Verzeichnis mit einem zugehörigen Attribut eines Reparse-Punkts beinhaltet, wobei das Reparse-Punkt-Attribut Informationen zum Reparse-Punkt mit Daten enthält, die einen speziellen Treber bestimmen, der zumindest einen Teil der E/A-Anforderung und Daten verarbeiten soll, die von dem speziellen Treiber bei der Verarbeitung zumindest eines Teils der E/A-Anforderung verwendet werden; wobei, wenn zumindest entweder die Datei oder das Verzeichnis ein zugehöriges Reparse-Punkt-Attribut haben, die erste Treibereinrichtung Folgendes ausführt: Extrahieren der Informationen zum Reparse-Punkt, die zumindest mit einem von der Datei oder dem Verzeichnis verknüpft sind; und Übergeben der extrahierten Informationen zum Reparse-Punkt an die zweite Treibereinrichtung zur Verarbeitung, wobei die zweite Treibereinrichtung die extrahierten Informationen zum Reparse-Punkt prüft, um zu ermitteln, ob die zweite Treibereinrichtung der spezielle Treiber ist, und falls dies so ist, die zweite Treibereinrichtung zumindest einen Teil der E/A-Anforderung verarbeitet.
  • In einem System, in dem eine Vielzahl von Treibern oder Datenmanagern zusammenwirkt, um eine E/A-Anforderung zu erfüllen, weisen die Treiber oder Datenmanager oft eine Schichtenbeziehung auf, wobei jeder Treiber verschiedene Typen von Funktionen durchführt, um die E/A-Anforderung zu erfüllen. Zum Beispiel kann ein E/A-System einen Dateisystemtreiber umfassen, der in einer Schicht über dem Vorrichtungstreiber angeordnet ist. Wenn eine E/A-Anforderung empfangen wird, kann der Dateisystemtreiber gewisse Funktionen durchführen, wie beispielsweise den Dateinamen auflösen und den Dateinamen in einen bestimmten Speicherplatz auf der Platte übersetzen. Der bestimmte Speicherplatz auf der Platte kann dann an den Vorrichtungstreiber übergeben werden, der den richtigen Speicherplatz auf der Platte findet und die gewünschten Informationen liest oder schreibt. Andere Treiber können ebenfalls in Schichten über oder unter dem Dateisystemtreiber angeordnet werden. Zum Beispiel kann es wünschenswert sein, einen redundanten Dateisystemtreiber zwischen dem Dateisystemtreiber und dem Vorrichtungstreiber bereitzustellen. Der redundante Dateisystemtreiber kann dann eine Datenspiegelung vornehmen, um Daten auf mehrere Speicherplätze auf einer Platte zu spiegeln oder um Daten auf mehrere Platten zu spiegeln.
  • In den herkömmlichen, in Schichten angeordneten Treibermodellen werden Informationen von einer Schicht zur anderen übergeben, wobei jede Schicht ihre verschiedenen Aufgaben durchführt, bevor die Anforderung an die andere Schicht übergeben wird. In einigen Fällen ist es extrem nützlich, die normale Verarbeitungsfolge unterbrechen und die Steuerung zur Abwicklung von wenigstens einem Teil der E/A-Anforderung an einen anderen Treiber übergeben zu können. Zum Beispiel ist es vielleicht von Bedeutung, gewisse Dateien an einem speziellen Speicherplatz zu speichern. Ein Treiber kann konzipiert werden, der den Zugriff auf die Dateien verwaltet, die in dem speziellen Speicherplatz gespeichert sind. Wenn der Dateisystemtreiber den Namen auf den speziellen Speicherplatz auflöst, wäre es daher wünschenswert, die Steuerung der E/A-Anforderung an den Treiber zu übergeben, der diese Informationen bearbeitet, statt die E/A-Anforderung an den normalen Vorrichtungstreiber zu übergeben.
  • Die vorliegende Erfindung gestattet die Unterbrechung der normalen Verarbeitungsfolge und die Übertragung der E/A-Anforderung an einen bestimmten Treiber. Das Verfahren der vorliegenden Erfindung ist dynamisch erweiterbar, und ein System kann konfiguriert werden, um Treiber hinzuzufügen oder zu entfernen, ohne den Betrieb der anderen Treiber zu unterbrechen. Um dies zu erreichen, wird ein neues Verzeichnis- und Dateiattribut definiert, das als "Reparse-Punkt"-Attribut bezeichnet wird. Das Reparse-Punkt-Attribut ist additiv, so dass einzelne Dateien und Verzeichnisse entweder Reparse-Punkte sein können oder nicht, was vom Status des Reparse-Punkt-Attributs abhängt.
  • Ein Reparse-Punkt-Attribut weist vorzugsweise sowohl ein Identifizierungskennzeichen (tag) als auch einen Datenwert auf. Das Tag wird verwendet, um den Treiber zu identifizieren, der der "Eigentümer" des Reparse-Punkts ist. Im Allgemeinen ist der Eigentümer des Reparse-Punkts für die Verarbeitung der gesamten oder eines Teils der E/A-Anforderung, die den Reparse-Punkte enthält. Der Datenwert sind Daten, die in dem Reparse-Punkt von dem Eigentümer gespeichert werden. Somit kann ein Eigentümer den Wert des Reparse-Punkts nutzen, um alle Daten zu speichern, die notwendig oder hilfreich sind, um eine bestimmte E/A-Anforderung abzuarbeiten, die den Reparse-Punkt enthält.
  • Wenn in einer Ausführungsform, die eine Vielzahl von in Schichten angeordneten Treiben umfasst, ein Reparse-Punkt-Attribut durch einen bestimmten Treiber identifiziert wird, extrahiert der Treiber das Tag und den Wert des Reparse-Punkts. Dann wird die E/A-Anforderung zusammen mit dem Tag und dem Wert des Reparse-Punkts an andere Treiber übergeben, bis einer sich als der Eigentümer des Reparse-Punkts identifiziert. Der Eigentümer übernimmt dann die Steuerung und nimmt die Verarbeitung der E/A-Anforderung wieder auf. Der Eigentümer eines Reparse-Punkts kann eine E/A-Anforderung vollständig verarbeiten oder andere Treiber in Anspruch nehmen, um die E/A-Anforderung vollständig zu verarbeiten. Der Eigentümer kann auch andere Computer nutzen, um die E/A-Anforderung vollständig zu verarbeiten.
  • Weil jeder Reparse-Punkt sowohl ein Tag als auch einen Wert aufweist, stellt der Reparse-Punkt-Mechanismus eine extrem flexible Struktur bereit, die von einer beliebigen Anzahl von Treibern verwendet werden kann, um eine beliebige Anzahl von Funktionen auszuführen. Zum Beispiel kann die Steuerung an den Manager eines hierarchischen Speichers übergeben werden, um automatisch Daten zu verwalten, die vom lokalen Speicher in den Archivspeicher migriert sind. Als weiteres Beispiel kann die Steuerung an einen verteilten Dateimanager übergeben werden, der Dateien verwaltet, die auf einer Vielzahl von verschiedenen Plattenlaufwerken gespeichert sind. Als noch weiteres Beispiel kann die Steuerung an einen Sicherheitsdateimanager übergeben werden, der Dateien verwaltet, die in einem sicheren Speicherplatz oder in einem verschlüsselten Format gespeichert sind. Im Wesentlichen erleichtert die vorliegende Erfindung das Unterbrechen der normalen Verarbeitungsfolge und Übertragen der Steuerung an einen anderen Treiber zum Abwickeln spezieller Verarbeitungserfordernisse von speziellen Datei- oder Verzeichnistypen. Der Mechanismus stellt eine kohärente Methodologie zum Erweitern der Fähigkeiten eines E/A-Systems bereit, um die sich mit der Zeit ändernden Erfordernisse abzudecken.
  • Die vorliegende Erfindung ist breit genug ausgelegt, um die Fähigkeiten eines E/A-Systems über die standardmäßigen E/A-Operationen hinaus zu erweitern, die normalerweise von einem E/A-System unterstützt werden. Ein Treiber oder Manager kann entwickelt werden, mit denen veranlasst wird, dass eine standardmäßige E/A-Operation zu Aktionen führt, die nichts mit standardmäßigen E/A-Operationen zu tun haben. Zum Beispiel können Reparse-Punkte im Kontext von Heimautomation verwendet werden, um eine beliebige Anzahl von Zielen zu erreichen. Ein Reparse-Punkt kann verwendet werden, um die Polizei oder Feuerwehr zu rufen. Eine mögliche Implementierung kann zum Beispiel einen Reparse-Punkt erstellen und die Telefonnummer der Polizei oder Feuerwehr als Teil des Reparse-Punkts speichern. Wenn das E/A-System auf den Reparse-Punkt zugreift, würde der Treiber, der Eigentümer des Reparse-Punkts ist, die Verarbeitungssteuerung erhalten, wie oben beschrieben wurde. Der Eigentümer könnte dann die entsprechende Telefonnummer abrufen, sie über ein Modem oder ein anderes System anwählen und Benachrichtigungen, Informationen, Sprache und so weiter an die angerufene Entität senden. Die vorliegende Erfindung kann in einer beliebigen Anzahl von anderen Situationen verwendet werden, um eine standardmäßige E/A-Operation zum Erreichen eines Ergebnisses zu verwenden, das nichts mit standardmäßigen E/A-Operationen zu tun hat.
  • Zusätzliche Vorteile der Erfindung werden in der folgenden Beschreibung dargelegt und gehen teilweise aus der Beschreibung hervor oder lassen sich durch Ausübung der Erfindung erfahren. Die Vorteile der Erfindung können mittels Instrumenten und Kombinationen verwirklicht und erhalten werden, auf die in den Ansprüchen im Anhang besonders hingewiesen wird. Diese und andere Merkmale der vorliegenden Erfindung werden vollständig aus der folgenden Beschreibung und den Ansprüchen im Anhang ersichtlich, oder lassen sich durch die Ausübung der Erfindung, wie im Folgenden dargelegt, erfahren.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Um die Art und Weise zu beschreiben, in der die oben genannten und andere Vorteile der Erfindung erzielt werden, wird die oben kurz beschriebene Erfindung unter Bezugnahme auf ihre spezifischen Ausführungsformen, die in den Zeichnungen im Anhang veranschaulicht sind, ausführlicher beschrieben. Einvemehmlich dessen, dass diese Zeichnungen nur typische Ausführungsformen der Erfindung darstellen und daher nicht als ihren Umfang einschränkend zu betrachten sind, wird die Erfindung mit zusätzlicher Genauigkeit und Ausführlichkeit unter Verwendung der folgenden begleitenden Zeichnungen beschrieben und erläutert:
  • 1 ist ein Schaubild, das ein E/A-System darstellt, das in Schichten angeordnete Treiber verwendet;
  • 2 ist ein Schaubild, das die Übertragung der Steuerung von einem in Schichten angeordneten Treiber zu einem anderen in Schichten angeordneten Treiber veranschaulicht, wenn ein Reparse-Punkt-Attribut angetroffen wird;
  • 3 ist ein Schaubild, das die Attribute einer Datei oder eines Verzeichnisses veranschaulicht, die für die Verwendung mit der vorliegenden Erfindung geeignet sind;
  • 4 ist ein Schaubild, das die Dienste veranschaulicht, die von zwei in Schichten angeordneten Treibern bereitgestellt werden, und die allgemeine Funktionalität zeigt, die von der vorliegenden Erfindung in die Treiber integriert wird;
  • 5 ist ein Beispiel, das veranschaulicht, wie die vorliegenden Erfindung verwendet werden kann, um eine E/A-Anforderung mit Beteiligung eines Reparse-Punkts zu verarbeiten;
  • 6 ist ein Schaubild, das die Verzeichnisstruktur des in 5 dargestellten Beispiels veranschaulicht;
  • 7 ist ein Schaubild, das ein Beispiel veranschaulicht, in dem ein weiterer Rechner zum Abarbeiten einer E/A-Anforderung verwendet wird; und
  • 8 ist ein Schaubild, das veranschaulicht, wie die vorliegende Erfindung die Fähigkeiten eines E/A-Systems erweitert.
  • AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Die Erfindung wird im Folgenden unter Verwendung von Schaubildern zum Veranschaulichen von entweder der Struktur oder der Verarbeitung von Ausführungsformen beschrieben, die zum Implementieren des Systems und des Verfahrens der vorliegenden Erfindung verwendet werden. Die derartige Verwendung der Schaubilder zum Darstellen der Erfindung sollte nicht als Einschränkung ihres Umfangs interpretiert werden. Die vorliegende Erfindung betrachtet sowohl Verfahren als auch Systeme zum Unterbrechen der normalen Verarbeitungsfolge in einem E/A-System und zum Übertragen der Steuerung auf einen anderen Treiber zur weiteren Verarbeitung der E/A-Anforderung. Ausführungsformen der vorliegenden Erfindung können einen Sonderzweckrechner oder Mehrzweckrechner umfassen, die eine standardmäßige Computer-Hardware umfassen, wie zum Beispiel eine Zentraleinheit (CPU) oder andere Verarbeitungseinrichtungen zum Ausführen von computerausführbaren Anweisungen, computerlesbare Medien zum Speichern von ausführbaren Anweisungen, eine Anzeige- oder andere Ausgabeeinrichtung zum Anzeigen oder Ausgeben von Informationen, eine Tastatur oder andere Eingabeeinrichtung zum Eingeben von Informationen und so weiter. Da die vorliegende Erfindung so ausgelegt ist, dass sie die Steuerung von einem Treiber zu einem anderen Treiber überträgt, weisen Ausführungsformen innerhalb des Umfangs dieser Erfindung im Allgemeinen ein E/A-System auf, das eine Vielzahl von Treibern oder Datenmanagern verwendet, um E/A-Anforderungen abzuarbeiten. Die vorliegende Erfindung ist jedoch ansonsten nicht durch den Typ von E/A-System eingeschränkt, das über die Computer-Hardware betrieben wird.
  • Ausführungsformen innerhalb des Umfangs der vorliegenden Erfindung umfassen auch computerlesbare Medien mit ausführbaren Anweisungen. Solche computerlesbaren Medien können alle verfügbaren Medien sein, auf die von einem Mehrzweck- oder Sonderzweckrechner zugegriffen werden kann. Beispielhaft und nicht einschränkend können solche computerlesbaren Medien RAM, ROM, EEPROM, CD-ROM oder andere Bildplattenspeicher-, Magnetplattenspeicher- oder andere Magnetspeicher-Vorrichtungen umfassen oder irgendein anderes Medium sein, das zum Speichern der gewünschten ausführbaren Anweisungen verwendet und auf das von einem Mehrzweck- oder Sonderzweckrechner zugegriffen werden kann. Kombinationen des Vorgenannten sollen ebenfalls in dem Umfang der computerlesbaren Medien enthalten sein. Ausführbare Anweisungen umfassen zum Beispiel Anweisungen und Daten, die einen Mehrzweckrechner, einen Sonderzweckrechner oder eine Verarbeitungsvorrichtung für besondere Zwecke veranlassen, eine gewisse Funktion oder Gruppe von Funktionen durchzuführen. Schließlich umfassen Ausführungsformen innerhalb des Umfangs der vorliegenden Erfindung ein computerlesbares Medium mit einer Vielzahl von darauf gespeicherten Datenfeldern, die eine Datenstruktur darstellen.
  • Um den Kontext der vorliegenden Erfindung besser zu verstehen, wird im Folgenden auf 1 Bezug genommen, die ein vereinfachtes Schaubild des Zusammenwirkens zwischen einem Client-Prozess und einem Betriebssystem mit einem E/A-System veranschaulicht, das eine Vielzahl von Treibereinrichtungen zum Verarbeiten vom E/A-Anforderungen verwendet. Dieses Schaubild ist zum Beispiel repräsentativ für das Betriebssystem Windows NT® von Microsoft. Das Schaubild von 1 kann auch jedes beliebige Betriebssystem darstellen, das eine Vielzahl von Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen verwendet.
  • In 1 nutzt der Client-Prozess 20 Betriebssystemdienste 22 zum Durchführen von E/A-Anforderungen. Dies wird typischerweise durch einen Client-Prozess 20 erreicht, der eine Anwenderprogrammschnittstellen-(API)Funktion aufruft, die vom Betriebssystem bereitgestellt wird. Das Aufrufen der entsprechenden API-Funktion führt schließlich zum Aufrufen der Betriebssystemdienste 22. Ein solcher Aufruf wird durch den Pfeil 24 veranschaulicht.
  • In 1 wird der Client-Prozess 20 im Betrieb im "Benutzer"-Modus veranschaulicht, und die Betriebssystemdienste werden im Betrieb im "Kern"-Modus veranschaulicht. Moderne Betriebssysteme stellen typischerweise eine robuste Umgebung für verschiedene Anwendungsprogramme und intuitive Benutzerschnittstellen bereit. Solche Betriebssysteme weisen normalerweise verschiedene Betriebsebenen oder "Modi" auf, die von der Entwicklungsebene des Betriebssystems und den Sicherheitsfunktionen abhängen, die durch das Betriebssystem implementiert sind. Normale Anwendungsprogramme laufen üblicherweise unter der niedrigsten Priorität und weisen ein vollständiges Komplement von Sicherheitsvorrichtungen auf, um eine Störeinwirkung auf andere Anwendungen oder andere Schichten des Betriebssystems zu verhindern. Auf Hardware und andere Dienste, die von dem Betriebssystem bereitgestellt werden, wird nur über gesteuerte Schnittstellen oder Mechanismen zugegriffen, die die Fähigkeit einer Benutzeranwendung oder eines anderen Prozesses im Benutzermodus begrenzen, das System "abstürzen" zu lassen. Die Modus mit niedrigster Priorität wird üblicherweise als Benutzermodus bezeichnet und ist der Modus, mit dem die meisten Computerbenutzer vertraut sind. Aufgrund der engen Integration der Treiber und ihrer dazugehörigen Hardware und aufgrund der zeitkritischen Natur der Aufgaben, die viele Treiber durch führen, laufen viele Treiber typischerweise in einem Betriebssystemmodus, der eine viel höhere Priorität und einen viel niedrigeren Sicherungsschutz aufweist. Dieser Modus wird im Allgemeinen als "Kern"-Modus bezeichnet. Indem die Treiber und andere Betriebssystemdienste in den Kernmodus gestellt werden, wird dem Betriebssystem gestattet, mit einer höheren Priorität zu arbeiten und viele Funktionen durchzuführen, die vom Benutzermodus aus nicht möglich wären.
  • Wenn der Client-Prozess 20 Betriebssystemdienste 22 aufruft, um eine E/A-Anforderung durchzuführen, wird die E/A-Anforderung an eine erste Treibereinrichtung zum Verarbeiten von E/A-Anforderungen übergeben. In 1 stellen der Dateisystemtreiber 26 und Vorrichtungstreiber 28 Beispiele für Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen dar. Das Übergeben der E/A-Anforderung an die erste Treibereinrichtung wird zum Beispiel in 1 durch den Pfeil 30 veranschaulicht. Der Dateisystemtreiber 26 übernimmt dann die E/A-Anforderung und führt im Allgemeinen eine teilweise Verarbeitung der E/A-Anforderung aus, bevor die E/A-Anforderung an den nächsten Treiber übergeben wird. Im Kontext dieses Patents umfasst die "E/A-Anforderung" jeden Typ von E/A-Operation, der durch das E/A-System unterstützt wird. Es ist anzumerken, dass dies viel mehr als die normalen Datei-Operationen enthalten kann, die mit einem E/A-System verbunden sind. Der Begriff kann auch erweiterte Fähigkeiten des E/A-Systems enthalten. Somit sollte der Begriff "E/A-Anforderung" breit gefasst interpretiert werden.
  • Beispielsweise angenommen, der Client-Prozess 20 möchte eine bestimmte Datei auf der Platte öffnen und Informationen aus der Datei abrufen. Die E/A-Anforderung würde von dem Client-Prozess 20 an die Betriebssystemdienste 22 und an den Dateisystemtreiber 26 übergeben. Der Dateisystemtreiber 26 würde dann die E/A-Anforderung von einem Dateinamen in einen bestimmten Speicherplatz auf einer Platte übersetzen. Der Übersetzungsprozess kann auch die Anzahl von Datenblöcken enthalten, die auf der Platte aus dem bestimmten Speicherplatz ausgelesen oder in diesen geschrieben werden sollen. Diese Informationen können dann an den nächsten Treiber übergeben werden, wie zum Beispiel den Vorrichtungstreiber 28. Der Prozess des Übergebens der erforderlichen Informationen durch den Vorrichtungstreiber 28 wird in 1 durch die Pfeile 32 und 34 veranschaulicht. Der Vorrichtungstreiber 28 übernimmt den Speicherplatz und die Anzahl der Datenblöcke, die gelesen oder geschrieben werden sollen, und übersetzt sie in die entsprechenden Steuersignale, um die gewünschten Informationen abzurufen oder die gewünschten Informationen auf der Hardware-Vorrichtung 36 zu speichern. Die abgerufenen Daten können dann von dem Vorrichtungstreiber 28 an den Dateisystemtreiber 26 und schließlich zum Client-Prozess 20 zurück übergeben werden, wie durch die zurückführenden Pfeile 38 angegeben wird. Statusinformationen können auf die gleiche Weise zurückgegeben werden.
  • In 1 werden E/A-Anforderungen nicht direkt zwischen dem Dateisystemtreiber 26 und dem Vorrichtungstreiber 28 übergeben. Stattdessen werden die E/A-Anforderungen zwischen den Treibern über den E/A-Manager 40 übergeben. Es ist jedoch nicht notwendig, in allen Implementierungen einen E/A-Manager zu haben. Es kann auch Ausführungsformen geben, in denen E/A-Anforderungen direkt von einem Treiber an den anderen übergeben werden.
  • Ein wichtiges Konzept, das aus 1 zu ersehen ist, besteht darin, dass, wenn E/A-Anforderungen durch einen Client-Prozess erstellt werden, die Verarbeitungsfolge in herkömmlichen Systemen relativ festgelegt und unverändert bleibt. Mit anderen Worten, eine E/A-Anforderung eines bestimmten Typs wird jedes Mal, wenn eine E/A-Anforderung dieses Typs empfangen wird, auf die genau gleiche Weise verarbeitet. Die E/A-Anforderung wird zuerst an einen Treiber übergeben, der eine teilweise Verarbeitung durchführen kann und die E/A-Anforderung dann an einen zweiten Treiber weiterleitet, der ebenfalls eine teilweise Verarbeitung an der E/A-Anforderung vornehmen kann. Im Allgemeinen folgt auf diese Prozedur, dass jeder Treiber die E/A-Anforderung an einen nachfolgenden Treiber übergibt, bis die E/A-Anforderung letztendlich verarbeitet ist. In Systemen des bisherigen Stands der Technik ist ein Unterbrechen der normalen Verarbeitungsfolge und Zurückgeben der Steuerung entweder zu einem vorherigen Treiber oder einem separaten Treiber zur Abwicklung spezieller Typen von E/A-Anforderungen nicht vorgesehen.
  • Unter folgender Bezugnahme auf 2 wird ein verallgemeinertes Schaubild eines Systems veranschaulicht, das die vorliegende Erfindung verkörpert. Der Client-Prozess 20 erstellt wiederum eine E/A-Anforderung, die schließlich zu den Betriebssystemdiensten 22 weitergeleitet wird, wie durch den Pfeil 24 veranschaulicht. Das E/A-System der vorliegenden Erfindung umfasst eine Vielzahl von Treibereinrichtungen zum Verarbeiten solcher E/A-Anforderungen. Beispielhaft und nicht einschränkend werden in 2 sol che Treibereinrichtungen durch den Treiber 42 der Schicht 1, den Treiber 44 der Schicht 44 und den Treiber 46 der Schicht N veranschaulicht.
  • Weil E/A-Anforderungen von einer Treibereinrichtung zu einer anderen Treibereinrichtung übergeben werden, können Ausführungsformen innerhalb des Umfangs der vorliegenden Erfindung Einrichtungen zum Übergeben einer E/A-Anforderungen von einem Treiber zu einem anderen umfassen. Zum Beispiel werden solche Einrichtungen in 2 durch die Pfeile 48 und 50 veranschaulicht, die zeigen, dass E/A-Anforderungen direkt von einem Treiber an einen anderen übergeben werden. Solche Einrichtungen können auch einen E/A-Manager umfassen, wie beispielsweise denjenigen, der in 12 veranschaulicht ist, der die Übergabe von E/A-Anforderungen von einem Treiber zu einem anderen abwickelt.
  • In 2 leitet der E/A-Manager 40 die vom Client-Prozess 20 empfangene E/A-Anforderung an den Treiber 42 der Schicht 1 weiter. Eine solche E/A-Anforderung kann in der Form einer Funktion oder eines Dienstes vorliegen, die bzw. der von dem E/A-Manager oder irgendeinem anderen Mechanismus aufgerufen wird, der die entsprechenden Informationen zu dem entsprechenden Treiber überträgt. Zum Beispiel wird in Windows NT® von Microsoft ein nachrichtengesteuerter Mechanismus verwendet, um zwischen den verschiedenen Treibern des E/A-Systems zu kommunizieren. In diesem System führt eine E/A-Anforderung in dem E/A-Manager zum Erstellen eines E/A-Anforderungspakets (IRP) und Senden des IRP zu dem entsprechenden Treiber. Wenn die E/A-Anforderungen verarbeitet und zu anderen Treibern weitergeleitet werden, können Informationen zu dem IRP hinzugefügt und das IRP an den nächsten Treiber übergeben werden. Unter gewissen Umständen kann das IRP modifiziert oder "transmogrifiziert" werden, bevor es an den nächsten Treiber übergeben wird. Unter Windows NT® von Microsoft ist der E/A-Manager für das Übertragen von IRPs zwischen Treibern verantwortlich. In anderen Systemen können anderen Mechanismen verwendet werden. Solche Implementierungsdetails werden als Wahlmöglichkeiten für die Auslegung und als nicht kritisch für die Erfindung betrachtet.
  • Unter erneuter Bezugnahme auf 2 wird die E/A-Anforderung, nachdem der Treiber 42 der Schicht 1 jede erforderliche Verarbeitung durchgeführt hat, an den Treiber 44 der Schicht 2 übergeben, der jede erforderliche Verarbeitung durchführt und die E/A-Anfor derung anschließend an den nächsten Treiber weiterleitet. Es ist anzumerken, dass, obwohl 2 alle Treiber so darstellt, dass sie die E/A-Anforderung einer nach dem anderen empfangen, es in einigen Ausführungsformen wünschenswert sein kann, gewisse Treiber zu überspringen, so dass nur diejenigen Treiber, die die E/A-Anforderung tatsächlich verarbeiten müssen, die E/A-Anforderung abwickeln.
  • Weil die vorliegende Erfindung ein System und ein Verfahren zum Unterbrechen der normalen Verarbeitungsfolge und zum Übertragen der Steuerung auf einen anderen Treiber bereitstellt, können Ausführungsformen in der vorliegenden Erfindung Einrichtungen zum Unterbrechen der Verarbeitung einer E/A-Anforderung enthalten. In 2 kann eine solche Einrichtung zum Beispiel in den Treiber 46 der Schicht N integriert sein. In der vorliegenden Erfindung wird die normale Verarbeitungsfolge unterbrochen, wenn ein spezieller Typ von Datei oder Verzeichnis während der Verarbeitung einer E/A-Anforderung angetroffen wird. Eine solche spezielle Datei bzw. ein solches Verzeichnis wird als "Reparse-Punkt" bezeichnet. Wie im Folgenden ausführlicher erläutert, wird ein Reparse-Punkt erstellt, indem ein spezielles Reparse-Punkt-Attribut in eine Datei oder ein Verzeichnis aufgenommen wird. Ein solches spezielles Reparse-Punkt-Attribut kann von einem Treiber erkannt werden, wenn er seine E/A-Anforderung durchführt. Wenn das Attribut erkannt wird, wird die normale Verarbeitungsfolge der E/A-Anforderung ausgesetzt, und es werden Schritte unternommen, um die Verarbeitung der E/A-Anforderung abzuarbeiten. Die Schritte umfassen die Übertragung der Steuerung zum Verarbeiten der E/A-Anforderung an einen anderen Treiber, um es dem Treiber zu ermöglichen, sich an der Verarbeitung der E/A-Anforderung für den speziellen Typ von Datei oder Verzeichnis zu beteiligen. Ausführungsformen innerhalb des Umfangs der vorliegenden Erfindung können somit Einrichtungen zum Übertragen der Steuerung zum Verarbeiten einer E/A-Anforderung von einem Treiber zu einem anderen umfassen. Jeder Mechanismus, der die Steuerung von einem Treiber, der die E/A-Anforderung verarbeitet, zu einem anderen Treiber überträgt, wenn die Verarbeitung der E/A-Anforderung vorzeitig unterbrochen wird, kann verwendet werden. In 2 wird ein solcher Mechanismus zum Beispiel durch den Pfeil 52 veranschaulicht, der zeigt, wie die Steuerung zum Verarbeiten der E/A-Anforderung vom Treiber 46 der Schicht N zum Treiber 42 der Schicht 1 übertragen wird, wenn während der Verarbeitung der E/A-Anforderung ein Reparse-Punkt angetroffen wird. Wie im Folgenden ausführlicher erläutert wird, kann für den Mechanismus zum Übertragen der Steuerung von einem Treiber zu einem anderen die Übertragung gewisser Informationen erforderlich sein, damit der Treiber, der die Steuerung übernimmt, den Reparse-Punkt sachgemäß verarbeiten kann. Somit können Ausführungsformen auch Einrichtungen zum Übergeben von Reparse-Punkt-Informationen und Einrichtungen zum Übergeben von Statusinformationen umfassen. Diese Mechanismen werden im Folgenden ausführlicher erörtert.
  • Sobald die Steuerung vom Treiber der Schicht N zum Treiber 42 der Schicht 1 übertragen worden ist, muss der Treiber 42 der Schicht 1 dann den Reparse-Punkt richtig verarbeiten, um die Verarbeitung der E/A-Anforderung voranzutreiben. In gewissen Situationen und Ausführungsformen kann der Treiber, der die Steuerung übernimmt, wenn ein Reparse-Punkt angetroffen wird, in der Lage sein, die E/A-Anforderung vollständig zu verarbeiten.
  • In solchen Situationen würden Ergebnisse und/oder Statusinformationen an den Client-Prozess nach Bedarf zurückgegeben werden, sobald der Treiber die E/A-Anforderung vollständig verarbeitet hat. Ein solches Ergebnis kann in 2 angegeben werden, wenn zum Beispiel der Treiber 42 der Schicht 1 die Ergebnisse der E/A-Anforderung zurückgegeben hat, wie durch den Pfeil 50 aus dem Treiber 42 der Schicht 1 angegeben wird. Andererseits kann die vollständige Verarbeitung einer E/A-Anforderung, nachdem ein Reparse-Punkt angetroffen wird, auch die Unterstützung anderer Treiber erfordern. Somit können die Ausführungsformen innerhalb des Umfangs dieser Erfindung Einrichtungen zum Erstellen einer zweiten E/A-Anforderung umfassen, um die Verarbeitung der ursprünglichen E/A-Anforderung fortzusetzen. In 2 kann eine solche Einrichtung zum Beispiel in den Treiber 42 der Schicht 1 integriert sein. Der Treiber 42 der Schicht 1 kann eine zweite E/A-Anforderung von Grund auf erstellen oder zum Beispiel die ursprüngliche E/A-Anforderung transmogrifizieren und die E/A-Anforderung zu einem anderen Treiber übertragen. Unter Windows NT® von Microsoft kann eine solche Einrichtung zum Beispiel implementiert werden, indem ein neues IRP erstellt und das IRP an den entsprechenden Treiber übergeben wird. Eine solche Einrichtung kann auch implementiert weden, indem ein bestehendes IRP transmogrifiziert und das IRP dann an den entsprechenden Treiber übergeben wird. in 2 wird eine solche Einrichtung zum Beispiel durch den Pfeil 54 veranschaulicht, der die erstellte E/A-Anforderung darstellen kann, die von dem Treiber 42 der Schicht 1 an den Treiber 44 der Schicht 2 und schließlich an den Treiber 46 der Schicht N übergeben wird. Wie im Folgenden in Verbindung mit 7 erörtert wird, kann eine vollständige Verarbeitung einer E/A-Anforderung auch die Verarbeitung durch andere Rechner erfordern. Somit können Einrichtungen zum Erstellen einer zweiten E/A-Anforderung auch E/A-Anforderungen zu anderen Rechnern übertragen.
  • Angenommen, der Treiber 42 der Schicht 1 hat den entsprechenden Reparse-Punkt verarbeitet und eine andere E/A-Anforderung erstellt, um die Verarbeitung der ursprünglichen E/A-Anforderung zu beenden, dann kann der Treiber 46 der Schicht N die zweite E/A-Anforderung empfangen und mit der Hardware 56 eine entsprechende Schnittstelle zum Abarbeiten der ursprünglichen E/A-Anforderung bilden. Die Ergebnisse können anschließend, wie durch die Pfeile 50 dargestellt, zum E/A-Manager und schließlich zum Client-Prozess 20 zurückgegeben werden, wie durch den Pfeil 58 dargestellt.
  • Kurz gesagt, die vorliegende Erfindung stellt ein System und ein Verfahren zum Unterbrechen der normalen Verarbeitungsfolge einer E/A-Anforderung bereit, um es einem Treiber, der normalerweise an der Verarbeitung der E/A-Anforderung nicht beteiligt wäre, zu ermöglichen, in die Verarbeitung der E/A-Anforderung einzugreifen. Wie im Folgenden ausführlicher erläutert wird, kann ein solcher Mechanismus für die Implementierung gewisser spezieller Typen von Dateien oder Verzeichnissen äußerst nützlich sein. Die vorliegende Erfindung verwendet den Mechanismus eines Reparse-Punkt-Attributs, das entweder mit einer Datei oder einem Verzeichnis verknüpft wird, um die normale Verarbeitungsfolge zu unterbrechen und die Steuerung zum Verarbeiten des Reparse-Punkts an einen bestimmten Treiber zu übergeben. Dieser Treiber kann die Verarbeitung der E/A-Anforderung abarbeiten oder kann eine zweite E/A-Anforderung generieren, um die Verarbeitung der E/A-Anforderung unter Verwendung anderer Treiber fertig zu stellen. Wie aus der folgenden Erörterung besser ersichtlich wird, bietet ein solcher Mechanismus eine Möglichkeit, die Fähigkeiten eines bestehenden E/A-Systems kohärent zu erweitern, um Situationen zu bewältigen, die bei der Entwicklung des E/A-Systems noch nicht vorstellbar waren. Eine solche Flexibilität stellt eine größere Fähigkeit zum Unterstützen von erweiterten Datei- und Verzeichnis-Organisationsstrukturen bereit, die sich im Lauf der Zeit entwickeln.
  • Als das UNIX-Betriebssystem entwickelt wurde, definierte es eine neue vereinfachte Sicht von Eingabe/Ausgabe. Alle Daten, die gelesen oder geschrieben werden, werden als einfacher Strom von Bytes betrachtet, die zu virtuellen Dateien gelenkt werden, die durch Dateideskriptoren dargestellt werden. Eine virtuelle Datei bezieht sich auf jede Quelle bzw. jedes Ziel einer Eingabe/Ausgabe, die so behandelt wird, als wäre sie eine Datei. Desgleichen besteht kein großer Unterschied zwischen Dateien und Verzeichnissen. Ein Verzeichnis wurde einfach als ein spezieller Typ von Datei betrachtet. Moderne Betriebssysteme wurden auf Basis dieses grundlegenden Konzepts erweitert, wobei man sich Dateien und Verzeichnisse einfach als Sammlung von "Attributen" vorstellen kann. Ein Attribut ist auf seiner abstraktesten Ebene einfach ein Datenspeicherplatz. Verschiedene Attribute werden verwendet, um verschiedene Eigenschaften einer Datei oder eines Verzeichnisses zu bestimmen oder werden verwendet, um verschiedene Informationsteile aufzunehmen, die es dem Betriebssystem und anderen Prozessen, die sich mit der Datei oder dem Verzeichnis beschäftigten müssen, gestatten, gewisse Informationen über die Datei oder das Verzeichnis zu erfahren. Zum Beispiel kann eine Datei ein Namensattribut enthalten, mit dem Prozessen gestattet wird, die Datei zu identifizieren, und ein Datenattribut, das die in der Datei gespeicherten Daten ist. Eine Datei kann eine beliebige Anzahl von anderen Attributen aufweisen, wie beispielsweise Sicherheitsattribute, die angeben, wer auf welche Weise auf die Datei zugreifen darf, ein Zeitstempel-Attribut, Attribute, die identifizieren, in welchem Verzeichnis die Datei gespeichert ist und so weiter. Verzeichnisse können ähnliche Arten von Attributen enthalten, obwohl Verzeichnisse üblicherweise kein Datenattribut enthalten, in dem ein Benutzer eine große Datenmenge speichern kann.
  • Unter folgender Bezugnahme auf 3 wird ein bildhaftes Schaubild von Attributen für entweder eine Datei oder ein Verzeichnis veranschaulicht, die für die Verwendung zusammen mit der vorliegenden Erfindung geeignet sind. Diese Attribute stellen eine modifizierte Liste von Attributen dar, die vom NTFS-Dateisystem verwendet werden, das speziell für Windows NT® von Microsoft entwickelt wurde. Das NTFS-Dateisystem wird ausführlicher beschrieben in Inside the Windows NT File System von Helen Custer, veröffentlicht von Microsoft Press und hiermit durch Verweis hierin aufgenommen. In 3 können die Attribute, die eine Datei oder ein Verzeichnis bilden, in zwei grundlegende Gruppen eingeteilt werden. Die erste grundlegende Gruppe, die allgemein mit 60 bezeichnet ist, stellt Attribute dar, die Dateien und Verzeichnissen gemeinsam sind. Die zweite grundlegende Gruppe, die allgemein mit 62 bezeichnet wird, enthält Attribute, die für eine (auf der linken Seite gezeigte) Datei oder ein (auf der rechten Seite gezeigtes) Verzeichnis spezifisch sind.
  • In der Gruppe von Attributen, die sowohl einer Datei als auch einem Verzeichnis gemeinsam sind, befindet sich das Standardinformationen-Attribut 64, die Attributliste 66, das Namensattribut 68, das Sicherheitsdeskriptor-Attribut 70 und das Reparse-Punkt-Attribut 72. Das Standardinformationen-Attribut 64 stellt die standardmäßigen "MS-DOS"-Attribute das, wie beispielsweise nur lesen, lesen/schreiben, verborgen und so weiter für eine Datei, den Zeitstempel der Datei oder des Verzeichnisses, und wie viele Verzeichnisse auf die Dateien verweisen. Die Attributliste 66 ist ein Attribut, das von NTFS verwendet wird, um die Speicherplätze von zusätzlichen Attributen zu identifizieren, die die Datei oder das Verzeichnis bilden, wenn die Datei oder das Verzeichnis mehr als einen Speicherdatensatz in der Stammdatei-Tabelle belegen. Die Stammdatei-Tabelle ist der Speicherplatz, in dem alle residenten Attribute einer Datei bzw. eines Verzeichnisses gespeichert werden. Das Namensattribut 68 ist die Bezeichnung der Datei bzw. des Verzeichnisses. Eine Datei oder ein Verzeichnis können mehrere Namensattribute in NTFS haben, zum Beispiel einen langen Namen, einen kurzen MS-DOS-Namen und so weiter. Das Sicherheitsdeskriptoren-Attribut 70 enthält die Datenstruktur, die von Windows NT® verwendet wird, um anzugeben, wer Eigentümer der Datei oder des Verzeichnisses ist und wer darauf zugreifen kann. Diese Attribute werden ausführlicher in Inside the Windows NT File System beschrieben.
  • Das Reparse-Punkt-Attribut 72 ist ein neues Attribut, das von der vorliegenden Erfindung hinzugefügt wird. Das Reparse-Punkt-Attribut 72 identifiziert eine bestimmte Datei bzw. ein bestimmtes Verzeichnis als einen Reparse-Punkt, der eine spezielle Verarbeitung durch einen bestimmten Treiber in dem E/A-System erfordert. Der Reparse-Punkt enthält vorzugsweise ausreichende Informationen, um zu gestatten, das zwei Ziele erreicht werden. Das erste Ziel ist, dass es möglich sein muss, den bestimmten Treiber, der den Reparse-Punkt verarbeiten soll, (der Eigentümer des Reparse-Punkts), zu identifizieren. Außerdem wird hinsichtlich einer maximalen Flexibilität bevorzugt, dass der Eigentümer des Reparse-Punkts in der Lage ist, Daten mit dem Reparse-Punkt zu speichern, die später von dem Eigentümer verwendet werden können, um den Reparse-Punkt richtig zu verarbeiten. In einer Ausführungsform umfasst das Reparse-Punkt-Attribut:
    Reparse-Punkt-Flag Tag Datenlänge Daten
  • Weil ein Reparse-Punkt von einem bestimmten Treiber verarbeitet wird, umfassen Ausführungsformen innerhalb des Umfangs dieser Erfindung Einrichtungen zum Identifizieren eines bestimmten Treibers als den Treiber, der wenigstens einen Teil einer E/A-Anforderung verarbeiten soll, die den Reparse-Punkt einschließt. Jeder Mechanismus, der einen bestimmten Treiber als den Eigentümer eines Reparse-Punkts identifiziert, kann für eine solche Einrichtung verwendet werden. Wenn das Reparse-Punkt-Attribut die in der obigen Tabelle veranschaulichte Struktur aufweist, kann eine solche Einrichtung zum Beispiel den Tag-Wert umfassen. In dem oben dargestellten Reparse-Punkt ist das Tag ein Datenwort, das die Kennung des Eigentümers des Reparse-Punkts enthält. Es wird bevorzugt, dass die Tags so zugeordnet werden, dass das gleiche Tag immer mit dem gleichen Eigentümer-Treiber verknüpft wird, gleichgültig, auf welchem System der Treiber installiert ist. Mit anderen Worten, es wird bevorzugt, dass irgendein Mechanismus vorhanden ist, der einen Tag-Wert einem bestimmten Treiber zuordnet. Zum Beispiel kann ein zentraler Ablagespeicher (repository) oder eine Freischaltestelle (clearing house) vorhanden sein, die Blöcke von Tag-Werten verschiedenen Treiber-Herstellern zuordnet. Die Treiber-Hersteller können Tags dann zu spezifischen Treibern zuordnen. Jeder andere Mechanismus, der das Zuordnen eines Tag-Werts zu maximal einem einzigen Treiber gestattet, kann ebenfalls verwendet werden. Das Zuordnen von Tag-Werten auf diese Weise gestattet es dem gleichen Eigentümer-Treiber, den gleichen Reparse-Punkt zu verarbeiten, gleichgültig, auf welchem System er installiert ist. In einigen Situationen ist es alternativ möglich, lokale Tag-Werte dynamisch so zuzuordnen, dass Tag-Werte während der Installation durch das System zugeordnet werden. Bei einem solchen Verfahren gibt es jedoch mehrere Probleme, und aus diesem Grund wird es im Allgemeinen nicht bevorzugt.
  • In dem Reparse-Punkt-Attribut, das in der obigen Tabelle veranschaulicht ist, wird ein optionales Reparse-Punkt-Flag dargestellt. Das Reparse-Punkt-Flag wird oben dargestellt, um anzugeben, dass ein Mechanismus vorhanden sein muss, um die Identifizierung von Dateien oder Verzeichnissen zu gestatten, die Reparse-Punkte sind. Eine solche Angabe kann zum Beispiel unter Verwendung eines Reparse-Punkt-Flags erfolgen, das ein gültiges Reparse-Punkt-Attribut angibt. Alternativ können auch andere Mechanismen verwendet werden. Zum Beispiel können ein oder mehrere Tag-Werte reserviert werden, um anzugeben, dass eine Datei oder ein Verzeichnis kein Reparse-Punkt ist. Unter Verwendung eines solchen Mechanismus wäre es zum Beispiel möglich, das Tag 0 für die Angabe zu reservieren, dass es sich bei einer Datei oder einem Verzeichnis um keinen Reparse-Punkt gehandelt hat.
  • Das oben veranschaulichte Reparse-Punkt-Attribut enthält auch ein vom Eigentümer gesteuertes Datenfeld. Das eigentümergesteuerte Datenfeld stellt einen Speicherplatz dar, an den der Eigentümer des Reparse-Punkts jeden Datentyp stellen kann, der benötigt wird, um den Reparse-Punkt richtig zu verarbeiten. Wenn der Eigentümer zum Beispiel mit einer entfernten Speicherung von verschiedenen Attributen einer Datei oder eines Verzeichnisses arbeitet, dann muss der Speicherplatz der entfernt gespeicherten Attribute, wenn gewisse Attribute entfernt gespeichert werden, in dem Datenfeld des Reparse-Punkt-Attributs gespeichert werden.
  • In dem oben veranschaulichten Reparse-Punkt-Attribut geht dem Datenfeld ein Datenlängen-Indikator voraus. In diesem Speicherformat wird die Länge des Datenfelds gespeichert, um festzulegen, wie viele Daten gelesen werden müssen, um das Datenfeld abzuarbeiten. In einigen Ausführungsformen kann es alternativ effizienter sein, ein Datenfeld mit einer festen Länge zu speichern oder ein Datenfeld, das Informationsblöcke verwendet, die durch Adressenverweise oder Verknüpfungen miteinander verkettet sind. Im Wesentlichen kann jeder Mechanismus verwendet werden, der identifiziert, wie viele Daten gelesen werden müssen, um das Datenfeld abzuarbeiten. Außerdem sollte auch berücksichtigt werden, wie viele Daten von einem Eigentümer-Treiber gespeichert werden müssen. Solche Überlegungen beeinflussen die Art der Speicherung des Datenfelds und die maximal mögliche Länge des Datenfelds.
  • Unter erneuter Bezugnahme auf 3 wird im Folgenden die Gruppe 62 betrachtet, die die Unterschiede zwischen Attributen, die von einer Datei verwendet werden, und Attributen, die von einem Verzeichnis verwendet werden, veranschaulicht. Eine Datei weist üblicherweise eines oder mehrere Datenattribute auf, die in 3 durch das Datenattribut 74 veranschaulicht werden. Das Datenattribut 74 stellt einen Speicherplatz dar, an dem benutzergesteuerte Daten gespeichert werden können. Dies ist das Attribut, in dem ein Benutzer oder ein Benutzerprozess Daten speichert. Obwohl ein Benutzerprozess auf andere Attribute Zugriff haben und in diesen Daten speichern kann, werden diese Attribute allgemein nicht nur vom Benutzerprogramm, sondern auch von anderen Systemressourcen verstanden, wie beispielsweise einem Treiber. Ein Treiber versteht im Allgemeinen jedoch nicht die in dem Datenattribut gespeicherten Daten oder arbeitet mit diesen. Einige Dateisysteme, wie beispielsweise das NTFS-System, können mehr als ein Datenattribut haben.
  • Zusätzlich zum Datenattribut 74 kann eine Datei andere Attribute haben, wie durch sonstige Attribute 76 angegeben wird. Solche Attribute stellen irgendwelche anderen Attribute dar, die mit der Datei gespeichert werden. Einige Systeme können benutzerdefinierte Attribute gestatten, in welchem Fall die sonstigen Attribute 76 jede Anzahl bzw. jeden Typ von Attributen darstellen können, die von einem Benutzer definiert und gespeichert werden.
  • Attribute, die von einem Verzeichnis verwendet werden, können zum Beispiel das Indexstamm-Attribut 78, das Indexzuweisungs-Attribut 80 und das Bitmap-Attribut 82 enthalten. Obwohl weitere Informationen in Bezug auf diese Attribute in der Referenz Inside the Windows NT File System zu finden sind, die vorher hierin unter Verweis darauf aufgenommen wurde, enthält das Indexstamm-Attribut 78 im Wesentlichen Indices für die Dateien, die in dem Verzeichnis enthalten sind, das Indexzuweisungs-Attribut 80 enthält Informationen in Bezug auf Datenblock- oder "Cluster"-Abbildungen, und das Bitmap-Attribut 82 verfolgt, welche Cluster verwendet werden und welche frei sind. Andere Attribute können ebenfalls definiert und als Teil eines Verzeichnisses gespeichert werden, wie von den sonstigen Attributen 84 angegeben.
  • Obwohl die obige Erörterung im Hinblick auf einen bestimmten Typ von Datei oder Verzeichnis etwas ausführlicher dargelegt wurde, sollte dies nur als beispielhaft und nicht begrenzend für den Umfang dieser Erfindung interpretiert werden. Die vorliegende Erfindung funktioniert mit jedem Typ von Datei oder Verzeichnis, zu denen ein Reparse-Punkt-Attribut zu den bestehenden Attributen der Datei oder des Verzeichnisses hinzugefügt worden ist. Als Alternative besteht auch die Möglichkeit, eine bestehendes Attribut hinzuzuwählen oder zu verwenden, um die Reparse-Punkt-Attributinformationen zu speichern und somit in entsprechender Weise eine Möglichkeit bereitzustellen, ein Re parse-Punkt-Attribut ohne Erhöhen der bestehenden Anzahl von Attributen in der Datei oder dem Verzeichnis aufzunehmen.
  • Unter folgender Bezugnahme auf 4 wird ein ausführlicheres Schaubild eines E/A-Systems dargestellt, das eine Vielzahl von Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen umfasst. Das in 4 veranschaulichte E/A-System kann ein E/A-System wie dasjenige sein, das von Windows NT® von Microsoft verwendet wird. Andere Betriebssysteme, die eine Vielzahl von Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen verwenden, können ebenfalls ähnliche Strukturen aufweisen. Die in Verbindung mit 4 erörterten Konzepte können unter Verwendung jedes E/A-Systems implementiert werden, das eine Vielzahl von Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen umfasst. Die Verwendung der in 4 veranschaulichten Strukturen ist als nur eine mögliche Implementierung zu betrachten und soll den Umfang der vorliegenden Erfindung nicht begrenzen.
  • Die in 4 veranschaulichte Ausführungsform umfasst eine Vielzahl von Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen. In 4 sind solche Treibereinrichtungen zum Beispiel durch den Treiber A, der allgemein mit 86 gezeigt wird, und den Treiber B, der allgemein mit 88 gezeigt wird, veranschaulicht. Ausführungsformen innerhalb des Umfangs dieser Erfindung umfassen auch Einrichtungen zum Übergeben einer E/A-Verarbeitungsanforderung von einem Treiber an einen anderen. Beispielhaft und nicht begrenzend werden solche Einrichtungen in 4 durch den E/A-Manager 90 veranschaulicht. Der E/A-Manager 90 ist zum Beispiel repräsentativ für einen Manager, der für die Übertragung von E/A-Anforderungen von der Vielzahl von Treibern zuständig ist, die von einem E/A-System verwendet werden. Wie vorher erörtert wurde, ist es möglich, dass einige Ausführungsformen keinen E/A-Manager verwenden und sich auf eine direkte Kommunikation zwischen den verschiedenen Treibern stützen. In solchen Ausführungsformen wäre die Einrichtung zum Übergeben einer E/A-Verarbeitungsanforderung von einem Treiber an einen anderen der Mechanismus, der von einem Treiber für die direkte Übergabe von E/A-Anforderungen an den anderen Treiber verwendet wird.
  • Wie in 4 veranschaulicht, stellen der Treiber A 86 und der Treiber B 88 eine Gruppe von Diensten oder Routinen bereit, auf die vom E/A-Manager 90 zum Ausführen verschiedener Funktionen zugegriffen werden kann. Die in 4 veranschaulichten Rou tinen stellen einen Teil der möglichen Routinen dar, die ein Treiber, der unter Windows NT® von Microsoft läuft, aufweisen kann. Details in Bezug auf die verschiedenen Routinen sind im Kapitel 8 von Inside Windows NT von Helen Custer zu finden, das von Microsoft Press veröffentlicht wurde und dessen Gesamtheit hierein durch Verweis aufgenommen wird.
  • Gewisse Routinen führen eine ähnliche Funktion für den Treiber A 86 und den Treiber B 88 durch. Obwohl die exakten Details der Routinen sich sehr unterscheiden können, ist das Gesamtziel der Routinen das Gleiche. Routinen, die eine ähnliche Funktion sowohl für den Treiber A 86 und den Treiber B 88 durchführen, umfassen: Initialisierungsroutine 92; E/A-Startroutine 94; Unterbrechungsdienstroutine 96; Aufrufroutine für verzögerte Prozeduren 98; Routine für E/A-Löschroutine 100; und Entlastungsroutine 102 (unload routine). Obwohl diese Routinen für den Betrieb eines Treibers unter einem Betriebssystem wie Windows NT® von Microsoft wichtig sind, sind sie im Allgemeinen nicht für die Zwecke dieser Erfindung wichtig. Die Funktion dieser Routinen wird im Folgenden jedoch kurz zusammengefasst.
  • Sowohl der Treiber A 86 als auch der Treiber B 88 weisen eine Initialisierungsroutine 92 auf. Obwohl die Initialisierungsroutinen für jeden Treiber unterschiedlich sein können, wird die Initialisierungsroutine von dem E/A-Manager ausgeführt, wenn der E/A-Manager den Treiber in das Betriebssystem lädt. Diese Routine führt jedwede Initialisierung durch, die notwendig ist, um es dem E/A-Manager zu gestatten, den Treiber zu verwenden und auf ihn zuzugreifen. Die E/A-Startroutine 94 wird verwendet, um eine Datenübertragung zu oder von einer Vorrichtung zu initiieren. Die Unterbrechungsdienstroutine 96 wird aufgerufen, wenn eine Vorrichtung eine Unterbrechung für einen bestimmten Treiber sendet. Unter Windows NT® wird die Verarbeitung einer Unterbrechungsdienstroutine auf ein absolutes Mindestmaß beschränkt, um zu vermeiden, dass Unterbrechungen auf niedrigeren Ebenen unnötig blockiert werden. Die Aufrufroutine für verzögerte Prozeduren 98 führt den größten Teil der Verarbeitung durch, die mit der Abwicklung einer Vorrichtungsunterbrechung verbunden ist, wenn die Unterbrechungsdienstroutine ausgeführt wird. Die E/A-Löschroutine 100 wird aufgerufen, wenn eine E/A-Operation gelöscht werden soll. Die Entlastungsroutine 101 gibt Systemressourcen frei, so dass der E/A-Manager den Treiber aus dem Speicher entfernen kann.
  • Treiber unter Windows NT® von Microsoft umfassen eine Gruppe von Abwicklungsroutinen 104 des Treibers A 86 und Abwicklungsroutinen 104 des Treibers B 88. Abwicklungsroutinen sind die Hauptfunktionen, die ein Vorrichtungstreiber bereitstellt. Einige Beispiele sind Lese- oder Schreib-Funktionen und alle anderen Fähigkeiten der Vorrichtung, des Dateisystems oder Netzwerks, die der Treiber unterstützt. Wenn eine E/A-Operation von einem Treiber verarbeitet wird, kann der E/A-Manager 90 ein E/A-Anforderungspaket (IRP) generieren und einen Treiber über eine der Abwicklungsroutinen des Treibers aufrufen. Damit kann eine E/A-Anforderung in 4 durch IRPs dargestellt werden, die zwischen Treibern oder zwischen dem E/A-Manager und einem Treiber übergeben werden.
  • Wenn mehrere Treiber verwendet werden, kann ein Treiber eine teilweise Verarbeitung einer E/A-Anforderung durchführen, bevor die E/A-Anforderung an einen nachfolgenden Treiber übergeben wird. Ein solcher Prozess wird in 4 durch das IRP 108 veranschaulicht, das an den Treiber A 86 übergeben, teilweise vom Treiber A verarbeitet, wie durch den IRP-Verarbeitungsblock 110 angegeben, und über das IRP 112 an den Treiber B 88 übergeben wird. Es ist anzumerken, dass es sich beim IRP 108 und IRP 112 um das gleiche IRP handeln kann. Zur Verdeutlichung der Identifizierung, wie IRPs zwischen den Treibern fließen können, sind sie in 4 jedoch getrennt nummeriert. Auch ist eine Ausführungsform möglich, die ein neues IRP erstellt, so dass IRP 108 und IRP 112 verschieden sind.
  • Wenn eine E/A-Anforderung keine Verarbeitung einer Datei oder eines Verzeichnisses mit einem damit verknüpften Reparse-Punkt-Attribut umfasst, verarbeitet ein Treiber die E/A-Anforderung auf übliche Weise und gibt die mit der E/A-Anforderung verknüpften Informationen auf übliche Weise zurück. Wenn zum Beispiel das IRP 112 vom Treiber B 88 empfangen wird, kann es auf übliche Weise vom IRP-Verarbeitungsblock 116 verarbeitet werden. Während der Verarbeitung einer E/A-Anforderung kann der Treiber B 88 Statusinformationen und/oder ein IRP an vorherige Treiber zurückgeben. Dies wird in 4 durch das IRP 118 und den Status 120 veranschaulicht. Obwohl in 4 nicht veranschaulicht, können IRP 118 und/oder Status 120 nach der Verarbeitung durch den Treiber B 88 an den Treiber A 86 zurück übergeben werden. Dies alles ist Teil der normalen E/A-Verarbeitung und wird ausführlicher in Inside Windows NT erläutert, das vorher durch Verweise hierin aufgenommen wurde.
  • Wenn IRPs von Treibern empfangen werden, kann die E/A-Anforderung, die durch das IRP dargestellt wird, eine Datei oder ein Verzeichnis umfassen, die ein damit verknüpftes Reparse-Punkt-Attribut aufweisen. Wenn, wie vorher in Verbindung mit 2 erläutert, eine E/A-Anforderung, die eine Datei oder ein Verzeichnis mit einem damit verknüpften Reparse-Punkt-Attribut umfasst, angetroffen wird, wird die normale Verarbeitung der E/A-Anforderung unterbrochen, und die Steuerung wird auf einen anderen Treiber übertragen. Um diesen Prozess auszuführen, umfassen Ausführungsformen innerhalb des Umfangs dieser Erfindung eine Einrichtung zum Unterbrechen der Verarbeitung einer E/A-Anforderung. Eine solche Einrichtung kann jeder Mechanismus sein, mit dem ein Treiber eine E/A-Anforderung mit einer Datei oder einem Verzeichnis mit einem damit verknüpften Reparse-Punkt erkennt und die Verarbeitung der E/A-Anforderung vorzeitig beendet, so dass die Steuerung auf einen anderen Treiber übertragen werden kann. In 4 wird eine solche Einrichtung zum Beispiel durch den Reparse-Punkt-Erfassungsblock 114 veranschaulicht.
  • Wenn der Reparse-Punkt-Erfassungsblock 114 festlegt, dass die E/A-Anforderung eine Datei oder ein Verzeichnis mit einem damit verknüpften Reparse-Punkt-Attribut umfasst, wird die normale Verarbeitung der E/A-Anforderung beendet, und es werden Schritte eingeleitet, um die Zuständigkeit für die Verarbeitung der E/A-Anforderung auf den Eigentümer des Reparse-Punkts zu übertragen. In 4 werden diese Schritte vom Reparse-Punkt-Verarbeitungsblock 122 durchgeführt.
  • Der Reparse-Punkt-Verarbeitungsblock 122 führt jede Vorab-Verarbeitung durch, die notwendig ist, um die Steuerung von dem gegenwärtigen Treiber auf den Eigentümer des Reparse-Punkts zu übertragen, so dass der Eigentümer des Reparse-Punkts damit fortfahren kann, die E/A-Anforderung zu verarbeiten. Wenn zum Beispiel das Reparse-Punkt-Attribut ein Tag und ein Datenfeld enthält, wie vorher erörtert, dann kann der Reparse-Punkt-Verarbeitungsblock 122 das Tag und das Datenfeld aus dem Reparse-Punkt-Attribut extrahieren und sie für die Übertragung zum Eigentümer des Reparse-Punkts aufbereiten. Daher können Ausführungsformen innerhalb des Umfangs dieser Erfindung Einrichtungen zum Übergeben der Reparse-Punkt-Informationen an einen Treiber umfassen. Beispielhaft und nicht einschränkend sind in 4 solche Einrichtungen durch Reparse-Daten 124 dargestellt. Die Reparse-Daten 124 stellen einfach die Reparse-Informationen dar, die durch den Reparse-Punkt-Verarbeitungsblock 122 extrahiert wurden. In einigen Ausführungsformen besteht ebenfalls die Möglichkeit, das Reparse-Punkt-Attribut zu extrahieren und direkt an den Eigentümer des Reparse-Punkts zu übergeben. Im Wesentlichen kann jeder Mechanismus, der es dem Eigentümer des Reparse-Punkts gestattet, auf die in dem Reparse-Punkt-Attribut gespeicherten Informationen zuzugreifen, als eine Einrichtung zum Übergeben von Reparse-Punkt-Informationen an einen Treiber verwendet werden. Dies schließt die Übergabe eines Adressenverweises auf einen Speicherplatz, an dem die Reparse-Punkt-Informationen gespeichert sind, oder auf das Reparse-Punkt-Attribut selbst ein. In einer Ausführungsform sind Reparse-Daten 124 in einem IRP enthalten und werden an einen anderen Treiber übergeben.
  • Wenn, wie im Folgenden ausführlicher beschrieben wird, ein Treiber Reparse-Punkt-Informationen prüft, ist es wünschenswert, dass der Treiber schnell feststellen kann, dass ein Reparse-Punkt angetroffen worden ist. Es kann daher wünschenswert sein, Statusinformationen zu übergeben, die angeben, dass ein Reparse-Punkt angetroffen worden ist. Ausführungsformen können daher Einrichtungen zum Übergeben von Statusinformationen von einem Treiber zum anderen umfassen. In 4 wird eine solche Einrichtung zum Beispiel durch den Status 126 veranschaulicht. Es ist anzumerken, dass der Status 126 separat übergeben werden kann oder mit den Reparse-Daten 124 in einem IRP zusammengestellt und als eine Einheit übergeben werden kann. Desgleichen können die Statusinformationen in dem IRP und eine Verweisadresse oder Verknüpfung zu den Reparse-Daten 124 in dem IRP platziert werden. Als weiteres Beispiel kann der Status 126 übergeben werden, und die Reparse-Daten 124 können mit einer Zeitverzögerung dazwischen in ein anderes IRP übergeben werden.
  • Wenn eine E/A-Anforderung mit einer Datei oder einem Verzeichnis mit einem damit verknüpften Reparse-Punkt identifiziert wird, wird die Zuständigkeit für die Verarbeitung der E/A-Anforderung von einem Treiber auf einen anderen übertragen. Ausführungsformen innerhalb des Umfangs dieser Erfindung umfassen daher eine Einrichtung zum Übertragen der Steuerung zum Verarbeiten einer E/A-Anforderung von einem Treiber zum anderen. In der in 4 veranschaulichten Ausführungsform kann eine solche Einrichtung zum Beispiel die Abarbeitungsroutine 128 umfassen. Treiber, die für das Windows NT®-Betriebssystem geschrieben sind, können eine oder mehrere Abarbei tungsroutinen umfassen, die vom E/A-Manager aufgerufen werden, nachdem ein Treiber einer niedrigeren Ebene die Verarbeitung eines IRP beendet hat. Zum Beispiel kann der E/A-Manager in einer Ausführungsform mit einem Dateisystemtreiber und einem Vorrichtungstreiber eine Dateisystemtreiber-Abarbeitungsroutine aufrufen, nachdem der Vorrichtungstreiber die Übertragung von Daten zu oder von einer Datei beendet hat. Die Abarbeitungsroutine kann den Dateisystemtreiber über Erfolg, Fehlschlagen oder Annullierung der Operation benachrichtigen und dem Dateisystem gestatten, Bereinigungsoperationen durchzuführen. Somit kann der E/A-Manager 90 während der normalen Verarbeitung, wenn der Treiber B 88 das IRP 112 empfängt, vollständig verarbeitet und das IRP 118 zurückgibt, eine Abarbeitungsroutine im Block 128 aufrufen, die den Treiber A 86 über den Erfolg oder das Fehlschlagen der E/A-Operation benachrichtigt und dem Treiber A 86 gestattet, eine Bereinigungsverarbeitung durchzuführen.
  • Weil der E/A-Manager 90 eine Abarbeitungsroutine aufruft, wenn ein Treiber einer niedrigeren Ebene seine Verarbeitung abgearbeitet hat, stellt eine solche Abarbeitungsroutine einen idealen Speicherplatz dar, um dort einen Mechanismus zu platzieren, der die Übertragung der Steuerung zum Verarbeiten einer E/A-Anforderung mit einer Datei oder einem Verzeichnis mit einem damit verknüpften Reparse-Punkt-Attribut erfasst. Somit kann die Abarbeitungsroutine 128 die Reparse-Daten 124 und/oder den Status 126 prüfen, um festzustellen, ob der Treiber A 86 der Eigentümer des Reparse-Punkts ist und die Verarbeitungszuständigkeiten für die E/A-Anforderung übernehmen sollte.
  • Bevor ein Treiber jedoch die Zuständigkeit für die Verarbeitung einer E/A-Anforderung mit einer Datei oder einem Verzeichnis mit einem damit verknüpften Reparse-Punkt-Attribut übernimmt, muss der Treiber sicherstellen, ob er der Eigentümer des Reparse-Punkts ist. Somit können Ausführungsformen innerhalb des Umfangs dieser Erfindung eine Einrichtung zum Identifizieren umfassen, ob die Reparse-Punkt-Informationen, die von einem bestimmten Treiber empfangen werden, Eigentum dieses Treibers sind. Beispielhaft und nicht einschränkend wird in 4 eine solche Einrichtung durch den Reparse-Punkt-Erfassungsblock 130 veranschaulicht. Der Reparse-Punkt-Erfassungsblock 130 prüft die Reparse-Daten 124 und/oder den Status 126, um zu identifizieren, ob der Treiber A 86 der Eigentümer des Reparse-Punkts ist. Wenn der Treiber A 86 nicht der Eigentümer des Reparse-Punkts ist, kann ein Treiber A 86 jede normale Verarbeitung zur Abarbeitung durchführen, die notwendig ist, wie durch den Abarbeitungs-Verarbei tungsblock 132 angegeben, und die Reparse-Daten 124 und/oder den Status 126 dem E/A-Manager 90 zum Übertragen an einen anderen Treiber übergeben.
  • Wenn andererseits der Reparse-Punkt-Erfassungsblock 130 den Treiber A 86 als den Eigentümer des Reparse-Punkts identifiziert, geht die Steuerung zur weiteren Verarbeitung der E/A-Anforderung auf den Reparse-Punkt-Verarbeitungsblock 134 über. Was über die Übernahme der Steuerung zum Verarbeiten der E/A-Anforderung hinaus geschieht, wenn sich ein Treiber als der Eigentümer eines Reparse-Punkts identifiziert, wird von der Erfindung nicht erklärt. Im Allgemeinen übernimmt der Treiber die Zuständigkeit für die Verarbeitung der E/A-Anforderung und leitet Schritte zum weiteren Abarbeiten der E/A-Anforderung ein. In einigen Ausführungsformen kann ein Treiber, der der Eigentümer eines Reparse-Punkts ist, in der Lage sein, die Verarbeitung der E/A-Anforderung vollständig zu beenden. Nachdem in einer solchen Ausführungsform der Treiber die Verarbeitung der E/A-Anforderung beendet hat, folgt die normale Abarbeitungsprozedur. Im Fall von Windows NT® von Microsoft umfasst dies die Übergabe aller notwendigen Informationen in einem IRP zur weiteren Übergabe zurück an den E/A-Manager. Außerdem kann es das Aufrufen der Abarbeitungsroutine von irgendwelchen Treibern höherer Ebene umfassen, um ihnen zu gestatten, jede notwendige Bereinigungsverarbeitung durchzuführen, oder um sie über den Status der E/A-Anforderung zu informieren.
  • In einigen Ausführungsformen ist der Treiber, der der Eigentümer des Reparse-Punkts ist, möglicherweise nicht in der Lage, den Rest der E/A-Anforderung selbst vollständig zu verarbeiten. In einer solchen Ausführungsform kann der Reparse-Punkt-Verarbeitungsblock 134 ein IRP generieren, das dann an andere Treiber übergeben wird, um die E/A-Anforderung weiter zu verarbeiten. Alternativ kann eine E/A-Anforderung generiert und an einen anderen Rechner zur weiteren Verarbeitung übergeben werden, wie in Verbindung mit 7 erörtert. Ausführungsformen innerhalb des Umfangs dieser Erfindung können daher eine Einrichtung zum Erstellen einer zweiten E/A-Anforderung umfassen, um die Verarbeitung der ursprünglichen E/A-Anforderung fortzusetzen. Jeder Mechanismus, der von der bestimmten Ausführungsform verwendet wird, um die Hilfe von anderen Treibern zum Abarbeiten der E/A-Anforderung in Anspruch zu nehmen, kann für eine solche Einrichtung verwendet werden. Zum Beispiel wird in 4 die Einrichtung zum Erstellen einer zweiten E/A-Anforderung durch einen Reparse-Punkt- Verarbeitungsblock 134 und ein IRP 136 veranschaulicht. Das IRP 136 kann an einen anderen Treiber übergeben werden, wie zum Beispiel den Treiber B 88 von 4. Der Treiber B 88 empfängt dann das IRP 136 und verarbeitet es als ein anderes IRP. Wenn der Reparse-Punkt-Verarbeitungsblock 134 das IRP 136 erstellt, kann es das IRP von Grund auf neu erstellen oder ein vorhandenes IRP nehmen und das IRP "transmogrifizieren". Der Transmogrifikationsprozess nimmt ein bestehendes IRP und ändert Informationen in dem IRP, um ein modifiziertes oder neues IRP zu erstellen. Die Einrichtung zum Erstellen einer zweiten E/A-Anforderung kann in verschiedenen Systemen unterschiedlich implementiert werden. Zum Beispiel kann die Einrichtung zum Erstellen einer zweiten E/A-Anforderung in einem System, in dem ein Treiber einen anderen Treiber direkt aufruft, der Mechanismus sein, durch den Informationen zusammengestellt und an einen anderen Treiber über den Direktaufruf-Mechanismus übergeben werden. Im Wesentlichen ist alles, was erforderlich ist, eine E/A-Anforderung zu erstellen oder zu modifizieren, die dann zur weiteren Verarbeitung an einen anderen Treiber übergeben wird.
  • Um den oben genannten Prozess zu veranschaulichen, wird im Folgenden Bezug auf 5 und 6 genommen, die zur Darstellung eines spezifischen Beispiels der Verarbeitung einer E/A-Anforderung mit einem Verzeichnis mit einem damit verknüpften Reparse-Punkt-Attribut verwendet werden. Unter nachfolgender Bezugnahme auf 5 wird die allgemeine Struktur eines E/A-Systems erörtert. In 5 erstellt der Client-Prozess 138 eine E/A-Anforderung an ein E/A-System, das eine Vielzahl von Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen umfasst. Der Client-Prozess 138 nimmt einen Aufruf an die Betriebssystemdienste 140 vor. Der E/A-Manager 142 empfängt die E/A-Anforderung und koordiniert die Übertragung der E/A-Anforderung zwischen den verschiedenen Treibereinrichtungen des E/A-Systems.
  • In 5 wird eine Vielzahl von Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen veranschaulicht. Die Treibereinrichtungen umfassen einen Decodierer für symbolische Verknüpfungen 144, einen verteilten Dateimanager 146, einen hierarchischen Dateisystem-Manager 148, einen Dateisystemtreiber 150 und einen Plattentreiber 152. Der Decodierer für symbolische Verknüpfungen 144 ist für die Decodierung aller symbolischen Verknüpfungen in einer E/A-Anforderung zuständig. Der verteilte Dateisystem-Manager 146 verwaltet die Dateien, die über mehrere physikalische Volumen verteilt sind, als ob sie ein einzelnes integriertes Volumen wären. Der hierarchische Dateisys tem-Manager 148 entfernt Dateien, auf die selten zugegriffen wird, und speichert sie auf einem entfernten Speicherplatz, wie beispielsweise auf einem Band. Der hierarchische Dateisystem-Manager 148 ist auch für das Abrufen von entfernt gespeicherten Dateien zuständig, wenn diese benötigt werden. Der Dateisystemtreiber 150 ist für die Übersetzung einer Anforderung eines Zugriffs auf eine Datei oder ein Verzeichnis für einen physikalischen Speicherplatz auf einer Platte zuständig. Der Plattentreiber 152 ist für das Abrufen von Informationen von oder das Platzieren von Informationen auf einer Platte 154 zuständig. Das E/A-System in 5 verwendet somit eine Vielzahl von Treibern, von denen jeder für eine spezifische Funktion oder Gruppe von Funktionen zuständig ist, um eine robuste E/A-Umgebung bereitzustellen.
  • Unter folgender Bezugnahme auf 6 wird die logische Struktur von zwei verschiedenen Plattenvolumen veranschaulicht. Volumen 1 weist ein Stammverzeichnis mit der Bezeichnung C auf, das in 6 unter 156 veranschaulicht ist. Das Verzeichnis C enthält eine mit A bezeichnete Datei mit dem Bezugszeichen 158 und ein mit B bezeichnetes Verzeichnis mit dem Bezugszeichen 160. Wie in 6 veranschaulicht, ist die Datei A 158 ein Reparse-Punkt mit einem Tag von 5 und einigen Datenwerten. Das Verzeichnis B 160 enthält eine Datei mit der Bezeichnung E 162 und ein Verzeichnis mit der Bezeichnung D 164. Wie in 6 veranschaulicht, weist das Verzeichnis D 164 einen damit verknüpften Reparse-Punkt mit einem Tag von DFSM und einem Wert W auf. Das Tag von DFSM gibt an, dass der Reparse-Punkt Eigentum des verteilten Dateisystem-Managers 146 ist. Wie in dem folgenden Beispiel veranschaulicht wird, werden dieses Tag und der Wert verwendet, um einen Einhängepunkt zu erstellen, der das Volumen 2 am Verzeichnis D aufpfropft. Dieser Einhängepunkt wird in 6 durch den Pfeil 166 veranschaulicht. Volumen 2 weist ein Stammverzeichnis mit der Bezeichnung W 186 auf. Das Verzeichnis W 168 enthält das Verzeichnis X 170 und das Verzeichnis Y 172. Das Verzeichnis Y enthält die Datei Z 174.
  • Unter erneuter Bezugnahme auf 5 wird angenommen, dass der Client-Prozess 138 eine E/A-Anforderung mit dem Pfadnamen C\B\D\Y\Z erstellt hat. Eine solche E/A-Anforderung kann das Auslesen von Daten aus der oder Schreiben von Daten in die Datei Z 174 umfassen. Der Pfadname würde vom Client-Prozess 138 verwendet werden, um auf die Datei Z 174 zuzugreifen. Der Client-Prozess 138 sendet diese E/A-Anforderung durch Aufrufen von Diensten 140, wie durch den Pfeil 176 angegeben. Der E/A- Manager 142 erstellt das IRP 178 und übergibt das IRP 178 an den Decodierer für symbolische Verknüpfungen 144. Wie in 4 ist der E/A-Manager ein Beispiel für die Einrichtung zum Übergeben einer E/A-Anforderung von einem Treiber an einen anderen.
  • Um die E/A-Anforderung zu erfüllen, die vom Client-Prozess 138 initiiert wird, ist es notwendig, den Datei-Pfadnamen C\B\D\Y\Z aufzulösen. Im Allgemeinen ist die Namensauflösung ein mehrstufiger Prozess, in dem der Name in seine Bestandteile aufgegliedert und jede Komponente üblicherweise von links nach rechts aufgelöst wird, wobei Erfolg oder Fehlschlagen auf jeder Stufe in dem Auflösungsprozess bestimmt werden. Wenn das IRP 178 an den Decodierer für symbolische Verknüpfungen 144 übergeben wird, weist es den Pfadnamen auf, der als Teil des IRP aufgelöst werden muss. Abhängig von der genauen Implementierung des Decodierers für symbolische Verknüpfungen 144 kann der Decodierer für symbolische Verknüpfungen 144 den Pfadnamen im IRP 178 abtasten, um sicherzustellen, ob irgendeine der Bestandteilkomponenten des Pfadnamens eine symbolische Verknüpfung ist. Weitere Implementierungen sind ebenfalls möglich, und die exakte Implementierung hängt von verschiedenen Auslegungs-Gesichtspunkten im E/A-System ab. In dem in 6 veranschaulichten Beispiel sind keine symbolischen Verknüpfungen vorhanden, und daher würde der Decodierer für symbolische Verknüpfungen 144 das IRP 178 an den verteilten Dateimanager übergeben. Wie vorher erörtert, würde in Windows NT® von Microsoft eine solche Übergabe des IRP über den E/A-Manager 142 erfolgen.
  • Das IRP 178 wird vom verteilten Dateimanager empfangen, der, wie oben erläutert, für die Verwaltung der Dateisysteme von mehreren Volumen und ihre Integration in ein einziges logischen Dateisystem zuständig ist. In diesem Beispiel wird angenommen, dass der verteilte Dateimanager 146 auf dieser Stufe des Auflösungsprozesses nicht viel Verarbeitung am IRP vornimmt. Der verteilte Dateimanager 146 kann zum Beispiel einfach die erste Komponente C als zum Volumen 1 gehörig identifizieren, wie in 6 angegeben. Das IRP 178 wird dann an den hierarchischen Dateisystem-Manager 148 übergeben. Wiederum wird angenommen, dass der hierarchische Dateisystem-Manager 148 wenig oder gar keine Verarbeitung am IRP 178 durchführt, bevor es an den Dateisystemtreiber 150 übergeben wird.
  • Der Dateisystemtreiber 150 beginnt dann mit dem Namen-Auflösungsprozess. Beginnend mit dem Verzeichnis C 156 von 6 kann der Dateisystemtreiber 150 das Verzeichnis C 156 in einen physikalischen Speicherplatz auf der Platte 154 übersetzen. Diese Informationen würden dann im IRP 178 platziert und an den Plattentreiber 152 übergeben. Der Plattentreiber 152 würde dann auf die Platte 154 zugreifen und Informationen im IRP 180 zurückgeben, die es dem Dateisystemtreiber gestatten, den Auflösungsprozess fortzusetzen. Dieser Prozess kann für jede Komponente des Pfadnamens wiederholt werden.
  • Unter folgender Bezugnahme auf 6 würde der Dateisystemtreiber 150 mit dem Verzeichnis C 156 beginnen, mit dem Verzeichnis B 160 fortfahren und dann mit dem Verzeichnis D 164 fortsetzen. Nach dem Abrufen des Verzeichnisses D 164 von der Platte würde der Dateisystemtreiber 150 erkennen, dass das Verzeichnis D ein damit verknüpftes Reparse-Punkt-Attribut aufweist. Eine Einrichtung zum Unterbrechen der Verarbeitung einer E/A-Anforderung, die in den Dateisystemtreiber 150 integriert ist, würde dann die normale Verarbeitungsfolge der E/A-Anforderung unterbrechen. Wie in 4 oben erläutert, kann der Dateisystemtreiber 150 Reparse-Daten aus dem Reparse-Punkt-Attribut des Verzeichnisses D 164 extrahieren. Angenommen, das Reparse-Punkt-Attribut weist ein Tag und einen Datenwert auf, wie vorher erläutert, so würden diese Informationen extrahiert und an den Treiber der nächsthöheren Ebene zurückgegeben werden. In 5 wird dies durch die Reparse-Daten 182 veranschaulicht. Die Reparse-Daten 182 von 5 stellen ein weiteres Beispiel der Einrichtung zum Übergeben von Reparse-Punkt-Informationen an einen Treiber dar. In diesem Fall ist das Tag eine Datenbank und der Wert ist W, wie in 6 angegeben. In diesem Beispiel identifiziert das Tag DFSM den verteilten Dateisystem-Manager 146 als den Eigentümer des Reparse-Punkts.
  • Die Reparse-Punkt-Daten 182 von 5 werden, wie veranschaulicht, zum hierarchischen Dateisystem-Manager 148 übertragen. Eine Einrichtung zum Identifizieren, ob die vom hierarchischen Dateisystem-Manager 148 empfangenen Reparse-Punkt-Informationen Eigentum dieses Treibers sind, würde dann identifizieren, ob die Reparse-Daten 182 Eigentum des hierarchischen Dateisystem-Managers 148 sind. Eine solche Einrichtung kann in der Abarbeitungsroutine des hierarchischen Dateisystem-Managers 148 implementiert sein, wie vorher in Verbindung mit 4 erörtert. In diesem Fall wäre der hierarchische Dateisystem-Manager 148 nicht der Eigentümer des Reparse-Punkts 164 von 6. Nachdem festgestellt worden ist, dass die Reparse-Daten 182 nicht Eigentum des hierarchischen Dateisystem-Managers 148 sind, würde der hierarchische Dateisystem-Manager 148 dann die Reparse-Daten 182 an den in 5 veranschaulichten Treiber der nächsthöheren Ebene weiterleiten.
  • Der verteilte Dateisystem-Manager 146 empfängt Reparse-Daten 182 und identifiziert, ob die Reparse-Daten 182 Eigentum des verteilten Dateisystem-Managers 146 sind. Dies wird über die Einrichtung zum Identifizieren, ob die vom verteilten Dateisystem-Manager 146 empfangenen Reparse-Punkt-Informationen Eigentum dieses Treibers sind, erreicht. Eine solche Einrichtung kann in einer Abarbeitungsroutine implementiert sein, wie vorher in Verbindung mit 4 beschrieben. In dem in 6 veranschaulichten Beispiel würde der verteilte Dateisystem-Manager 146 die Reparse-Daten 182 prüfen und sich selbst als Eigentümer erkennen. Solches lässt sich durch eine Einrichtung zum Identifizieren eines bestimmten Treibers als den Treiber erreichen, der wenigstens einen Teil der E/A-Anforderung verarbeiten soll. Wie vorher erläutert, ist ein Beispiel einer solchen Einrichtung das Tag der Reparse-Daten 182. Mit anderen Worten, der verteilte Dateisystem-Manager 146 kann Reparse-Daten 182 von sich aus erkennen, indem der Tag-Wert der Reparse-Daten 182 mit einem Tag-Wert abgeglichen wird, den er selbst besitzt.
  • Wenn ein Treiber Reparse-Daten erkennt, deren Eigentümer er ist, dann übernimmt der Treiber die Zuständigkeit für die weitere Verarbeitung dieser E/A-Anforderung. Zu weiteren Verarbeitung der E/A-Anforderung prüft ein Treiber üblicherweise den Datenwert des Reparse-Punkt-Attributs und verwendet die darin gespeicherten Informationen zum Verarbeiten der E/A-Anforderung. In diesem Fall speichert der verteilte Dateisystem-Manager 146 das Ziel des Einhängepunkts in dem Datenwert. Unter erneuter Bezugnahme auf 6 und Prüfung des Datenwerts des Reparse-Punkts, der mit dem Verzeichnis D 164 verknüpft ist, wird festgestellt, das der Datenwert W beträgt. Dieser bezieht sich auf das Verzeichnis W von Volumen 2. Der verteilte Dateisystem-Manager 146 kann den Datenwert prüfen und von dort aus das Verzeichnis W von Volumen 2 als das Ziel des Einhängepunkts identifizieren. Der verteilte Dateisystem-Manager 146 kann dann ein IRP erstellen, das den Auflösungsprozess beginnend mit dem Verzeichnis W von Volumen 2 fortsetzt. Zum Erstellen eines zweiten IRP, um den Namen-Auflösungspro zess beginnend mit dem Verzeichnis W von Volumen 2 fortzusetzen, kann der verteilte Dateisystem-Manager 146 eine Einrichtung zum Erstellen einer zweiten E/A-Anforderung verwenden, um die Verarbeitung der ursprünglichen E/A-Anforderung fortzusetzen. Eine solche Einrichtung kann, wie vorher in Verbindung mit 4 erläutert, implementiert werden. Um festzustellen, wie der Namen-Auflösungsprozess fortgeführt werden soll, wäre es äußerst wünschenswert für den verteilten Dateisystem-Manager 146, feststellen zu können, wie weit der Namen-Auflösungsprozess fortgeschritten war, bevor der Reparse-Punkt angetroffen wurde. Somit kann es in einigen Ausführungsformen wünschenswert sein, den ursprünglichen Pfadnamen und einen Versatz zurückzugeben, um festzustellen, wie weit der Auflösungsprozess fortgeschritten war, bevor der Reparse-Punkt angetroffen wurde. In diesem Beispiel ist der Pfadname C\B\D\Y\Z. Der Versatz würde dann auf das Verzeichnis D verweisen, da der Reparse-Punkt dort angetroffen wurde. Beim Erstellen eines weiteren IRP zum Fortsetzen des Namen-Auflösungsprozesses kann der Dateisystem-Manager 146 sich dafür entscheiden, den Teil des Namens, der vorher aufgelöst worden ist, abzulegen und den Reparse-Punkt D durch den Speicherplatz zu ersetzen, an dem der Auflösungsprozess fortgeführt werden soll, dem Verzeichnis in W 168 von 6. In einer solchen Situation würde der neue Pfadname W\Y\Z lauten. Der verteilte Dateisystem-Manager 146 kann diese Informationen dann in das IRP 184 stellen und das IRP 184 an den hierarchischen Dateisystem-Manager 148 übergeben.
  • Der hierarchische Dateisystem-Manager 148 würde das IRP 148 dann an den Dateisystemtreiber 1590 weiterleiten. Der Dateisystemtreiber 150 würde dann den Namen-Auflösungsprozess beginnend mit dem Verzeichnis W 168 von 6 fortsetzen. Der Namen-Auflösungsprozess würde dann weiter über das Verzeichnis Y 172 fortfahren, bis die Datei Z 174 erreicht wird. Dieser Prozess ist in 5 durch das IRP 184, das an den Plattentreiber 152 übergeben wird, und die Rückgabe von IRP 186 von dem Plattentreiber 152 veranschaulicht. Es ist anzumerken, dass der Namen-Auflösungsprozess mehrere Übergaben des IRP 184 und 186 zwischen dem Dateisystemtreiber 150 und dem Plattentreiber 152 erfordern kann. Es ist ebenfalls anzumerken, dass das IRP 186 das gleiche wie IRP 184 sein kann, und das IRP 178 das gleiche wie IRP 180 sein kann. Sie weisen in 5 verschiedene Bezugszeichen auf, um anzugeben, dass der Plattentreiber 152 das IRP modifizieren kann, indem die Ergebnisse der E/A-Operation darin platziert werden.
  • Sobald die gewünschte E/A-Operation, an der die Datei Z 174 von 6 beteiligt ist, ausgeführt worden ist, und die Ergebnisse im IRP zum Dateisystemtreiber 150 zurückgegeben worden sind, würde der Dateisystemtreiber 150 das IRP 186 an den hierarchischen Dateisystem-Manager zurück übergeben. Wie in 5 dargestellt, würde das IRP dann nacheinander durch den verteilten Dateisystem-Manager 146 und den Decodierer für symbolische Verknüpfungen 144 geführt werden, bis das Ergebnis letztendlich an den Client-Prozess 138 zurückgegeben wird, wie durch den Pfeil 188 angegeben.
  • Unter folgender Bezugnahme auf 7 wird ein Beispiel dargestellt, in dem eine E/A-Anforderung an ein getrenntes Computersystem zur Verarbeitung gesendet wird, wenn ein Reparse-Punkt-Attribut angetroffen wird. In der in 7 veranschaulichten Ausführungsform nimmt der Client-Prozess 190 die Ausführung auf dem lokalen Rechner 192 vor. Der lokale Rechner 192 ist mit dem entfernten Rechner über eine Netzwerkeinrichtung zum Verbinden von Rechnern verbunden. In 7 wird eine solche Netzwerkeinrichtung durch die Netzwerkkarten 196 und die Verbindung 198 veranschaulicht. Das E/A-System 200 des lokalen Rechners 192 umfasst eine Vielzahl von Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen. In 7 wird eine solche Treibereinrichtung zum Beispiel durch den Decodierer für symbolische Verknüpfungen 202, den Dateisystemtreiber 204 und den Plattentreiber 206 veranschaulicht. Das E/A-System 200 umfasst auch die Betriebssystemdienste 208 und den E/A-Manager 210. Wie in 5 nimmt der Client-Prozess 190 Aufrufe an die Betriebssystemdienste 208 vor. Der E/A-Manager 210 empfängt E/A-Anforderungen und koordiniert die Übertragung von E/A-Anforderungen zwischen den verschiedenen Treibereinrichtungen des E/A-Systems. Alternativ können die verschiedenen Treibereinrichtungen des E/A-Systems direkt miteinander kommunizieren, ohne den E/A-Manager oder eine andere Vorrichtung zum Koordinieren der Übertragung von Informationen zwischen den verschiedenen Treibereinrichtungen zu verwenden.
  • In diesem Beispiel wird angenommen, dass der Client-Prozess 190 eine E/A-Anforderung vornimmt, an der eine symbolische Verknüpfung beteiligt ist, die auf eine Datei oder ein Verzeichnis verweist, die sich auf einer Platte befinden, die an den entfernten Rechner 194 angeschlossen ist. Zum Beispiel angenommen, der Client-Prozess 190 nimmt eine E/A-Anforderung vor, um den Inhalt eines Verzeichnisses mit einer symboli schen Verknüpfung zu einem Verzeichnis aufzulisten, das sich auf einer Platte 212 befindet, die an den entfernten Rechner 194 angeschlossen ist. Eine solche E/A-Anforderung würde zum Beispiel durch den Client-Prozess 190 vorgenommen, der Betriebssystemdienste 208 aufruft, wie durch den Pfeil 214 angegeben wird. Die E/A-Anforderung würde an den Dateisystemtreiber 204 übergeben, der den Plattentreiber 206 einsetzen würde, um mit dem Namensauflösungsprozess zu beginnen. Der Plattentreiber 206 liest Informationen unter Verwendung der Plattensteuereinheit 218 aus der Platte 216 aus. Der Namen-Auflösungsprozess wird fortgesetzt, wie vorher beschrieben, bis der Reparse-Punkt, der die symbolische Verknüpfung darstellt, angetroffen wird. An diesem Punkt würden die Reparse-Punkt-Informationen extrahiert und an die anderen Treiber übergeben, bis sich einer selbst als den Eigentümer des Reparse-Punkts erkennt. In diesem Beispiel würde der Decodierer für symbolische Verknüpfungen 202 sich selbst als den Eigentümer des Reparse-Punkts erkennen, der zum Implementieren der symbolischen Verknüpfung zum entfernten Rechner 104 verwendet wird.
  • Wenn der Decodierer für symbolische Verknüpfungen 202 sich selbst als den Eigentümer des Reparse-Punkts erkennt, übernimmt der Decodierer für symbolische Verknüpfungen 202 die Zuständigkeit für die Verarbeitung der E/A-Anforderung. In diesem Beispiel kann der Decodierer für symbolische Verknüpfungen 202 die E/A-Anforderung selbst nicht vollständig verarbeiten, weil die Verarbeitung der E/A-Anforderung das Abrufen der Verzeichnisinformationen von dem entfernten Rechner 194 erfordert. In einer solchen Situation können Ausführungsformen innerhalb des Umfangs dieser Erfindung eine Einrichtung zum Senden einer E/A-Anforderung an einen entfernt verbundenen Rechner zur Verarbeitung umfassen. In der in 7 veranschaulichten Ausführungsform, in der ein lokaler Rechner 192 und ein entfernter Rechner 194 durch eine Netzwerkeinrichtung verbunden sind, kann eine Einrichtung zum Senden einer E/A-Anforderung an den entfernt verbundenen Rechner jeder Mechanismus sein, der die E/A-Anforderung an den entfernten Rechner 194 über das Netzwerk überträgt und dem entfernten Rechner 194 gestattet, die E/A-Anforderung zu verarbeiten und zu erfüllen. Zum Beispiel kann in 7 die Einrichtung zum Senden einer E/A-Anforderung an den entfernt verbundenen Rechner einen Weiterleitungstreiber (redirector) 220 und Netzwerktransporttreiber 222 umfassen. In der in 7 veranschaulichten Ausführungsform stellt der Weiterleitungstreiber 220 die Einrichtungen bereit, die erforderlich sind, damit der lokale Rechner 192 auf Ressourcen auf anderen Maschinen auf einem Netzwerk zugreifen kann. Die Netzwerktransporttreiber 222 stellen den Mechanismus zum Übertragen von Informationen vom lokalen Rechner 192 zum entfernten Rechner 194 über die Netzwerkkarte 196 und die Verbindung 198 bereit. Andere Mechanismen können auch verwendet werden, um Einrichtungen zum Senden einer E/A-Anforderung an einen entfernt verbundenen Rechner zu implementieren. Im Allgemeinen umfassen solche Einrichtungen einen Transportmechanismus, um die E/A-Anforderung von einem Rechner zum anderen zu transportieren. Ein solcher Mechanismus kann im Allgemeinen jeden Typ von Verbindung zwischen zwei Rechnern enthalten, wie beispielsweise eine festgeschaltete Verbindung, ein lokales Netz (LAN), ein Fernnetz (WAN), eine Telefonleitung, Funk und so weiter. Außerdem kann eine solche Einrichtung auch einen Mechanismus zum Übernehmen der E/A-Anforderung von dem E/A-System eines Rechners und Zuführen der E/A-Anforderung zu dem E/A-System eines anderen Rechners umfassen. Dies kann verschiedene Typen von Software- oder Firmware-Programmen oder Treibern bedingen. Alles was für eine solche Einrichtung zum Senden eines Mechanismus erforderlich ist, um eine E/A-Anforderung zu transportieren und zuzuführen, ist ein Format, das von einem entfernten Rechner verarbeitet werden kann.
  • In der Ausführungsform von 7, wenn der Decodierer für symbolische Verknüpfungen 202 erkennt, dass eine E/A-Anforderung von dem entfernten Rechner 194 vorgenommen werden muss, kann der Decodierer für symbolische Verknüpfungen 202 die E/A-Anforderungen an den Weiterleitungstreiber 220 übergeben, der die Netzwerktransporttreiber 222 zum Übertragen der E/A-Anforderungen über die Netzwerkkarte 196 und die Verbindung 198 zum entfernten Rechner 194 verwendet. In diesem besonderen Beispiel würde die E/A-Anforderung für den Verzeichnisinhalt des Verzeichnisses gelten, auf das von der symbolischen Verknüpfung verwiesen wird.
  • Eine E/A-Anforderung, die von dem entfernten Rechner 194 empfangen wird, würde von den Netzwerktransporttreibern 224 empfangen und an das Serverdateisystem 226 übergeben. Das Serverdateisystem 226 kommuniziert mit dem Weiterleitungstreiber 220, um alle E/A-Anforderungen zu verarbeiten und zu erfüllen, die an den entfernten Rechner gesendet werden. Um eine E/A-Anforderung zu erfüllen, kann das Serverdateisystem 226 Treiber und Hardware des entfernten Rechners 194 nutzen, wie beispielsweise den Dateisystemtreiber 228 und die Plattensteuereinheit 230. In dem vorliegenden Beispiel nutzt das Serverdateisystem 226 den Dateisystemtreiber 228 zum Abrufen des entspre chenden Verzeichnisinhalts von der Platte 212 und Zurückgeben des Verzeichnisinhalts an den lokalen Rechner 192. Wenn der Verzeichnisinhalt zurückgegeben worden ist, dann kann der Decodierer für symbolische Verknüpfungen 202 den Verzeichnisinhalt an den Client-Prozess 190 zurück übergeben.
  • Obwohl die in 7 veranschaulichte Ausführungsform spezifische Komponenten enthält, die die Kommunikation zwischen dem lokalen Rechner 192 und dem entfernten Rechner 194 durchführen, sind solche Komponenten in jeder Hinsicht als beispielhaft zu betrachten. Alles was für die vorliegende Erfindung erforderlich ist, ist ein Mechanismus, durch den E/A-Anforderungen von einem Treiber in dem lokalen Rechner an einen entfernten Rechner übergeben werden, wo die E/A-Anforderung erfüllt wird und die entsprechenden Informationen zurückgegeben werden. Jeder Mechanismus, von dem diese Funktionen entsprechend erfüllt werden, fällt in den Umfang der vorliegenden Erfindung.
  • Um die volle Bandbreite der Erfindung würdigen zu können, wird im Folgenden auf 8 Bezug genommen, die eine Darstellung auf oberster Ebene einer Ausführungsform zeigt, die die vorliegende Erfindung verwendet, um die Fähigkeiten eines E/A-Systems zu erweitern. Im Allgemeinen wird ein E/A-System verwendet, um Daten an eine Hardware-Vorrichtung zu senden oder von dieser abzurufen. Eine solche Hardware-Vorrichtung kann ein Massenspeicher sein, wie vorher erörtert, oder jeder andere Typ von Hardware-Vorrichtung, einschließlich Netzwerken wie demjenigen, das in 7 veranschaulicht ist, oder jede andere Vorrichtung, die entweder eine Datenquelle oder ein Datenverbraucher ist. Tatsächlich können sogar solche Vorrichtungen wie beispielsweise Tastaturen oder Anzeigevorrichtungen von Abschnitten eines E/A-System gesteuert werden, was von der speziellen Implementierung und Umgebung abhängt. Im Allgemeinen sendet ein Client-Prozess eine E/A-Anforderung an ein E/A-System, um Daten zu einer bestimmten Hardware-Vorrichtung zu senden oder Daten von einer bestimmten Hardware-Vorrichtung abzurufen. Des Weiteren kann das E/A-System einen Client-Prozess warnen, wenn Informationen von einer Hardware-Vorrichtung verfügbar sind. Wie vorher erläutert, ist eine breit gefasste Interpretation einer E/A-Anforderung beabsichtigt. Eine E/A-Anforderung kann daher jede Interaktion zwischen einem Client-Prozess und dem E/A-System umfassen, einschließlich Anforderungen, die Daten in das E/A-System senden oder die Daten aus dem E/A-System empfangen.
  • In 8 wird die allgemeine Hardware-Vorrichtung durch die Hardware-Vorrichtung 232 veranschaulicht. Wie in den vorher angegebenen Beispielen veranschaulicht, können einer oder mehrere Treiber von einem E/A-System verwendet werden, um auf eine bestimmte Hardware-Vorrichtung zuzugreifen. In 8 werden die Treiber, die zum Zugreifen auf die Hardware-Vorrichtung 232 verwendet werden, durch die Hardware-Zugriffstreiber 234 veranschaulicht. Die Hardware-Zugriffstreiber 234 sind ein weiteres Beispiel für Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen. Die Hardware-Zugriffstreiber 234 können jede Anzahl oder jeder Typ von Treibern sein, die für den Zugriff auf eine Hardware-Vorrichtung 232 benötigt werden. Wenn die Hardware-Vorrichtung 232 zum Beispiel eine Platte ist, dann können die Hardware-Zugriffstreiber 234 eines oder beides von einem Dateisystemtreiber und einem Plattentreiber sein. Wenn die Hardware-Vorrichtung 232 eine Netzwerkvorrichtung ist, dann können die Hardware-Zugriffstreiber 234 jede Anzahl oder jeder Typ von Treibern sein, die für den Zugriff auf das Netzwerk benötigt werden. Eine solche Situation kann zum Beispiel auftreten, wenn ein Zugriff auf eine Massenspeichervorrichtung über ein Netzwerk erfolgt.
  • Um die Fähigkeiten eines E/A-Systems zu erweitern und zusätzliche Funktionalität hinzuzufügen, die ursprünglich nicht in dem E/A-System enthalten ist, können einer oder mehrere Erweiterungstreiber hinzugefügt werden, um spezifische Typen von E/A-Anforderungen zu verarbeiten. In 8 werden solche spezifischen Typen von Treibern durch den Erweiterungstreiber 236 veranschaulicht. Der Erweiterungstreiber 236 ist ein weiteres Beispiel für Treibereinrichtungen zum Verarbeiten von E/A-Anforderungen. Der Erweiterungstreiber 236 ist typischerweise repräsentativ für eine Treiberschicht, die Reparse-Daten in Übereinstimmung mit den allgemeinen Prinzipen verarbeitet, die oben in den vorgenannten Beispielen veranschaulicht wurden. Wie vorher erläutert ist der Erweiterungstreiber 235 während normaler E/A-Operationen nicht Teil der Verarbeitung der E/A-Anforderung. Wenn jedoch ein Reparse-Punkt von den Hardware-Zugriffstreibern 234 angetroffen wird, wird die Steuerung auf den Erweiterungstreiber 236 übertragen, um es dem Erweiterungstreiber 236 zu gestatten, in die Verarbeitung der E/A-Anforderung einzugreifen.
  • Wie vorher erläutert, wird die Verarbeitung, die anschließend stattfindet, wenn der Erweiterungstreiber 236 die Steuerung übernimmt, durch die Erfindung nicht erklärt. Die Erfindung kann verwendet werden, um jeden Typ von Verarbeitung durchzuführen. In einem Beispiel ist ein Reparse-Punkt in einer Umgebung einer Heimautomation erstellt. Wenn auf den Reparse-Punkt zugegriffen wird, wird die Steuerung an einen Erweiterungstreiber übergeben, der dann die dem Reparse-Punkt entsprechenden Maßnahmen ergreift. Zum Beispiel ist eventuell die Telefonnummer der Feuerwehr oder der Polizei als Teil der Reparse-Punkt-Informationen gespeichert. Wenn eine E/A-Anforderung mit einem Reparse-Punkt ausgegeben wird, könnte die Steuerung auf einen bestimmten Treiber übertragen werden, der dann die Telefonnummer aus dem Reparse-Punkt extrahiert und die Nummer der Feuerwehr oder Polizei wählt. Nachdem der Kontakt mit der Polizei oder der Feuerwehr hergestellt ist, können entsprechende Maßnahmen ergriffen werden, wie beispielsweise Senden von synthetischer Sprache oder anderen Audio-Informationen, um die Polizei oder Feuerwehr über einen bestimmten Zustand zu informieren. Wenn ein E/A-System einen Reparse-Punkt antrifft und die Steuerung zu einem bestimmten Erweiterungstreiber zur Verarbeitung übertragen wird, können anschließend im Wesentlichen alle Maßnahmen ergriffen werden, einschließlich Maßnahmen, die normalerweise nicht mit einem E/A-System oder mit Dateien oder anderen Informationen verbunden sind, die auf Speichervorrichtungen gespeichert sind.
  • Wenn ein Erweiterungstreiber, wie beispielsweise ein Erweiterungstreiber 236, die Verarbeitungszuständigkeit für eine E/A-Anforderung übernimmt, kann der Erweiterungstreiber jede Verarbeitung durchführen. Der Erweiterungstreiber kann, falls zweckmäßig, andere Dienste oder Treiber zum Abarbeiten seiner Aufgabe in Anspruch nehmen. In 8 werden solche anderen Treiber oder Dienste durch die Erweiterungstreiber-Dienste 238 veranschaulicht. Die Erweiterungstreiber-Dienste 238 können alle anderen Treiber oder Dienste sein, einschließlich Hardware-Vorrichtungen, die der Erweiterungstreiber 236 nutzen muss, um seine Aufgabe abzuarbeiten. Offensichtlich kann eine solche Funktionalität vom Erweiterungstreiber 236 getrennt oder direkt in diesen integriert sein, was von der speziellen Implementierung und den Auslegungs-Wahlmöglichkeiten abhängt, die für diese Implementierung getroffen wurden.
  • Schließlich ist anzumerken, dass Informationen, die zum Abarbeiten der Verarbeitung der E/A-Anforderung notwendig oder wünschenswert sind, von dem Reparse-Punkt, von der ursprünglichen E/A-Anforderung oder von beiden kommen können. Die ursprüngli che E/A-Anforderung sowie die Informationen in dem Reparse-Punkt sind für den Erweiterungstreiber 236 verfügbar.
  • Kurz gesagt stellt die vorliegende Erfindung einen Mechanismus zum Unterbrechen der normalen Verarbeitung einer E/A-Anforderung bereit und zum Gestatten, dass ein Treiber, der normalerweise nicht an der normalen Verarbeitung der E/A-Anforderung beteiligt ist, die Zuständigkeit für die Verarbeitung der E/A-Anforderung übernimmt. Das Verfahren und das System, die durch die vorliegende Erfindung definiert werden, sind sowohl flexibel als auch erweiterbar. Da die vorliegende Erfindung die genauen Details der Verarbeitung der E/A-Anforderung nicht definiert, sondern nur ein Verfahren, um einen Eingriff in die normale Verarbeitungsfolge zu gestatten, kann die Erfindung eingesetzt werden, um eine große Bandbreite von Ergebnissen zu erreichen. Im Wesentlichen gestattet der Mechanismus, dass spezielle Typen von Daten oder Verzeichnissen definiert werden, und dann die Steuerung zur Verarbeitung von E/A-Anforderungen mit den speziellen Dateien oder Verzeichnissen an einen bestimmten Treiber übergeben wird, der für die Verarbeitung der E/A-Anforderungen mit der speziellen Datei bzw. dem speziellen Verzeichnis ausgelegt ist. Obwohl die Verwendung, die in diesem Patent beschrieben ist, dergestalt ist, dass ein verteiltes Dateisystem so verwaltet wird, als wäre es ein einzelnes Dateisystem, kann die vorliegende Erfindung auch nützlich sein bei der Verwaltung eines hierarchischen Speichers, der Verwaltung von sicheren oder verschlüsselten Dateien oder Verzeichnissen, der Verwaltung von neuen Möglichkeiten, auf Dateien oder Verzeichnisse auf eine andere Weise zuzugreifen oder diese zu organisieren als in der hierarchischer Weise, die üblicherweise von modernen Rechnern verwendet wird, oder jeder anderen Verwendung, die vorstellbar ist oder entwickelt werden kann, wenn ein spezieller Typ von Datei oder Verzeichnis definiert wird. Ferner kann die Verarbeitung, die erfolgt, sobald die Steuerung an einen Treiber übergeben worden ist, der für die Verarbeitung der E/A-Anforderung ausgelegt ist, nichts mit den herkömmlichen E/A-Operationen, an denen Dateien oder Verzeichnisse beteiligt sind, zu tun haben. Der spezielle Treiber kann jede Verarbeitung unter Verwendung aller Ressourcen, Treiber oder Systeme durchführen, die für die gewünschte Aufgabe geeignet sind.
  • Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt sein.
  • Die beschriebenen Ausführungsformen sind in jeder Hinsicht nur als veranschaulichend und nicht einschränkend zu betrachten. Der Umfang der Erfindung wird daher durch die Ansprüche im Anhang angegeben statt durch die vorhergehende Beschreibung. Alle Änderungen, die innerhalb des Sinngehalts der Ansprüche liegen, sind in ihren Umfang aufzunehmen.

Claims (9)

  1. Verfahren zum Unterbrechen der Verarbeitungsfolge in einem E/A-System, das eine Vielzahl von in Schichten angeordneten Treibermitteln (42, 44, 46, 144, 146, 148, 150, 152, 202, 204, 206, 234, 236) zur Verarbeitung von E/A-Anforderungen verwendet, wobei die Vielzahl von in Schichten angeordneten Treibermitteln ein erstes Treibermittel (46, 152, 206, 234) und ein zweites Treibermittel (42, 146,236) umfassen, wobei das Verfahren die Schritte aufweist: Empfangen (48) einer E/A-Anforderung (108, 178) durch ein erstes Treibermittel, um eine angegebene E/A-Operation auszuführen; und Bestimmen durch das erste Treibermittel, ob die E/A-Anforderung die zumindest teilweise Verarbeitung durch ein anderes Treibermittel erfordert, indem bestimmt wird, ob die E/A-Anforderung zumindest eine Datei oder ein Verzeichnis mit einem zugehörigen Attribut (72) eines Punktess des erneuten Parsens (reparse point) beinhaltet, wobei das Reparse-Punkt-Attribut Informationen zum Reparse-Punkt mit Daten enthält, die einen speziellen Treiber bestimmen, der zumindest einen Teil der E/A-Anforderung und Daten verarbeiten soll, die von dem speziellen Treiber bei der Verarbeitung zumindest eines Teils der E/A-Anforderung verwendet werden; Wobei, wenn zumindest entweder die Datei oder das Verzeichnis ein zugehöriges Reparse-Punkt-Attribut (72) haben, das erste Treibermittel Folgendes ausführt: Extrahieren der Informationen zum Reparse-Punkt (124, 182), die zumindest mit der Datei oder dem Verzeichnis verknüpft sind; und Übergeben (52) der extrahierten Informationen zum Reparse-Punkt an das zweite Treibermittel zur Verarbeitung, wobei das zweite Treibermittel die extrahierte Informationen zum Reparse-Punkt (124) untersucht, um zu ermitteln, ob das zweite Treibermittel der spezielle Treiber ist, und falls dies so ist, das zweite Treibermittel zumindest einen Teil der E/A-Anforderung verarbeitet.
  2. Verfahren zum Unterbrechen der Verarbeitungsfolge nach Anspruch 1, das weiterhin die Schritte aufweist: Empfangen der extrahierten Informationen zum Reparse-Punkt vom ersten Treibermittel durch das zweite Treibermittel; und Verwenden zusätzlicher Treibermittel zum Verarbeiten der E/A-Anforderung.
  3. Verfahren zum Unterbrechen der Verarbeitungsfolge, wie in einem beliebigen der vorhergehenden Ansprüche angegeben, wobei die Vielzahl der Treibermittel weitere Treibermittel umfassen und wobei das Verfahren weiterhin die folgenden Schritte aufweist: Empfangen der extrahierten Informationen zum Reparse-Punkt vom ersten Treibermittel durch das zweite Treibermittel; und Senden einer E/A-Anforderung durch das zweite Treibermittel an die weiteren Treibermittel.
  4. Verfahren zum Unterbrechen der Verarbeitungsfolge, wie in einem beliebigen der vorhergehenden Ansprüche angegeben, wobei wenn zumindest die Datei oder das Verzeichnis ein zugehöriges Reparse-Punkt-Attribut aufweist, das erste Treibermittel dann den Schritt ausführt, Statusinformationen (126) an das zweite Treibermittel zu senden, die dem zweiten Treibermittel angeben, dass zumindest die Datei oder das Verzeichnis ein zugehöriges Reparse-Punkt-Attribut aufweist.
  5. Verfahren zum Unterbrechen der Verarbeitungsfolge, wie in einem beliebigen der vorhergehenden Ansprüche angegeben, das weiterhin den Schritt aufweist, die extrahierten Informationen zum Reparse-Punkt, die zumindest mit einer Datei oder einem Verzeichnis verbunden sind, der Reihe nach an jedes der Vielzahl der Treibermittel zu übergeben, bis sich ein Treibermittel aus der Vielzahl der Treibermittel als Eigentümer der extrahierten Informationen zum Reparse-Punkt bestimmt und die Verarbeitung der E/A-Anforderung übernimmt.
  6. Verfahren zum Unterbrechen der Verarbeitungsfolge nach Anspruch 3, wobei die E/A-Anforderung einen Pfadnamen enthält, der zumindest die Datei oder das Verzeichnis beinhaltet, und wobei das Verfahren weiterhin den Schritt aufweist, Informationen an die weiteren Treiber über den Fortschritt des ersten Treibers beim Auflösen des Pfadnamens zu übergeben, bevor auf das Reparse-Punkt-Attribut getroffen wurde.
  7. Verfahren zum Unterbrechen der Verarbeitungsfolge nach Anspruch 6, das weiterhin den Schritt aufweist, Informationen von der E/A-Anforderung zusätzlich zu den extrahierten Informationen zum Reparse-Punkt bei der Verarbeitung der E/A-Anforderung zu übergeben.
  8. Computerprogramm-Code, der vom Computer ausführbare Anweisungen umfasst, die von einem Datenverarbeitungsgerät ausführbar sind, um das Verfahren eines beliebigen vorhergehenden Anspruchs auszuführen.
  9. Von einem Computer lesbares Medium, das einen Computerprogramm-Code nach Anspruch 8 enthält.
DE69838756T 1997-04-15 1998-04-14 Die verarbeitung von eingabe/ausgabeanforderungen von mehreren treibern ermöglichen dateisystem-primitivroutine in einem mehrschicht-treiber-e/a-system Expired - Lifetime DE69838756T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US862025 1992-04-02
US83959397A 1997-04-15 1997-04-15
US839593 1997-04-15
US08/862,025 US5931935A (en) 1997-04-15 1997-05-22 File system primitive allowing reprocessing of I/O requests by multiple drivers in a layered driver I/O system
PCT/US1998/007595 WO1998047074A1 (en) 1997-04-15 1998-04-14 File system primitive allowing reprocessing of i/o requests by multiple drivers in a layered driver i/o system

Publications (2)

Publication Number Publication Date
DE69838756D1 DE69838756D1 (de) 2008-01-03
DE69838756T2 true DE69838756T2 (de) 2008-10-30

Family

ID=25280157

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69838756T Expired - Lifetime DE69838756T2 (de) 1997-04-15 1998-04-14 Die verarbeitung von eingabe/ausgabeanforderungen von mehreren treibern ermöglichen dateisystem-primitivroutine in einem mehrschicht-treiber-e/a-system

Country Status (2)

Country Link
US (1) US5931935A (de)
DE (1) DE69838756T2 (de)

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5963962A (en) 1995-05-31 1999-10-05 Network Appliance, Inc. Write anywhere file-system layout
US6604118B2 (en) 1998-07-31 2003-08-05 Network Appliance, Inc. File system image transfer
WO1994029795A1 (en) 1993-06-04 1994-12-22 Network Appliance Corporation A method for providing parity in a raid sub-system using a non-volatile memory
US6516351B2 (en) * 1997-12-05 2003-02-04 Network Appliance, Inc. Enforcing uniform file-locking for diverse file-locking protocols
US6314422B1 (en) * 1997-12-09 2001-11-06 Chrysler Corporation Method for softlinking between documents in a vehicle diagnostic system
US6457130B2 (en) * 1998-03-03 2002-09-24 Network Appliance, Inc. File access control in a multi-protocol file server
US6317844B1 (en) 1998-03-10 2001-11-13 Network Appliance, Inc. File server storage arrangement
US6496839B2 (en) 1998-06-12 2002-12-17 Microsoft Corporation Persistent names for logical volumes
US6119131A (en) * 1998-06-12 2000-09-12 Microsoft Corporation Persistent volume mount points
US6654881B2 (en) 1998-06-12 2003-11-25 Microsoft Corporation Logical volume mount manager
US6279011B1 (en) 1998-06-19 2001-08-21 Network Appliance, Inc. Backup and restore for heterogeneous file server environment
US6574591B1 (en) 1998-07-31 2003-06-03 Network Appliance, Inc. File systems image transfer between dissimilar file systems
US8234477B2 (en) 1998-07-31 2012-07-31 Kom Networks, Inc. Method and system for providing restricted access to a storage medium
US9361243B2 (en) 1998-07-31 2016-06-07 Kom Networks Inc. Method and system for providing restricted access to a storage medium
US6119244A (en) * 1998-08-25 2000-09-12 Network Appliance, Inc. Coordinating persistent status information with multiple file servers
US6343984B1 (en) 1998-11-30 2002-02-05 Network Appliance, Inc. Laminar flow duct cooling system
US6965911B1 (en) * 1998-12-21 2005-11-15 Intel Corporation Efficiently exporting local device access onto a system area network using a direct-call interface
JP4294142B2 (ja) 1999-02-02 2009-07-08 株式会社日立製作所 ディスクサブシステム
US20030157292A1 (en) * 1999-06-23 2003-08-21 Dataplay, Inc. Miniature optical disk for data storage
US6832379B1 (en) * 1999-08-17 2004-12-14 Emc Corporation Computer architecture utilizing layered device drivers
US6961749B1 (en) 1999-08-25 2005-11-01 Network Appliance, Inc. Scalable file server with highly available pairs
US6553387B1 (en) 1999-11-29 2003-04-22 Microsoft Corporation Logical volume configuration data management determines whether to expose the logical volume on-line, off-line request based on comparison of volume epoch numbers on each extents of the volume identifiers
US6684231B1 (en) 1999-11-29 2004-01-27 Microsoft Corporation Migration of friendly volumes
US6883120B1 (en) 1999-12-03 2005-04-19 Network Appliance, Inc. Computer assisted automatic error detection and diagnosis of file servers
US6715034B1 (en) 1999-12-13 2004-03-30 Network Appliance, Inc. Switching file system request in a mass storage system
US7150018B2 (en) * 2000-02-16 2006-12-12 Microsoft Corporation Method and system for deterministic ordering of software modules
US6823398B1 (en) * 2000-03-31 2004-11-23 Dphi Acquisitions, Inc. File system management embedded in a storage device
US6990058B1 (en) 2000-04-03 2006-01-24 Dphi Acquisitions, Inc. Structure and method for storing data on optical disks
US6738333B1 (en) 2000-05-30 2004-05-18 Dphi Acquisitions, Inc. Format for recording data in a storage disk
US7051054B1 (en) 2000-05-30 2006-05-23 Dphi Acquisitions, Inc. Method and apparatus for emulating read/write file system on a write-once storage disk
EP1436700A2 (de) * 2000-05-30 2004-07-14 DPHI Aquisitions, Inc. Fehlerverwaltungssystem für einmal beschreibbare speicherplatte
TW573299B (en) * 2000-08-31 2004-01-21 Dataplay Inc Double-sided digital optical disk and method and apparatus for making
US6813670B1 (en) * 2000-09-26 2004-11-02 Microsoft Corporation Automatic server-side plug-and-play without user intervention
US7167982B2 (en) * 2001-09-14 2007-01-23 Lenovo (Singapore) Pte Ltd. Securing decrypted files in a shared environment
US7165260B2 (en) * 2002-06-12 2007-01-16 Fsl, L.L.C. Layered computing systems and methods for insecure environments
US7243353B2 (en) * 2002-06-28 2007-07-10 Intel Corporation Method and apparatus for making and using a flexible hardware interface
US7653632B2 (en) * 2002-10-01 2010-01-26 Texas Instruments Incorporated File system for storing multiple files as a single compressed file
US7802022B2 (en) * 2004-04-29 2010-09-21 Microsoft Corporation Generic USB drivers
US20060117018A1 (en) * 2004-11-30 2006-06-01 Microsoft Corporation Method and system for caching remote files locally
US8230068B2 (en) * 2004-12-02 2012-07-24 Netapp, Inc. Dynamic command capacity allocation across multiple sessions and transports
US7672979B1 (en) * 2005-04-22 2010-03-02 Symantec Operating Corporation Backup and restore techniques using inconsistent state indicators
US7730040B2 (en) * 2005-07-27 2010-06-01 Microsoft Corporation Feedback-driven malware detector
US7647308B2 (en) * 2006-11-08 2010-01-12 Mcafee, Inc. Method and system for the detection of file system filter driver based rootkits
IES20080508A2 (en) * 2007-06-22 2008-12-10 Tenoware R & D Ltd Network distributed file system
US20090049459A1 (en) * 2007-08-14 2009-02-19 Microsoft Corporation Dynamically converting symbolic links
CN104199894A (zh) * 2014-08-25 2014-12-10 百度在线网络技术（北京）有限公司 一种文件扫描方法及装置
US10223378B2 (en) 2015-11-02 2019-03-05 Microsoft Technology Licensing, Llc Controlling reparse behavior associated with an intermediate directory
US20180059990A1 (en) 2016-08-25 2018-03-01 Microsoft Technology Licensing, Llc Storage Virtualization For Files
US20190213015A1 (en) * 2018-01-09 2019-07-11 Microsoft Technology Licensing, Llc Extensible input stack for processing input device data
US10599444B2 (en) 2018-01-09 2020-03-24 Microsoft Technology Licensing, Llc Extensible input stack for processing input device data
CN113885948B (zh) * 2021-09-29 2023-05-30 武汉噢易云计算股份有限公司 windows镜像分层的管理方法及装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3996564A (en) * 1974-06-26 1976-12-07 International Business Machines Corporation Input/output port control
US4701848A (en) * 1984-11-19 1987-10-20 Clyde, Inc. System for effectively paralleling computer terminal devices
US5206951A (en) * 1987-08-21 1993-04-27 Wang Laboratories, Inc. Integration of data between typed objects by mutual, direct invocation between object managers corresponding to object types
US5247681A (en) * 1990-12-18 1993-09-21 International Business Machines Corporation Dynamic link libraries system and method
CA2067650C (en) * 1991-07-24 1996-10-22 Eric Jonathan Bauer Method and apparatus for operating a computer-based file system
US5519833A (en) * 1992-08-13 1996-05-21 Computervision Corporation Distributed data processing system providing a distributed stream software environment to enable application on a first system to use driver on a second system
US5781797A (en) * 1992-09-30 1998-07-14 Microsoft Corporation Method and system for configuring device driver by selecting a plurality of component drivers to be included in the device driver
US5652913A (en) * 1992-10-13 1997-07-29 Microsoft Corporation System for providing intercommunication of I/O access factors stored in a shared data structure, accessed and maintained by both file system and device driver
US5369770A (en) * 1992-11-02 1994-11-29 Microsoft Corporation Standardized protected-mode interrupt manager
EP0610677A3 (de) * 1993-02-12 1995-08-02 Ibm In zwei Modi arbeitender Kommunikationsgerätetreiber.
US5592683A (en) * 1994-03-18 1997-01-07 Ibm Corporation System for selectively processing nested print commands and buffered post-print commands thereafter and resending selected portion of data stream upon error detection
US5630076A (en) * 1995-05-05 1997-05-13 Apple Computer, Inc. Dynamic device matching using driver candidate lists
US5778168A (en) * 1995-09-11 1998-07-07 Sun Microsystems, Inc. Transaction device driver technique for a journaling file system to ensure atomicity of write operations to a computer mass storage device

Also Published As

Publication number Publication date
DE69838756D1 (de) 2008-01-03
US5931935A (en) 1999-08-03

Similar Documents

Publication Publication Date Title
DE69838756T2 (de) Die verarbeitung von eingabe/ausgabeanforderungen von mehreren treibern ermöglichen dateisystem-primitivroutine in einem mehrschicht-treiber-e/a-system
DE69423151T2 (de) Verwendung der zuletzt gültigen Konfiguration zum Laden eines Rechnersystems
DE69112156T2 (de) Gerät zur Realisierung von Datenbanken zum Verschaffen von objektorientiertem Aufrufen von Anwendungsprogrammen.
DE69907919T2 (de) Mehrsprachige benutzeroberfläche für ein betriebssystem
DE69031491T2 (de) Hypertextdatenverarbeitungssystem und Verfahren
DE10297281B4 (de) Verfahren zum elementaren Aktualisieren einer Vielzahl von Dateien
DE69427174T2 (de) Dynamische Hochleistungsprogrammverknüpfung durch Cachespeicherung
DE69131745T2 (de) Verfahren und Gerät zum Verschaffen einer Kundenschnittstelle zu einem objektorientierten Aufruf eines Anwendungsprogramms
DE69131245T2 (de) Verfahren und Gerät zum Verschaffen von dynamischen Aufrufen von Anwendungsprogrammen in einer verteilten heterogenen Umgebung
DE69802437T2 (de) Feinkörniger übereinstimmungsmechanismus für optimistische parallelsteuerung mit verriegelungsgruppen
DE3689664T2 (de) Verfahren und Gerät zur Verwaltung von veralteten Datenobjekten.
DE69604734T2 (de) Client-Server-Computersystem und Verfahren zum Verwenden eines lokalen Plattenlaufwerks als Daten-Cache
DE4435751B4 (de) Dateiname- und Verzeichnis- Erfassungsverfahren zur Verwendung mit einem Betriebssystem
DE69533530T2 (de) Verfahren und System zur dynamischen Aggregation von Objekten
DE69228621T2 (de) Objektorientiertes verteiltes Rechnersystem
DE10112941B4 (de) System und Verfahren für das parallele Lesen von primären und sekundären Sicherungen zur Wiederherstellung mehrerer gemeinsam benutzter Datenbankdateien
DE69513956T2 (de) Datenspeicherverwaltung für in einem netzwerk zusammengeschaltete prozessoren
DE69533786T2 (de) Vorrichtung zum Erzeugen von objektorientierten Schnittstellen für relationale Datenbanken und von dieser Vorrichtung durchgeführtes Verfahren
DE69503065T2 (de) Objektorientierte vorrichtung für konfigurationsverlaufsverwaltung
DE69131742T2 (de) Verfahren zur Realisierung von Anbieterfunktionen in einer verteilten heterogenen Umgebung
DE69428848T2 (de) Mehrsprachige Standardressourcen
DE69713409T2 (de) Dokumenten-Verwaltungssystem unter Verwendung von objekt- und agentorientierten Methoden
DE60001976T2 (de) Verfahren und system zur datensicherung/wiederherstellung von an einer einzigen stelle gespeicherten dateien
DE69229982T2 (de) Verfahren und Gerät um ein rechnergestütztes Dateiensystem zu betreiben
DE69636330T2 (de) Verfahren für On-line- und Echzeit-Datenmigration

Legal Events

Date Code Title Description
8364 No opposition during term of opposition