DE112010003049T5

DE112010003049T5 - Dateisystem für duale Betriebssysteme

Info

Publication number: DE112010003049T5
Application number: DE112010003049T
Authority: DE
Inventors: Dileep Venkata Rao Madhava; Richard Bramley; Banga Gaurav
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2009-08-27
Filing date: 2010-08-27
Publication date: 2012-06-06
Also published as: GB2485111B; CN102473089A; US20110055536A1; GB201202798D0; CN102473089B; KR20120104161A; GB2485111A; WO2011031537A2; KR101638658B1; US8195929B2; WO2011031537A3

Abstract

Verfahren, Systeme, Vorrichtungen und Programmprodukte sind offenbart zum Verwalten, Aktivieren und Steuern von Dateisystemen, die von zwei oder mehr Betriebssystemen gemeinschaftlich verwendet werden und/oder dergleichen in einer Rechenvorrichtung oder in einer einzigen Computerbetriebssitzung oder einem solchen Kontext. Die Journalführung und Resynchronisation von Dateisystemen wird bereitgestellt, selbst wenn zumindest eines der Betriebssysteme keine Merkmale aufweist zum Berücksichtigen des Vorliegens des anderen Betriebssystems.

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf Personalcomputer und Vorrichtung, die ähnliche Architekturen gemeinschaftlich verwenden, und bezieht sich insbesondere auf ein System und ein entsprechendes Verfahren zum Verwalten, Aktivieren und Steuern von Dateisystemen, die von zwei oder mehr Betriebssystemen gemeinschaftlich verwendet werden und/oder dergleichen in einer Rechenvorrichtung oder in einer einzigen Computerbetriebssitzung oder einem solchen Kontext.
Hintergrund der Erfindung
Heutzutage ist die Verwendung von PCs (Personalcomputern), die zunehmend so genannte Laptop- und Notebookcomputer umfassen, zunehmend üblich und die Computer selbst sind zunehmend rechenstark, haben eine verringerte thermische Leistung und werden immer komplexer.
Ältere PCs hatten eine einzige und allumfassende Steuersoftware, normalerweise ein Windows-Betriebssystem, beispielsweise Microsoft^® Vista^® (ein Handelsprodukt) oder Linux^® mit GNOME (ein Open-Source-Programm bzw. -quelloffenes Programm).
Handelsübliche Windows^®-Produkte und Open-Source-Betriebssysteme haben jeweils bestimmte Vorteile, die Käufer von Laptopcomputern zunehmen haben möchten, und verwenden beide. Eine gleichzeitige Bereitstellung von mehreren Betriebssystemprogrammprodukten auf einem einzigen Computer ergibt verschiedene Herausforderungen, einschließlich Multi-Boot, ACPI-unterstütztes Laden und Virtualisierung-Hypervisor-Programme mit zugeordneter Hardwareunterstützung.
Ein weiteres Problem ergibt sich bezüglich der gemeinschaftlichen Verwendung von Daten und somit der gemeinschaftlichen Verwendung von Dateisystemen (FS; FS = file systems) über mehrere Betriebssysteme. Dies ist insbesondere ein Problem, wo mehrere Betriebssysteme entweder effektiv gleichzeitig oder hintereinander und abwechselnd in einer einzigen Betriebssitzung arbeiten. Typischerweise geht für einen PC eine Betriebssitzung vom POST (power-on self-test = Einschalt-Selbsttest) bis zum ordnungsgemäßen Abschalten des Betriebssystems und normalerweise einer Abschaltsequenz. Mutex (wechselseitiger Ausschluss), Ressourcensperrung (resource locking) und ähnliche Techniken sind gut bekannt im Computerwesen, wo mehrere Entitäten (Ausführungsthreads, Prozessorkerne, verteilte Prozessoren, usw.) Datendateiressourcen effektiv gemeinschaftlich verwenden müssen. Solche Situationen wurden im Computerwesen bisher allgemein gelöst durch kooperative Softwareprozeduren, um ordnungsgemäßes gemeinschaftliches Verwenden von Ressourcen sicherzustellen, oder zumindest eine geordnete Ressourcenzuordnung. Von einem Closed-Source-(Geschlossene-Quellen-)Betriebssystem kann jedoch nicht erwartet werden, dass es gemeinschaftliche Verwendung von Ressourcen mit anderen Betriebssystemen ermöglicht, wenn es (bestimmt durch den Entwurf) keine Kenntnis von diesem anderen Betriebssystem hat.
Eine weniger allgemeine Lösung ist erforderlich, wo Dateien gleichzeitig oder abwechselnd verfügbar sein sollen zwischen zwei oder mehr Betriebssystemen, und die vorliegende Erfindung adressiert zumindest eine solche Situation. Insbesondere wo ein Closed-Source-Betriebssystem fortgeschrittene oder hoch entwickelte Datenhandhabungsmerkmale implementiert, beispielsweise Journal- bzw. Protokollführung (journalizing) oder Programmhaltepunkt/Wiederholung (checkpoint/rollback), dann kann es für andere Betriebssysteme als nicht folgsam erscheinen (oder zumindest so, dass es sich nicht auf leicht zu verstehende Weise verhält). Die vorliegende Erfindung adressiert eine besonders übliche und weitere Situationen.
Bisherige Lösungen umfassten, dass jedes Betriebssystem vollständige Steuerung seines eigenen Dateisystems übernimmt, das dann für die anderen Betriebssysteme als RO (RO = read-only = nur zum Lesen) angesehen wird. Dadurch wird dasselbe nicht nur unnötig in seinen Fähigkeiten beschränkt, sondern kann sogar nicht einmal einheitliche Ergebnisse erzeugen, wenn ein Dateisystem in der Mitte der Sitzung auf unerwartete oder anderweitig undokumentierte Weise durch ein Betriebssystem verlassen wird, das das Dateisystem für RW (RW = read-write = Lesen-Schreiben) geöffnet hat. In einigen Fällen kann ein solches Dateisystem sogar selbst für RO als nicht einhängbar (un-mountable) (oder verfälscht) erfasst werden außerhalb des Kontexts des Betriebssystems, das RW-Zugriff auf dasselbe hat.
Ein wesentlicher Vorteil von Ausführungsbeispielen der Erfindung im Vergleich zu bisher entwickelten Lösungen ist, dass es möglich wird, die Ausführung zwischen mehr als einem Betriebssystem hin- und herzuschalten, ohne Dateisysteme abzuschalten und neu starten zu müssen (und dadurch auch Betriebssysteme neu starten zu müssen) zwischen dem Schalten von Betriebssystemkontext innerhalb einer einzigen Betriebssitzung.
Zusammenfassung der Erfindung
Die vorliegende Erfindung schafft ein Verfahren zum Betreiben eines Computers und auch eine Vorrichtung, die das Verfahren enthält. Außerdem werden Programmprodukte und andere Einrichtungen zum Ausnutzen der Erfindung präsentiert.
Gemäß eine Aspekt der vorliegenden Erfindung kann ein Ausführungsbeispiel der Erfindung Folgendes bereitstellen: Laden von zwei Betriebssystemen, Einhängen (mounten) eines ersten Dateisystems, das durch das zweite Betriebssystem gesteuert wird und auf das das erste Betriebssystem Nur-Lese-Zugriff hat, Einhängen eines Journals bzw. Protokolls, das durch das erste Betriebssystem gesteuert wird. Ferner das Umleiten von Daten, die von einem Anwendungsprogramm unter dem ersten Betriebssystem geschrieben wurden, zu dem Journal, dann Wiederaufnehmen der Ausführung des zweiten Betriebssystems und Anwenden des Journals an das erste Betriebssystem im Kontext des zweiten Betriebssystems.
Ein Vorteil und/oder Merkmal, das durch das Implementieren der vorliegenden Erfindung bereitgestellt wird oder sich daraus ergibt, ist, dass Dateien in einem einzigen Dateisystem durch zwei Betriebssysteme abwechselnd verwendet werden können, während das eine angehalten (suspended) und das andere aktiv wird.
Kurze Beschreibung der Zeichnungen
Die vorher erwähnten und verwandten Vorteile und Merkmale der vorliegenden Erfindung werden besser verständlich und klarer bei der Betrachtung der folgenden detaillierten Beschreibung der Erfindung in Verbindung mit den folgenden Zeichnungen, die in die Beschreibung aufgenommen sind und einen Teil derselben bilden, ein Ausführungsbeispiel der Erfindung darstellen und bei denen gleiche Bezugszeichen gleiche Elemente darstellen.
1 ist ein schematisches Blockdiagramm eines Elektronikgeräts, das konfiguriert ist, um die Sicherheitsfunktionalität gemäß der vorliegenden Erfindung zu implementieren;
2 und 3 zusammengenommen bilden ein Flussdiagramm, das eine Übersicht über einige Schritte darstellt, die beim Implementieren eines Ausführungsbeispiels der vorliegenden Erfindung durchgeführt werden;
4 ist ein Diagramm, das Beziehungen zwischen bestimmten Softwarekomponenten eines Ausführungsbeispiels der Erfindung zeigt;
5 zeigt, wie ein beispielhaftes Ausführungsbeispiel der Erfindung auf einem Computermedium oder Computermedien codiert werden kann; und
6 zeigt, wie ein beispielhaftes Ausführungsbeispiel der Erfindung unter Verwendung elektromagnetischer Wellen codiert, gesendet, empfangen und decodiert werden kann.
Detaillierte Beschreibung der Erfindung
Die zahlreichen Komponenten, die in den Zeichnungen gezeigt sind, sind präsentiert, um einem Durchschnittsfachmann auf diesem Gebiet eine gründliche ausführbare Offenbarung der vorliegenden Erfindung bereitzustellen. Die Beschreibung gut bekannter Komponenten ist in dieser Beschreibung nicht enthalten, um die Offenbarung nicht zu behindern oder die Neuartigkeit der vorliegenden Erfindung und die dadurch bereitgestellten Hauptvorteile wegzunehmen oder anderweitig zu reduzieren.
Ein beispielhaftes Ausführungsbeispiel der vorliegenden Erfindung wird nun mit Bezugnahme auf die Figuren beschrieben. 1 ist ein schematisches Blockdiagramm eines Elektronikgeräts, das konfiguriert ist, um die Sicherheitsfunktionalität gemäß der vorliegenden Erfindung zu implementieren.
Bei einem beispielhaften Ausführungsbeispiel kann das Elektronikgerät 10 als ein Personalcomputer, beispielsweise ein Desktopcomputer, ein Laptopcomputer, ein Tablet-PC oder ein anderes geeignetes Rechengerät implementiert sein. Obwohl die Beschreibung den Betrieb eines Personalcomputers darstellt, ist für Durchschnittsfachleute auf diesem Gebiet klar, dass das Elektronikgerät 10 als ein PDA, ein drahtloses Kommunikationsgerät, beispielsweise ein Mobiltelefon, eingebettete Steuerungen oder Vorrichtungen, beispielsweise Set-Top-Boxen, Druckvorrichtungen oder andere geeignete Vorrichtungen oder Kombinationen derselben implementiert sein kann, und geeignet ist zum Arbeiten oder Zusammenarbeiten mit der Erfindung.
Das Elektronikgerät 10 kann zumindest einen Prozessor oder eine CPU (CPU = central processing unit = zentrale Verarbeitungseinheit) 12 umfassen, die konfiguriert ist, um den Gesamtbetrieb des Elektronikgeräts 10 zu steuern. Ähnliche Steuerungen oder MPUs (microprocessor units = Mikroprozessoreinheiten) sind üblich. Der Prozessor 12 kann typischerweise mit einer Bussteuerung 14 gekoppelt sein, wie z. B. einem Northbridge-Chip durch einen Bus 13, wie z. B. einen FSB (FSB = Front-Side-Bus). Die Bussteuerung 14 kann typischerweise eine Schnittstelle bereitstellen für einen Lese-Schreib-Systemspeicher 16, wie z. B. RAM (RAM = random access memory = Direktzugriffsspeicher).
Bei dem gewöhnlichen Betrieb kann die CPU 12 Computeranweisungen (auch als Computeranweisungscode bezeichnet, in 1 nicht gezeigt) von dem Systemspeicher 16 abrufen. Die CPU kann dann die abgerufenen Computeranweisungen interpretieren und arbeiten, um die Anweisungen zu interpretieren und dadurch den Betrieb des Elektronikgeräts 10 zu steuern. Eine solche Verwendung von CPU-, Systemspeicher- und Computeranweisungen, die typischerweise Betriebssystemcodes und andere Software umfassen, sind auf dem Gebiet des Computerwesens gut bekannt.
Die Bussteuerung 14 kann auch mit einem Systembus 18 gekoppelt sein, beispielsweise einer DMI (DMI = direct media interface = Direktmedienschnittstelle) in typischen Intel^®-artigen Ausführungsbeispielen. Mit der DMI 18 kann ein so genannter Southbridge-Chip gekoppelt sein, wie z. B. ein Intel^® ICH8-Chip 24 (ICH8 = input/output controller hub type 8 = Eingabe-/Ausgabesteuerungs-Hub-Typ-8).
Bei einem typischen Ausführungsbeispiel kann der Southbridge-Chip 24 mit einem PCI-Bus (PCI = peripheral component interconnect = Peripheriekomponentenverbindung) 22 verbunden sein, der wiederum mit einem Plattenspeicher-Teilsystem 66 verbunden sein kann, das verschiedene Dateisysteme bereitstellen kann, die bei Ausführungsbeispielen der Erfindung verwendet werden. Dies beendet die Erörterung von 1.
Die HyperSpace^TM-Familie von Produkten der Phoenix Technologies^® Ltd. ermöglicht die Bereitstellung mehrerer Betriebssystemprogrammprodukte auf einem einzigen Computer auf verschiedene Weisen. Das HyperSpace^TM-Produkt gibt es in verschiedenen Varianten, hauptsächlich unter Verwendung von Techniken wie Dual Boot (duales Hochfahren), Dual Resume (duales Wiederaufnehmen) oder Virtual Machines (virtuelle Maschinen) – die letztere erfordert Hardwareunterstützung, die weit entfernt ist von dem, was sich normalerweise in heutigen Laptopcomputerprodukten findet. Die Dual-Boot-Version des HyperSpace^TM-Produkts ermöglicht kein gleichzeitiges Laden, aber erfordert stattdessen, dass ein erstes Betriebssystem abgeschaltet ist, bevor ein zweites Betriebssystem geladen wird und es demselben erlaubt wird, den PC zu steuern.
Die Dual-Resume-Version des HyperSpace^TM-Produkts ermöglicht gleichzeitiges Laden, wie es durch HyperSpace^TM-Produkt angewiesen wird, von einem ersten und einem zweiten Betriebssystem, beispielsweise einem gestrafften (steramlined) Linux^®-artigen Betriebssystem und einem Closed-Source-Betriebssystem mit vielfältigen Merkmalen, wie z. B. denjenigen der Microsoft^® Corporation. Grundsätzlich werden in der Dual-Resume-Version des HyperSpace^TM-Produkts zwei Betriebssysteme gleichzeitig geladen, aber nur eines wird ausgewählt, um zu einem bestimmten Zeitpunkt auf Nutzerebene aktiv zu sein. Schalten zwischen Betriebssystemen, wie es der Name sagt, umfasst das Bringen eines Betriebssystems in einen Ruhezustand und das „Wiederaufnehmen” (Wiedereinsetzen) des anderen Betriebssystems von seinem früheren Ruhezustand in einen aktiveren Zustand. Somit ist bei dem beschriebenen Ausführungsbeispiel der Erfindung nur ein Betriebssystem auf Anwendungsebene zu einem Zeitpunkt aktiv.
Die Dual-Resume-Version des HyperSpace^TM-Produkts ermöglicht begrenzte gemeinschaftliche Verwendung von Dateien zwischen den beiden betreffenden Betriebssystemen. Die Linuxartige Betriebssystemseite des HyperSpace^TM-Produkts wird allgemein nur als HS bezeichnet (kurz für HyperSpace^TM), und andererseits wird ein ausgewähltes der modernen Betriebssystemprodukte von der Microsoft^® Corporation allgemein als „Windows” bezeichnet, als ein üblicherweise verwendeter allgemeiner Begriff im Computerwesen. Dies ist unabhängig davon, dass Windows^® auch eine anerkannte registrierte Marke der Microsoft^® Corporation ist, und X-Windows vom MIT (Massachusetts Institute of Technology) ein Open-Source-Programmprodukt ist.
Ein Hauptmerkmal der verschiedenen HyperSpace^TM-Firmware-/Softwareprodukte ist selbstverständlich, dass dieselben erlauben, dass Dateisysteme (und somit Dateien) gemeinschaftlich verwendet werden zwischen Windows^® Kontexten und gleichzeitigen HS (Linuxartiges Betriebssystem von HyperSpace^TM) Kontexten. Bei der folgenden Beschreibung bestimmter Ausführungsbeispiele solcher spezifischen Dateisysteme, die implementiert wurden, wie z. B. NTFS, FAT32, Windows PSA, ext3 (usw., die alle in der Technik gut bekannt sind) so gesehen werden, dass sie eine ausführbare Beschreibung beispielhafter Betriebssysteme sind. Die Erfindung ist nicht grundsätzlich auf diese spezifischen beschriebenen Betriebssysteme beschränkt, dieselben werden lediglich als paradigmatische Beispiele verwendet.
Eine auf ein Minimum reduzierte und nur kaum akzeptierbare und rudimentäre Implementierung (geborgt von üblichen Linux^® Verteilungen) würde die Verwendung eines unmodifizierten NTFS-3g-Treibers (NTFS-3g = new technology file system, third generation = Neue-Technologie-Dateisystem, dritte Generation) ausnutzen, um Speicherdatenträger bzw. -volumen, die als C:, D:, etc. bezeichnet werden, von einem Hyper-Space^TM-Kontext aus einzuhängen (mount) und auf dieselben zuzugreifen. Unter Verwendung einer Dual-Boot-Technik ist eine Implementierung dieses Typs, die einen scheren Nur-Lese-Zugriff (von einem Linuxartigen Betriebssystem) auf Dateisysteme erlaubt, die durch Windows erzeugt (und erhalten) werden, kaum akzeptabel. In einem Dual-Resume-Produkt ist eine solche Beschränkung für die meisten Nutzer höchstwahrscheinlich vollständig inakzeptabel.
Allgemein wird das Schreiben in Dateisysteme unterstützt durch den NTFS-3g-Treiber, aber ohne weitere Vorsichts- und Hilfsmaßnahmen könnte das Verwenden dieses Merkmals höchstwahrscheinlich zu Problemen führen (und wird dies auch wahrscheinlich tun), die sich von der unvollständigen Implementierung durch NTFS-3g von hochentwickelten Merkmalen, wie z. B. MS NTFS VSS (der Volume-Snapshot-Dienst von NTFS der Microsoft^® Inc.) und Datenjournalführungsmerkmalen. MS NTFS VSS ist in der Technik gut bekannt.
Eine Möglichkeit, die obigen Schwierigkeiten zu lösen, kann das Beschränken von Lese-Schreib-Zugriff innerhalb von NTFS-3g umfassen, um vollen Lese-Schreib-Zugriff auf nur einen begrenzten Teilsatz des entsprechenden Datenträgers bereitzustellen. Dies begrenzt den Umfang für Komplikationen, während es das Bereitstellen von vollem NTFS-3g-Zugriff auf die Dateien ermöglicht, die höchstwahrscheinlich diejenigen sind, für die Lese-Schreib-Zugriff für den Nutzer wertvoll ist. Das Begrenzen des Umfangs auf diese Weise ermöglicht es, dass Software bei einem Minimum gehalten wird, womit das Risiko, übermäßige Ressourcen zu verbrauchen, vermieden wird.
Bei einem Ausführungsbeispiel ist Lese-Schreib-Zugriff auf Windows^®-Dateien von der HS-Seite (die eine Variante von Linux^® betreibt) auf einen kleinen gesteuerten Teil des Dateisystems begrenzt. Bei einem bestimmten Ausführungsbeispiel ist Lese-Schreib-Zugriff auf den „Meine-Dokumente-Ordner” ermöglicht. „Meine-Dokumente-Ordner” ist ein übliches und gut bekanntes Merkmal von Microsoft^® Softwareprodukten.
Nur-Lese-Zugriff kann allgemein für alle Dateien bereitgestellt werden, ohne Probleme zu verursachen; es kann jedoch sein, dass Schritte durchgeführt werden müssen, um sicherzustellen, dass das Dateisystem eines ersten Betriebssystems in einen ordnungsgemäßen Zustand gebracht wird, wenn die Steuerung zu einem zweiten Betriebssystem übertragen wird. Die beschriebenen Implementierungen verringern Probleme im Zusammenhang mit denn Zugreifen auf ein Dateisystem (insbesondere ein NTFS) von einem Betriebssystem, während das andere Betriebssystem angehalten wurde, das aber trotzdem auf einer Anwendungsebene eine anstehende Aktion aufweist. Diese Effekte sind für einen Durchschnittsfachmann auf diesem Gebiet offensichtlich.
Somit sind bei dem beispielhaften HyperSpace^TM Dual-Resume-Programmprodukt die Probleme der gemeinschaftlichen Verwendung von Dateien eine Herausforderung. Es ergeben sich Situationen, in denen Windows und HS beide aktiviert sind, auch wenn sie keine Anwendungsebenenprogramme abwechselnd anstatt gleichzeitig ausführen. Dies kann beispielsweise auftreten, wenn ein Betriebssystem einen ACPI-Zustand S0 sieht (ACPI = advanced configuration and power interface = hochentwickelte Konfigurations- und Leistungsschnittstelle) und die andere sich selbst als ausgesetzt in Zustand S3 ansieht. Auf diese Weise können beide ein Windows-eigenes NTFS-Dateisystem gleichzeitig eingehängt haben, auch wenn eines der eingehängten Betriebssysteme effektiv ausgesetzt ist. Ohne spezielle Maßnahmen durchzuführen, um Einheitlichkeit sicherzustellen, entsteht das Risiko, dass veraltete Daten und/oder ein verfälschtes Windows-Dateisystem gelesen werden, beispielsweise wenn es Schreibvorgänge zu NTFS von HS während Perioden gibt, in denen Windows^® ausgesetzt ist.
Insbesondere die folgenden Probleme sind hervorstechend und werden bei Ausführungsbeispielen der Erfindung vollständig oder zum großen Teil gelöst:

(A) Eine „On-Disk”-Version einer Datei in einem Dateisystem oder Datenträger kann sich von einer „nach nicht gespeicherten” oder zwischengespeicherten Version der gleichen Datei unterscheiden. Dies ist ein verzweigtes Problem – ein oder alle Betriebssysteme können die Datei oder das Dateisystem Datenträger besitzen und steuern und können somit ein Problem verursachen, das das andere Betriebssystem lösen muss.
(B) Ein NTFS-3g Treiber kann sich weigern, einen NTFS-Datenträger einzuhängen, der nicht ordnungsgemäß ausgehängt (unmounted) wurde.
(C) Mit einem HS-Dual-Resume-Typ-Produkt können Windowsdateien offen bleiben zum Bearbeiten zu einem Zeitpunkt des Schaltens des Kontexts zu HS.
(D) Windows-basierte NTFS-Implementierungen können verbesserte Funktionalität umfassen, die der NTFS-3g nicht hat, insbesondere:
(I) Wiederherstellungspunkte und VSS; (II) Dateiindexieren; (III) Verwenden von Filtertreibern durch AV (audiovisuelle) Pakete; und (IV) Sicherung mit Wiederherstellungsfähigkeiten.

Mit Bezugnahme auf 2 wird bei einem Ausführungsbeispiel der Erfindung, beginnend bei Bezugszeichen 200, in einem Kontext eines Betriebssystems, beispielsweise eines Linux^®-basierten HS, eine Anzahl von Schritten durchgeführt. Bei Bezugszeichen 210 hängt HS ein Dateisystem unter Verwendung von NTFS-3g in einem Nur-Lese-Modus ein. Dies kann Zugriff von HS für ein oder mehrere (eines oder alle) Windows-basierte Dateisysteme in dem Datenträger bereitstellen, die ausgewählt sind, um durch das NTFS-3g-Softwareteilsystem eingehängt zu werden. Außerdem kann das Windows-Betriebssystem auf herkömmliche Weise auf verschiedene Dateisysteme schreiben, unbeeinträchtigt durch (in der Tat in Unkenntnis über) das Vorliegen eines aktiven HyperSpace^TM-Kontexts und -Betriebssystems in dem Computersystem.
Bei dem Bezugszeichen 230 werden alle Daten, die von HS-Anwendungen auf Dateien in jedem NTFS geschrieben werden, das zu Windows^® gehört, in ein virtuelles Schattenbetriebssystem (Shadow Virtual FS) geschrieben, das durch HS gesteuert wird und demselben gehört. Datenträger-(Platten-)Zuordnung von Raum für das virtuelle Schattendateisystem kann von innerhalb eines Dateisystems bereitgestellt werden, das dem HS eigen ist.
Bei dem Bezugszeichen 240 können Schreibvorgänge von innerhalb des HS zu dem virtuellen Schattendateisystem auch in eine Journaldatei protokolliert werden. Das Journal kann auf Platte synchronisiert werden (Cache für IDE (integrierte Antriebselektronik)-Platte), beispielweise bei jedem Schreibvorgang oder beispielsweise regelmäßig nach Vorgabe alle paar Sekunden oder gemäß vergleichbaren Kriterien. Die Journaldatei kann auch implementiert werden in einen zweckgebundenen Datenbereich auf einem Datenträger, und auf die Journaldatei kann auch von Systemprogrammen zugegriffen werden, die in einem Windows^®-Betriebssystem oder -Kontext arbeiten. Beispielsweise kann ein FAT32-(32-Bit-Dateizuordnungstabelle-)Dateisystem in einer zweckgebundenen erweiterten Plattenpartition verwendet werden, oder ein proprietärer formatierter Journalbereich kann auf einer versteckten, unbewegten zusammenhängenden Windows^®-Arbeitsdatei implementiert werden.
Bei dem Bezugszeichen 250 wird eine Leseanforderung empfangen, um in einem HS-Kontext abgearbeitet zu werden, dies bewirkt, dass eine Prüfung an dem virtuellen Schatten-Dateisystem durchgeführt wird, um zu bestimmen, ob die angeforderten Daten bereits darin angeordnet sind. Falls nicht, dann ist die Datenleseanforderung für eine angeforderte Datei, die sich nicht in dem virtuellen Schatten-Dateisystem befindet, oder die angeforderte Datei wird gefunden, aber die bestimmte Aufzeichnung wird nicht gefunden. Falls die Anforderung durch Lesen des Schatten-Dateisystems abgearbeitet werden kann, dann wird bei dem Bezugszeichen 260 dieser Lesevorgang durchgeführt. Andernfalls wird bei dem Bezugszeichen 270 das Nur-Lese-NTFS gelesen und die Datei und die Daten werden von dort lokalisiert.
Bei dem Bezugszeichen 280 gibt es einen Wechsel weg von dem HS-Kontext, und bei dem Bezugszeichen 290 wird die Ausführung in einem Windowskontext fortfahren, in 3.
Mit Bezugnahme auf 3 ist das Bezugszeichen 300 der Beginn einer Wiederaufnahme der Ausführung in einem Windowskontext (oder auf einen Neustart einer Microsoft^® Windows^® Ressourcenpartition hin).
Bei 310 kann ein Windowsdienst (typischerweise in der Form eines Anwendungsdämons) die Journaldatei, die unter HS erzeugt wurde, wie oben beschrieben, auf Übereinstimmung prüfen (validieren).
Bei dem Bezugszeichen 320 kann ein Filter-(Plug-in-)Programm, das vorher in eine Windowsanwendung installiert wurde (wie z. B. das Explorerprogramm) und/oder ein vorher installierter FS-Filtertreiber angeforderte Zugriffe von Windowsprozessen auf bestimmte Dateien fernhalten (d. h. verschieben oder verzögern). Betroffene Dateien sind die Dateien, die derzeit einer Modifizierung unterzogen werden durch Anlegen der Journaldatei. Der Zugriff wird ferngehalten bis zu dem Zeitpunkt, nachdem das HS-Schreibjournal gemischt bzw. zusammengeführt und vollständig angewendet wurde (wie es nachfolgend beschrieben wird).
Bei dem Bezugszeichen 325 kann der Dienst dann das Journal an die NTFS-Datei(en) anwenden und kann dann bei dem Bezugszeichen 330 die Journalkontexte löschen (wie z. B. durch Schreiben von Daten von nur Nullen), und kann bei dem Bezugszeichen 340 das virtuelle Schatten-Dateisystem als leer markieren (oder als anderweitig ungeeignet, da es nicht mehr eine Journaldatei enthält, die angewendet werden sollte). Dieses Anlegen einer Journaldatei bedeutet im Wesentlichen ein Nachhholen bzw. Nachtragen einer Schattenkopie und stellt sicher, dass spätere Zugriffe (wie z. B. von innerhalb von Windows, die von der Schattenbildung nichts wissen) nur gültige und frische (d. h. nicht veraltete) Daten empfangen.
Bei dem Bezugszeichen 350 wird das Fernhalten oder Verzögern von Zugriffen, das bei Schritt 320 auferlegt wurde, aufgehoben. Dies ermöglicht es anstehenden Übertragungen in dem wieder aufgenommenen Betriebssystemkontext, fortzufahren, und jeder Stau, der sich gebildet haben kann, wird abgewickelt. Bei dem Bezugszeichen 390 wird die Sequenz von Schritten abgeschlossen.
4 ist ein Diagramm, das Beziehungen zwischen den Softwarekomponenten eines Ausführungsbeispiels der Erfindung zeigt. Auf einer niedrigen Ebene und unter Verwendung von BIOS-Unterstützung gibt es eine HyperSpace^TM Dual-Resume-Unterstützung durch ACPI 490. Darüber hinaus gibt es zwei Betriebssystemkontexte, einen Windows^®-Betriebssystemkontext 400 und HyperSpace^TM-Betriebssystemkontext 450.
Der Windows^®-Betriebssystemkontext 400 ist unterteilt in Komponenten, die entweder als GUI (graphische Nutzerschnittstelle) oder als Dämonanwendungen 410 laufen, und alternativ Programme, die als Plug-Ins funktionieren, insbesondere Dateisystem-Dateifilter.
Der HyperSpace^TM-Betriebssystemkontext 450 ist unterteilt in Nutzerraum 455 und Betriebssystemkern-Raum 470.
Die verschiedenen Softwarekomponenten, die ein Ausführungsbeispiel der Erfindung bilden, werden nun mit Bezugnahme auf 4 beschrieben. Der Entwurf auf der Windowsseite 400 besteht aus mehreren Komponenten: (A) NTFS-Dateifilter 440 (B) FS-Übergangsverwalter 420 und (C) FAT-Dateifilter 450.
Das NTFS-Dateifilter 440 ist ein Dateisystemtreiber, der sich während des Hochfahrens an dem Windowsdateisystemstapel anhängt und alle Aufrufe in den FS-Treiber des Windows Betriebssystems überwacht. Er spielt eine bedeutende Rolle bei der Unterstützung des FS-Übergangsverwalters bei der gemeinschaftlichen Verwendung von Dateien.
Während eines Schaltens von Windows zu HS räumt der NTFS-Dateifilter 440 den Plattenzwischenspeicher (disk cache), auf die Benachrichtigung von dem FS-Übergangsverwalter 420 hin. Dann blockiert der NTFS-Dateifilter 440 alle FS-I/Os (Eingabe-/Ausgabeoperationen), so dass dieselben das Dateisystem nicht erreichen, durch Bilden einer Warteschlage der IRPs (I/O Anforderungspakete) basierend auf Dateikennungen. Das Blockieren wird begonnen und beendet ansprechend auf eine Benachrichtigung von dem FS-Übergangsverwalter 420. Das Dateifilter blockiert nur Lese- und -Schreib-IRPs, erlaubt aber andere IRPs, wie z. B. PNP IRP (Plug-n-Plag IRP), Power IRP, WMI IRP (Windows management instrumentation IRP).
Das NTFS-Dateifilter 440 spielt eine bedeutende Rolle beim Implementieren eines OpLock-Merkmals, das Dateien auferlegt wird, die zwischen den zwei Betriebssystemen gemeinschaftlich verwendet werden. Ein OpLock implementiert mehrere Leser- und einen Schreibermechanismus. OpLock stellt die Integrität von Daten in den Fallen sicher, wo eine Datei, die in einem Betriebssystem geöffnet ist, zur Bearbeitung in einem anderen Betriebssystem geöffnet wird. Wenn eine Anwendung das Öffnen einer Datei in der gemeinschaftlich verwendeten Partition anfordert, verfolgt das NTFS-Dateifilter 440 IRPs und versucht, die Datei in einer Protokolldatei nachzuschlagen. Falls es keinen Eintrag für die angeforderte Datei gibt, wird die Anforderung erlaubt. Aber falls es einen Eintrag gibt, dann wird die Anforderung der jeweiligen Anwendung, die Datei zu öffnen, verweigert. Diese Technik ermöglicht es, dass Dateisysteme über Betriebssysteme gemeinschaftlich verwendet werden auf eine ordnungsgemäße Weise, während die Dateiverriegelung in einer herkömmlichen Situation nach wie vor berücksichtigt wird, bei der zwei Anwendungen versuchen, dieselbe aktuelle Datei (nicht nur das gleiche Dateisystem) gleichzeitig zu aktualisieren.
Bei einem Ausführungsbeispiel wird die Protokolldatei implementiert unter Verwendung eines UnionFS-Filtertreibers 482 (in HS), der jedes Mal einen Eintrag in die Protokolldatei schreibt (oder aktualisiert), wenn eine Anwendung, die in HS (d. h. in Dom0) ausführt, eine Dateikennung öffnet. UnionFS ist ein Merkmal, das in Linux^® popularisiert und in der Technik gut bekannt ist. Der relevante Protokolleintrag wird von der Protokolldatei gelöscht, wenn alle Referenzen auf die Dateikennung geschlossen sind. Nur der UnionFS-Treiber (auf der HS-Seite) aktualisiert das Protokoll und den anderen Bereich (der typischerweise Windows ausführt), den das jeweilige NTFS-Dateifilter lediglich liest (d. h. demselben wurde Nur-Lese-Zugriff gewährt).
Ähnlich dazu, als eine logische Folge, protokolliert das NTFS-Dateifilter 440 auch alle offenen Dateieinträge in einer zweiten Protokolldatei. Diese Protokolldatei wird durch das UnionFS-Filter 482 verwendet zum Nachschlagen, das es einer Anwendung in HS erlaubt, die Datei zum Bearbeiten zu öffnen. Somit wirkt bei einem Ausführungsbeispiel das Vorliegen eines jeweiligen Eintrags in dem zweiten Protokoll, um zu verhindern, dass die Datei in HS geöffnet wird.
Da ein Datenabnehmer (logger) verwendet wird, um ein OpLock zu implementieren (viele Leser, ein Schreiber sind erlaubt), dann blockieren oder protokollieren die jeweiligen Datenabnehmer auf den zwei Betriebssystemen die Dateieinzelheiten in keiner der Situationen, in der eine Anwendung eine Datei für Nur-Lese-Zugriff öffnet. Darüber hinaus ist eine wünschenswerte Konsequenz davon, zwei getrennte Datenabnehmer zu haben, dass dies verhindert, dass beide Betriebssysteme die gleiche Partition (für die ein Protokoll vorliegt) in einem RW-Modus (Lese-Schreib-Modus) einhängen. Somit kann die „Windowsprotokolldatei” in einem gemeinschaftlich verwendeten Datenträger vorliegen, das ein Windowsdateitreiber lesen kann, wird aber von dem HS nur gelesen. Umgekehrt liegt das HS-Protokoll in dem Schattendatenträger vor, den HS aktualisieren oder bearbeiten kann, das für den anderen Bereich (typischerweise die Windowsseite) als Nur-Lese-Datenträger oder Dateisystem gesehen wird.
Der FS-Übergangsverwalter 420 ist eine Windowsanwendung und ein Dienst, der im Hintergrund läuft. Die Dienstanwendung startet die Windowsanwendung, die dem Nutzer Pop-Up-Mitteilungen gibt. Dienstanwendungen sind typischerweise nicht entworfen, um auf die GDI-Funktion (GDI = graphical display interface) zuzugreifen, und jeder Versuch, dies direkt zu tun, würde während der Ausführung wahrscheinlich scheitern. Dienstanwendungen hören auf Nachrichten von dem SCM (SCM = service control manager = Dienststeuerverwalter; eine gut bekannte Windowskomponente) und auch auf Standby- und Wiederaufnahme-Benachrichtigungsereignisse.
Der FS-Übergangsverwalter 420 ist eine Schlüsselkomponente, die eine Anzahl von Rollen durchführt: (A) Startet selbst während der Anmelde-Phase. Es hängt die Windows PSA Partition (PSA = packaged system area) ein und versteckt dieselbe von der Nutzerebene. (B) Jedes Mal, wenn Windows aktiv ist, hört der FS Übergangsverwalter 420 auf den Auslöser, um den ACPI-Systemzustand zu ändern, und benachrichtigt auf den Empfang hin das NTFS-Dateifilter 440, den Plattenzwischenspeicher zu räumen und I/Os vorübergebend zu sperren. (C) Jedes Mal, wenn Windows wieder aufnimmt von Standby, hört die Anwendung die Aufwachbenachrichtigung und auf den Empfang bin führt dieselbe eine Kopie durch von dem Schattendatenträger zu der gemeinschaftlich verwendeten Datenträgerpartition. Sobald die Kopie abgeschlossen ist, benachrichtigt dieselbe den Filtertreiber, die anstehenden IRPs nicht mehr zu blockieren. (D) FS-Übergangsverwalter 420 hängt auch den Windows-PSA-Datenträger ein auf die Wiederaufnahme von Standby hin. Bei einem Ausführungsbeispiel der Erfindung ist der Schattendatenträger in dem Windows-PSA.
Das FAT32-Dateifilter 450 ist ein Filtertreiber, der im Stapel des FAT32-Dateisystems sitzt. FAT32 ist in der Technik gut bekannt. Bei diesem Entwurf wird Windows-PSA als die Schattenpartition verwendet und ist eine FAT32-Partition. Der FS-Übergangsverwalter 420 hängt die Partition ein und führt eine angeforderte Kopieroperation durch. Sobald dieselbe eingehängt ist, macht Windows die Partition für den Nutzer verfügbar und der Nutzer kann sie nach Bedarf nutzen. Um alle solche (potentiell problematischen) Operationen auf dem Windows-PSA zu vermeiden, blockiert das FAT32-Dateifilter 450 vom Entwurf her I/O, die an das Windows-PSA adressiert sind.
Mit Bezugnahme auf den Entwurf auf der HyperSpace^TM-Seite 450 befinden sich in dem Nutzerraum 455 mehrere Komponenten: (D) HS-Übergangsverwalter 460, (E) HS-Übergangsverwalter UI (Nutzerschnittstelle) 465, und (F) Skript-Unterstützung 470. In dem Betriebssystemkern-Raum 470 liegen Dateifilter, VFS 480 (virtuelles Dateisystem) und UnionFS 482. Diese Dateifilter arbeiten mit FS (Dateisystemen) verschiedener Typen, „ext3” 484 (das Standards Linux^® Dateisystem), NTFS 486 und FAT32 488.
Der HS-Übergangsverwalter 460 verwaltet gesteuerte I/O zu NTFS-RO(Nur-Lese-)Partitionen. Jedes Mal, wenn es eine Transaktion gibt, die das Aktualisieren der Platte nicht erfordert, d. h. jede RO-Operation, liest der HS-Übergangsverwalter 460 die Datei von der geeigneten NTFS-Partition und öffnet dieselbe in einem RO-Modus. Wenn irgendeine Transaktion das Aktualisieren der Platte erfordert, dann öffnet der HS-Übergangsverwalter 460 die Datei von der NTFS-Partition in dem RO-Modus, aber in diesem Fall wird die I/O-Übertragung (Schreiben oder Neuschreiben) an den Schattendatenträger gerichtet, der in einem RW-Modus eingehängt ist, anstatt dass der I/O-Transfer direkt zu der NTFS-Partition selbst gerichtet wird.
Bei einem Ausführungsbeispiel der Erfindung kann das HS-Dateifiltermodul Teil des Dateifilters für VFS 480 sein, das zusammen mit dem UnionFS 482 wirkt. Das UnionFS 482 ist ein Dateisystemtyp, der für das Mischen der zwei Einhängpunkte sorgt und Schreiben von I/O auf Schattendatenträger 488 durchführt, auch wenn der Anwendung in dem Nutzerraum eine Ansicht geliefert wird, dass das Schreiben von I/O direkt zu einer NTFS-Partition stattgefunden hat. Die Verwendung eines UnionFS stellt bereit, dass eine Leseoperation die Daten ordnungsgemäß abruft, insbesondere von den bearbeiteten Daten auf dem Schattendatenträger (anstatt der ursprünglichen und unveränderten Daten) jedes Mal, wenn diese Daten durch eine kürzliche Schreiboperation verändert wurden.
Das Dateifilter für VFS 480 stellt allgemeinen Dateizugriff bereit, wie z. B. direkt auf ext3 484 und NTFS 486, zusätzlich zum Bereitstellen der HS-Dateifiltermodulfähigkeit.
Der HS-Übergangsverwalter 460 liest die Informationen über den Zustand der Datei, die geöffnet ist für das Schreiben von I/O von einer Metadatendatei (in 4 nicht gezeigt). Die Metadatendatei kann als ein Merkmal der Protokolldatei implementiert sein, die oben beschrieben ist, oder könnte getrennt erzeugt und erhalten werden. Die Metadatendatei existiert in der NTFS-Partition, die in dem RO-Modus eingehängt ist. Der NTFS-Dateifilter (in Windows) aktualisiert diese Metadatendatei mit Informationen über jede zugehörige (potentiell gemeinschaftlich verwendbare) Datei, die im Windows bearbeitet oder aktualisiert wird. Einige Dateien, wie z. B. Windowssystemsdateien, können absichtlich ausgeschlossen werden und bleiben daher für die HS-Anwendungsseite unbekannt.
Die Informationen, die in der Metadatendatei enthalten sind, umfassen Dateiname, Position in der NTFS-Partition, aktuellen Zustand, Anzahl von Dateibeschreiberreferenzen und mehr. Falls eine Datei in einem Schreiben-erlaubenden Modus in HS geöffnet ist, und falls der HS-Übergangsverwalter 460 von der Metadatendatei herausfindet, dass diese Datei in einem Zustand „geöffnet in Windows zum Bearbeiten” ist, dann signalisiert der HS-Übergangsverwalter 460 dem HS-Übergangsverwalter der UI 465, eine entsprechende Mitteilung anzuzeigen und das Öffnen der Datei wird nicht erlaubt.
Gleichartig dazu behält der HS-Übergangsverwalter 460 eine Metadatendatei in dem Schattendatenträger bei. Die Struktur darin ist ähnlich der Metadatendatei, die in der NTFS-Partition existiert, die durch Windows aktualisiert wird. Der HS-Übergangsverwalter 460 aktualisiert diese Metadatendatei jedes Mal, wenn eine Anforderung von einer HS-Anwendung ankommt zum Öffnen einer Datei zum Schreiben, die zu der NTFS-Partition gehört und die nicht bereits in Windows bearbeitet wird. Falls die Datei, die in HS bearbeitet wird, geschlossen wird vor dem Schalten von Kontext zu Windows, dann wird der Eintrag für diese Datei von der Metadatendatei entfernt. Somit wird Windows angezeigt, dass es diese Datei zum Bearbeiten öffnen kann. Zusammen mit Metadaten wird die tatsächliche Datei selbst im Schattendatenträger gespeichert. Jedes Mal, wenn Kontext zu Windows geschaltet wird, wird diese Datei durch Windows zu der tatsächlichen Position auf der NTFS-Partition kopiert. Diese Situation könnte insbesondere gelten, wenn eine neue Datei in einem HS-Kontext erzeugt wird und der Windowsseite verfügbar gemacht werden soll. Dies kann auch äquivalent sein (oder als äquivalent angesehen werden) zu einer Situation, in der ein Journal einfach die gesamte Datei ist, wobei es ein Implementierungsdetail ist, wie dies auszuführen ist.
Das HS-Dateifilter wird durch einen Linux-artige UnionFS 482 Treiber implementiert. UnionFS ist ein Dateisystemtyp, der zwischen VFS und einem NTFS-3g-Treiber sitzt.
UnionFS ist in der Technik gut bekannt. Funktional ist ein UnionFS 482 gleichzeitig auf mehrere Dateisysteme 484, 486, 488 geschichtet oder manchmal auf mehrere Verzeichnisse in einem einzigen Dateisystem. UnionFS 482 überlagert mehrere Verzeichnisse in einen einzigen Einhängungspunkt. Er versucht erst, auf die Datei auf einer oberen Verzweigung zuzugreifen und falls dies nicht erfolgreich ist, fährt er auf Verzweigungen unterer Ebene fort. Falls der Nutzer versucht, eine Datei auf einer Verzweigung unterer Ebene zu modifizieren, die RO ist, dann wird die Datei zu einer Lese-Schreib-Verzweigung höherer Ebene kopiert. UnionFS 482 präsentiert eine Dateisystemschnittstelle zu dem Betriebssystemkern, und UnionFS selbst wiederum präsentiert sich als das VFS des Betriebssystemkerns für die Dateisysteme, auf die derselbe gestapelt ist. Da UnionFS dem Betriebssystemkern eine Dateisystemansicht präsentiert, kann derselbe durch Anwendungen auf Nutzerebene verwendet werden. UnionFS fängt Operationen ab, die für Dateisysteme niedrigerer Ebene beabsichtigt sind, und kann somit Operationen modifizieren, um eine einheitliche Ansicht zu präsentieren.
Bei Ausführungsbeispielen der Erfindung können die zwei Dateisysteme NTFS (Nur-Lese) und FAT32-Schattendatenträger (Lese-Schreiben) sein. Nutzern (Nutzermodusanwendungen) wird kein Zugriff auf das Schattendatenträger erlaubt, aber als eine Ausnahme ist dies dem HS-Übergangsverwalter 460 erlaubt. Der FAT32-Schattendatenträger 488 kann verwendet werden, um die Metadatendatei beizubehalten und neue Dateien, die in der NTFS-Partition 486 erzeugt werden sollen.
Der HS-Übergangsverwalter 460 könnte entweder (A) implementiert werden als ein UnionFS-FUSE-Treiber (UnionFS-Dateisystem im Nutzerraum) oder alternativ als ein UnionFS-Betriebssystemkern-Raum-Dateisystemtreiber. Der UnionFS-FUSE-Treiber ist in 4 nicht gezeigt, aber in der Technik gut bekannt.
Skriptunterstützung 468 stellt Startup-Skripte bereit, die kundenspezifisch angepasst werden, um ein UnionFS-Betriebssystemkernmodul zu laden. Falls UnionFS-FUSE verwendet wurde, müssen Skripte ein FUSE-Betriebssystemkernmodul laden und UnionFS-FUSE aufrufen. Und dann (unabhängig davon, ob UnionFS-FUSE verwendet oder nicht) starten dieselben den HS-Übergangsverwalter-Dämon 460 und die HS-Übergangsverwalter-UI 465.
Mit Bezugnahme auf 5 können Computeranweisungen, die in ein Elektronikgerät 10 aufgenommen werden sollen, verteilt werden als gefertigte Firmware und/oder Softwarecomputerprodukte 510 die eine Vielzahl möglicher Medien 530 verwenden, auf denen die Anweisungen aufgezeichnet sind, wie z. B. durch Verwenden einer Speicheraufzeichnungsvorrichtung 520. In Produkten, die so komplex sind wie diejenigen, die die Erfindung verwenden, kann häufig mehr als ein Medium verwendet werden, sowohl bei der Verteilung als auch bei der Herstellung des relevanten Produkts. Aus Übersichtlichkeitsgründen ist in 5 nur ein Medium gezeigt, aber mehr als ein Medium kann verwendet werden und ein einzelnes Computerprodukt kann zwischen einer Mehrzahl von Medien verteilt sein.
6 zeigt, wie ein beispielhaftes Ausführungsbeispiel der Erfindung codiert, gesendet, empfangen und decodiert werden kann unter Verwendung elektromagnetischer Wellen.
Mit Bezugnahme auf 6 können außerdem, und insbesondere seit dem Anstieg der Internetnutzung, Computerprodukte 610 verteilt werden durch Codieren derselben in Signale, die als eine Welle moduliert werden. Die resultierenden Signalverläufe können dann durch einen Sender 640 gesendet werden, als greifbare modulierte elektromagnetische Trägerwellen 650 ausgebreitet werden und durch einen Empfänger 660 empfangen werden. Auf dem Empfang hin können dieselben demoduliert werden, und das Signal kann in eine weitere Version oder Kopie des Computerprodukts 611 decodiert werden in einem Speicher oder einer anderen Speichervorrichtung, die Teil eines zweiten Elektronikgeräts 11 ist und typischerweise von der Art her ähnlich ist wie das Elektronikgerät 10.
Andere Topologien und/oder Vorrichtungen könnten auch verwendet werden, um alternative Ausführungsbeispiele der Erfindung aufzubauen. Die oben beschriebenen Ausführungsbeispiele sind beispielhaft und nicht begrenzend, und die Grenzen der Erfindung sollten von den Ansprüchen her bestimmt werden. Obwohl bevorzugte Ausführungsbeispiele der vorliegenden Erfindung hierin oben näher beschrieben wurden, sollte klar sein, dass viele Variationen und/oder Modifikationen der hierin gelehrten grundlegenden erfindungsgemäßen Konzepte, die für Fachleute auf diesem Gebiet offensichtlich werden, immer noch in die Wesensart und den Schutzbereich der vorliegenden Erfindung fallen, wie er in den angehängten Ansprüchen definiert ist.

Claims

Ein Verfahren zum Betreiben eines Computers, das folgende Schritte aufweist: Laden eines ersten Betriebssystems in einen Speicher; Laden eines zweiten Betriebssystems in den Speicher; Einhängen eines ersten Dateisystems, das durch das zweite Betriebssystem gesteuert wird; Einhängen des ersten Dateisystems für Nur-Lese-Zugriff durch das erste Betriebssystem; Umleiten einer Mehrzahl von Daten, die von einem Anwendungsprogramm geschrieben werden, das durch das erste Betriebssystem gesteuert wird, zu einem Journal, das durch das erste Betriebssystem gesteuert wird; Wiederaufnehmen der Ausführung des zweiten Betriebssystems und Anlegen des Journals an das erste Dateisystem im Kontext des zweiten Betriebssystems.
Das Verfahren gemäß Anspruch 1, bei dem: das erste Dateisystem ein NTFS (NTFS = New Technology File System = Neue-Technologie-Dateisystem) ist.
Das Verfahren gemäß Anspruch 1, bei dem: das Wiederaufnehmen einer ACPI-Statusänderung (ACPI = Advanced Configuration and Power Interface = Hockentwickelte Konfigurations- und Leistungsschnittstelle) entspricht.
Das Verfahren gemäß Anspruch 1, bei dem: das Journal in einem virtuellen Schattendateisystem gespeichert ist.
Das Verfahren gemäß Anspruch 1, das ferner folgenden Schritt aufweist: Umleiten, von einer Verbindung des Journals und des ersten Dateisystems, einer Mehrzahl von Daten, die in das Anwendungsprogramm gelesen werden, das durch das erste Betriebssystem gesteuert wird.
Das Verfahren gemäß Anspruch 1, bei dem das Anlegen des Journals an das erste Dateisystem ferner folgenden Schritt aufweist: Durchführen von Übereinstimmungs- oder Validitätsprüfungen an dem Journal im Kontext des zweiten Betriebssystems.
Das Verfahren gemäß Anspruch 1, das ferner folgenden Schritt aufweist: Verzögern einer Transaktion für das erste Betriebssystem in dem Kontext des zweiten Betriebssystems, wodurch der Abschluss des Anlegens des Journals an das erste Dateisystem in dem Kontext des zweiten Betriebssystems unerledigt bleibt.
Das Verfahren gemäß Anspruch 1, bei dem: das Journal in einem zweiten Dateisystem enthalten ist.
Das Verfahren gemäß Anspruch 8, bei dem: das erste Dateisystem vom Typ NTFS ist, und das zweite Dateisystem vom Typ FAT32 (FAT = File Allocation Table = Dateizuordnungstabelle).
Das Verfahren gemäß Anspruch 1, bei dem: ein Kontext kontinuierlich wechselt zwischen einem ersten und einem zweiten Betriebssystem, entsprechend einer Mehrzahl von ACPI-Zustandsänderungen.
Ein Computerprogrammprodukt, das folgende Merkmale aufweist: zumindest ein computerlesbares Medium, auf dem Anweisungen codiert sind, wobei die Anweisungen, wenn diese durch zumindest einen Prozessor ausgeführt werden, bewirken, dass der zumindest eine Prozessor in Schritten arbeitet, die folgende Schritte aufweisen: Laden eines ersten Betriebssystems in einen Speicher; Laden eines zweiten Betriebssystems in den Speicher; Einhängen eines ersten Dateisystems, das durch das zweite Betriebssystem gesteuert wird; Einhängen des ersten Dateisystems für Nur-Lese-Zugriff durch das erste Betriebssystem; Umleiten einer Mehrzahl von Daten, die von einem Anwendungsprogramm geschrieben werden, das durch das erste Betriebssystem gesteuert wird, zu einem Journal, das durch das erste Betriebssystem gesteuert wird; Wiederaufnehmen der Ausführung des zweiten Betriebssystems und Anlegen des Journals an das erste Dateisystem im Kontext des zweiten Betriebssystems.
Das Computerprogrammprodukt gemäß Anspruch 11, bei dem das erste Dateisystem ein NTFS (NTFS = New Technology File System = Neue-Technologie-Dateisystem) ist.
Das Computerprogrammprodukt gemäß Anspruch 11, bei dem: das Journal in einem virtuellen Schattendateisystem gespeichert ist.
Ein Verfahren, das folgende Schritte aufweist: einen Schritt des Modulierens eines Signals auf eine elektromagnetische Trägerwelle, die in ein greifbares Medium eingeprägt ist, oder das Demodulieren des Signals von der elektromagnetischen Trägerwelle, wobei auf dem Signal Anweisungen codiert sind, wobei die Anweisungen, wenn dieselben durch zumindest einen Prozessor ausgeführt werden, bewirken, dass der zumindest eine Prozessor in Schritten arbeitet, die folgende Schritte aufweisen: Laden eines ersten Betriebssystems in einen Speicher; Laden eines zweiten Betriebssystems in den Speicher; Einhängen eines ersten Dateisystems, das durch das zweite Betriebssystem gesteuert wird; Einhängen des ersten Dateisystems für Nur-Lese-Zugriff durch das erste Betriebssystem; Umleiten einer Mehrzahl von Daten, die von einem Anwendungsprogramm geschrieben werden, das durch das erste Betriebssystem gesteuert wird, zu einem Journal, das durch das erste Betriebssystem gesteuert wird; Wiederaufnehmen der Ausführung des zweiten Betriebssystems und Anlegen des Journals an das erste Dateisystem im Kontext des zweiten Betriebssystems.
Das Verfahren gemäß Anspruch 14, bei dem: das erste Dateisystem ein NTFS (NTFS = New Technology File System = Neue-Technologie-Dateisystem) ist.
Das Verfahren gemäß Anspruch 14, bei dem: das Wiederaufnehmen einer ACPI-Statusänderung (ACPI = Advanced Configuration and Power Interface = Hochentwickelte Konfigurations- und Leistungsschnittstelle) entspricht.
Ein Elektronikgerät, das folgende Merkmale aufweist: eine Steuerung; und einen ersten Systemspeicher, auf dem Anweisungen codiert sind, wobei die Anweisungen, wenn dieselben durch die Steuerung ausgeführt werden, bewirken, dass die Steuerung in Schritten arbeitet, die folgende Schritte aufweisen: Laden eines ersten Betriebssystems in einen Speicher; Laden eines zweiten Betriebssystems in den Speicher; Einhängen eines ersten Dateisystems, das durch das zweite Betriebssystem gesteuert wird; Einhängen des ersten Dateisystems für Nur-Lese-Zugriff durch das erste Betriebssystem; Umleiten einer Mehrzahl von Daten, die von einem Anwendungsprogramm geschrieben werden, das durch das erste Betriebssystem gesteuert wird, zu einem Journal, das durch das erste Betriebssystem gesteuert wird; Wiederaufnehmen der Ausführung des zweiten Betriebssystems und Anlegen des Journals an das erste Dateisystem im Kontext des zweiten Betriebssystems.
Das Elektronikgerät gemäß Anspruch 17, bei dem: das erste Dateisystem ein NTFS (NTFS = New Technology File System = Neue-Technologie-Dateisystem) ist.
Das Elektronikgerät gemäß Anspruch 17, bei dem: das Wiederaufnehmen einer ACPI-Statusänderung (ACPI = Advanced Configuration and Power Interface = Hochentwickelte Konfigurations- und Leistungsschnittstelle) entspricht.
Das Elektronikgerät gemäß Anspruch 17, bei dem: das Journal in einem virtuellen Schattendateisystem gespeichert ist.