EP1661042A1 - Organisation eines dateibaums bei einem tragbaren datenträger - Google Patents

Organisation eines dateibaums bei einem tragbaren datenträger

Info

Publication number
EP1661042A1
EP1661042A1 EP04764398A EP04764398A EP1661042A1 EP 1661042 A1 EP1661042 A1 EP 1661042A1 EP 04764398 A EP04764398 A EP 04764398A EP 04764398 A EP04764398 A EP 04764398A EP 1661042 A1 EP1661042 A1 EP 1661042A1
Authority
EP
European Patent Office
Prior art keywords
file
file system
application program
data carrier
tree
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.)
Withdrawn
Application number
EP04764398A
Other languages
English (en)
French (fr)
Inventor
Erich Englbrecht
Robert Hockauf
Thorsten Ulbricht
Rudolf Schubert
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.)
Giesecke+Devrient GmbH
Original Assignee
Giesecke+Devrient GmbH
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 Giesecke+Devrient GmbH filed Critical Giesecke+Devrient GmbH
Publication of EP1661042A1 publication Critical patent/EP1661042A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card
    • G06Q20/35765—Access rights to memory zones

Definitions

  • the invention relates generally to the technical field of file systems and, in particular, to the organization of a file tree in a portable data carrier.
  • At least two file systems configured in different technologies are integrated in the file tree, which at least partially - and in preferred configurations predominantly or completely - for storing at least one application program or for storing user data for the at least one application program serve.
  • the transaction backup provided by the second file system 30 comprises either all data blocks to be written into the second file system 30 or only metadata relating to the structure of the second file system 30. If only metadata is included in the journal, the container file 38 can have partly new and partly old content after the data carrier 10 has been interrupted. In these configurations, additional security measures on the part of the application program 32 and / or the conversion module 40 are therefore required. In contrast, complete transaction protection is achieved in configurations in which the journal logs the entire file content to be changed by a write operation and all the metadata to be changed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Bei einem Verfahren zur Organisation eines Dateibaums (26) bei einem tragbaren Datenträger (10) wird mindestens ein transaktionsbasiertes Dateisystem (30) in den Dateibaum (26) eingebunden. Bei einem weiteren Verfahren werden in den Dateibaum (26) mindestens zwei in unterschiedlichen Technologien ausgestaltete Dateisysteme (28, 30) eingebunden, von denen ein erstes Dateisystem (28) zumindest teilweise zur Speicherung mindestens eines Anwendungsprogramms (32) dient und ein zweites Dateisystem (30) zumindest teilweise zur Speicherung von Nutzdaten (34, 34') für das mindestens eine Anwendungsprogramm (32) dient. Ein tragbarer Datenträger (10) und ein Computerprogrammprodukt weisen entsprechende Merkmale auf. Die Erfindung stellt eine Technik zur Organisation eines Dateibaums (26) bereit, die speziell auf die Gegebenheiten bei tragbaren Datenträgern (10) zugeschnitten ist.

Description

Organisation eines Dateibaums bei einem tragbaren Datenträger
Die Erfindung betrifft allgemein das technische Gebiet der Dateisysteme und insbesondere die Organisation eines Dateibaums bei einem tragbaren Daten- träger.
Ein tragbarer Datenträger im Sinne des vorliegenden Dokuments kann insbesondere eine Chipkarte (smart card in unterschiedlichen Bauformen oder ein Chipmodul oder ein sonstiges ressourcenbeschränktes System sein. Typische Gegebenheiten bei tragbaren Datenträgern sind die erhebliche Beschränkung von Speicherplatz und Rechenleistung sowie die Forderung, daß auch nach einem plötzlichen Ausfall der Versorgungsspannung - z.B. durch Trennen des Datenträgers von einem Terminal - keine Undefinierten Betriebszustände auftreten dürfen.
In einem internen Forschungsprojekt der Giesecke & Devrient GmbH wird gegenwärtig untersucht, inwieweit ein UNIX®-artiges Betriebssystem auf einem heute verfügbaren oder in Zukunft zu erwartenden Datenträger implementiert werden kann. In diesem Zusammenhang ist insbesondere eine Implementierung des unter der Marke Linux® bekannten Betriebssystems vorgesehen. Das Buch "Understanding the Linux Kernel" von D. P. Bovet und M. Cesati, O'Reilly Verlag, 2. Auflage, Dezember 2002, enthält eine detaillierte technische Beschreibung dieses Betriebssystems.
Die bei dem Linux-Betriebssystem üblicherweise eingesetzten Dateibäume, Dateisysteme und Dateisystem-Organisationstechniken sind insbesondere auf den Seiten 12 - 16 sowie in den Kapiteln 12, 15 und 17 des gerade zitierten Buches erläutert. Auf diese Fundstellen wird Bezug genommen. Es ist dort jedoch weder ein Einsatz des Linux-Betriebssystems für tragbare Daten- träger noch eine spezielle Anpassung von Dateisystemen an die Gegebenheiten bei tragbaren Datenträgern offenbart. Die Erfindung hat daher die Auf abe, eine Technik zur Organisation eines Dateibaums bereitzustellen, die speziell auf die Gegebenheiten bei tragbaren Datenträgern zugeschnitten ist. Gemäß einem ersten Aspekt soll die Erfindung insbesondere dazu beitragen, mit geringem Aufwand Undefinierte Be- triebszustände zu verhindern. Gemäß einem zweiten Aspekt soll die Erfindung die technischen Grundlagen für eine besonders speicherplatzsparende und/ oder leistungsfähige Dateiverwaltung in dem tragbaren Datenträger liefern.
Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch ein Verfahren gemäß Anspruch 1 bzw. Anspruch 6, einen tragbaren Datenträger gemäß Anspruch 12 bzw. Anspruch 13 sowie ein Computerprogramnτpro- dukt gemäß Anspruch 14. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen der Erfindung.
Die Erfindung geht von der Grundüberlegung aus, die an sich bekannte Technik des Einbindens von Dateisystemen in einen Dateibaum in einer für tragbare Datenträger besonders vorteilhaften Weise zu nutzen. Unter dem im vorliegenden Dokument verwendeten Begriff "Dateibaum" ist insbesondere jede hierarchische Struktur zu verstehen, die Verzeichnisse und Dateien aufzunehmen vermag. Dies schließt nicht aus, daß im Dateibaum weitere Elemente vorhanden sind, z.B. Querverweise (links) oder Gerätedateien (device flies). Wenn im vorliegenden Dokument ein Dateisystem als in den Dateibaum eingebunden (mounted) bezeichnet wird, soll dies nicht notwendigerweise heißen, daß das Dateisystem nur einen Teil des Dateibaums darstellt. Im Extremfall kann als Ergebnis des Einbindens auch der gesamte Dateibaum von dem Dateisystem gebildet werden. Gemäß einem ersten Aspekt der Erfindung wird zumindest ein transaktionsbasiertes Dateisystem in den Dateibaum eingebunden. Bei einem solchen Dateisystem werden Dateioperationen zumindest zum Teil wie atomare Transaktionen behandelt. Wenn während einer Dateioperation die Versor- gungsspannung des Datenträgers ausfällt, werden Undefinierte Zwischenzustände des Dateisystems spätestens beim nächsten Hochfahren des Datenträgers wieder rückgängig gemacht. Insgesamt werden also Aufgaben der Transaktionssicherung zumindest zum Teil vom Dateisystem übernommen. Anwendungsprogramme, die von dem Datenträger ausgeführt werden, brauchen diese Aufgaben dann nicht mehr selbst zu erledigen. Dies erleichtert die Programmierung, erhöht die Sicherheit des Datenträgers und führt in der Regel zu einem deutlichen Effizienzgewinn.
Gemäß einem zweiten Aspekt der Erfindung sind in den Dateibaum min- destens zwei in unterschiedlichen Technologien ausgestaltete Dateisysteme eingebunden, die zumindest zum Teil - und in bevorzugten Ausgestaltungen überwiegend oder vollständig - zur Speicherung mindestens eines Anwendungsprogramms bzw. zur Speicherung von Nutzdaten für das mindestens eine Anwendungsprogramm dienen. Diese Lehre ermöglicht eine besonders vorteilhafte Kombination der Eigenschaften unterschiedlicher
Dateisysteme. So kann beispielsweise für das mindestens eine Anwendungsprogramm, ein einfaches, speicherplatzsparendes Dateisystem verwendet werden. Für die Nutzdaten wird dagegen in bevorzugten Ausgestaltungen ein leistungsfähiges und/ oder transaktionsbasiertes Dateisystem verwendet.
Vorzugsweise ist das transaktionsbasierte Dateisystem ein journalführendes Dateisystem (journaling file System). Solche Dateisysteme sind z.B. unter den Namen Extθfs, ReiserFS, XFS und JFS an sich bekannt. Bei journalführenden Dateisystemen werden die in das Dateisystem zu schreibenden Datenblöcke zunächst in ein Journal aufgenommen. Erst wenn dieser Vorgang erfolgreich abgeschlossen ist, erfolgt das eigentliche Schreiben in das Dateisystem. Tritt während des Schreibens in das Journal eine Betriebsunterbrechung auf, so werden beim nächsten Hochfahren des Datenträgers die Einträge im Journal verworfen. Erfolgt die Betriebsunterbrechung dagegen erst, wenn der
Schreibvorgang in das Journal vollständig abgeschlossen ist, so werden beim nächsten Hochfahren des Datenträgers die Einträge aus dem Journal in das Dateisystem übertragen.
Besonders bevorzugt wird ein Betriebsmodus des journalführenden Dateisystems verwendet, in dem nicht nur Metadaten, sondern alle in das Dateisystem zu schreibenden Datenblöcke in dem Journal aufgezeichnet werden. Ein derartiger Betriebsmodus bietet eine vollwertige Transaktionssicherung, die garantiert, daß eine Schreiboperation entweder vollständig ausgeführt oder rückstandsfrei abgebrochen wird. In manchen Ausgestaltungen werden dagegen journalführende Dateisysteme und/ oder Betriebsmodi verwendet, die nur Metadaten, nicht aber die eigentlichen Inhalte, in dem Journal aufzeichnen. In diesem Fall wird bei einer Betriebsunterbrechung nur die Konsistenz der Strukturen des Dateisystems, nicht aber die Konsistenz der gespeicherten Dateien, gewährleistet. Vorzugsweise sollen auch derartige Ausgestaltungen als "transaktionsbasierte Dateisysteme" angesehen werden.
In vorteilhaften Ausgestaltungen wird das mindestens eine Anwendungsprogramm nicht in einem transaktionsbasierten Dateisystem gespeichert. Vielmehr ist für solche Nutzdaten vorzugsweise ein einfaches, speichersparendes Dateisystem vorgesehen, beispielsweise eines der unter den Namen Minix-FS und Flash-FS an sich bekannten Dateisysteme. In bevorzugten Ausführungsformen wird ein Anwendungsprogramm-Datei- system zur Speicherung der Nutzdaten des mindestens einen Anwendungsprogramms simuliert. Aus Sicht des Anwendungsprogramms kann das Anwendungsprogramm-Dateisystem, eine bei tragbaren Datenträgern übliche Struktur, beispielsweise nach ISO/IEC 7816-4, aufweisen. Diese Struktur wird in manchen Ausgestaltungen in dem Dateibaum des Datenträgers beibehalten. Vorzugsweise ist jedoch vorgesehen, daß das Anwendungsprogramm-Dateisystem, in eine einzige Container-Datei oder einige wenige Container-Dateien des Dateibaums abgebildet wird. Zugriffe des Anwen- dungsprogramms auf eine Datei des Anwendungsprogramm-Dateisystems werden dann in entsprechende Zugriffe auf einen mit der Datei korrespondierenden Abschnitt der Container-Datei abgebildet.
Wie eingangs bereits erwähnt, weist der Datenträger vorzugsweise ein UNIX-artiges Betriebssystem auf. In bevorzugten Ausgestaltungen wird mindestens ein aus dem Linux-Betriebssystem an sich bekanntes Dateisystem in geeignet modifizierter Form eingesetzt. Die Erfindung kann jedoch auch für andere Betriebsysteme eingesetzt werden, bei denen ähnliche Gegebenheiten vorliegen. Insbesondere ist es vorteilhaft, wenn das Betriebs- System einen Mechanismus zum Einbinden unterschiedlicher Dateisysteme in einen Dateibaum aufweist. Ein solcher Mechanismus ist bei dem Linux- Betriebssystem als VFS (virtual filesystem switch) an sich bekannt.
Der erfindungsgemäße Datenträger ist gemäß einem ersten Aspekt dazu eingerichtet, ein erfindungsgemäßes Verfahren zur Organisation eines Dateibaums auszuführen. Gemäß einem zweiten Aspekt enthält der Datenträger einen Dateibaum, der durch ein erfindungsgemäßes Verfahren generierbar ist oder generiert wurde. In bevorzugten Ausgestaltungen weisen der Datenträger und/ oder das Computerprogrammprodukt Merkmale auf, die den oben beschriebenen und/ oder den in den abhängigen Verfahrensansprüchen genannten Merkmalen entsprechen.
Das erfindungsgemäße Computerprogrammprodukt kann ein körperliches Medium mit gespeicherten Programmbefehlen sein, beispielsweise ein Halbleiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerpro- grammprodukt kann jedoch auch ein nicht-körperliches Medium sein, beispielsweise ein über ein Computernetzwerk übermitteltes Signal. Insbesondere kann das Cornputerprogrammprodukt ein Betriebssystem oder ein Betriebssystemmodul enthalten, das im Zuge der Herstellung oder der Initialisierung oder der Personalisierung eines tragbaren Datenträgers in diesen eingebracht wird.
Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden Beschreibung eines Ausführungsbeispiels und mehrerer Ausführungsalternativen hervor. Es wird auf die Zeichnung verwiesen.
Fig. 1 als einzige Zeichnungsfigur zeigt ein Blockdiagramm eines Datenträgers nach einem Ausführungsbeispiel der Erfindung.
Der in Fig. 1 dargestellte Datenträger 10 weist auf einem einzigen Halbleiter- chip einen Prozessor 12, einen Speicher 14 und eine Schnittstellenschaltung 16 zur kontaktlosen oder kontaktgebundenen Kommunikation mit einem externen Terminal (nicht gezeigt) auf. Der Speicher 14 ist in mehrere Speicher- f eider unterteilt. Im vorliegenden Ausführungsbeispiel sind als Speicherfelder ein als RAM ausgestalteter Arbeitsspeicher 18, ein als ROM ausgestalteter Festwertspeicher 20 und ein als EEPROM ausgestalteter, nicht-flüchtiger Speicher 22 vorgesehen. Im Speicher 14 - und zwar teils im Festwertspeicher 20 und teils im nicht- flüchtigen Speicher 22 - befindet sich Programmcode, der ein Betriebssystem 24 implementiert. Das Betriebssystem 24 ist im vorliegenden Ausführungsbeispiel eine auf den Einsatz im Datenträger 10 zugeschnittene Variante des unter der Marke Linux bekannten Betriebssystems. Insbesondere ist das Betriebssystem 24 an die erhebliche Ressourcenbeschränkung des Datenträgers 10 im Hinblick auf die Rechenleistung des Prozessors 12 und die Größe des Speichers 14 angepaßt.
Der nicht-flüchtige Speicher 22 enthält Datenstrukturen, die einen Dateibaum 26 bilden. Der Dateibaum 26 weist die für UNIX-Systeme übliche Struktur mit einer durch einen Schrägstrich "/" bezeichneten Wurzel und hierarchisch gegliederten Verzeichnissen und Dateien auf. In Fig. 1 sind beispielhaft ein Verzeichnis "etc" für Konfigurationsdateien und ein Verzeichnis "bin" für diverse systemnahe Programme gezeigt. Weitere Strukturen des Dateibaums 26 sind z.B. Querverweise (links) und Gerätedateien (deυice files), über die Ein- und Ausgabevorgänge des Datenträgers 10 durchgeführt werden.
In den Dateibaum 26 sind ein erstes und ein zweites Dateisystem 28, 30 eingebunden. Das erste Dateisystem 28 ist ein speichersparendes, nicht-trans- aktionsbasiertes und nicht-journalführendes Dateisystem, beispielsweise das an sich bekannte Minix-Dateisystem. Das zweite Dateisystem 30 ist dagegen als leistungsfähiges, transaktionsbasiertes Dateisystem ausgestaltet. Im vor- liegenden Ausführungsbeispiel ist das zweite Dateisystem 30 ein journalführendes Dateisystem, z.B. das unter dem Namen JFS bekannte Dateisystem. In Ausführungsalternativen ist die Verwendung anderer Dateisysteme vorgesehen. Insbesondere können als zweites Dateisystem 30 andere Journal- führende Dateisysteme eingesetzt werden, die Aufgaben der Transaktionssicherung vollständig oder teilweise übernehmen.
Das Einbinden (mounting) der Dateisysteme 28, 30 in den Dateibaum 26 erfolgt durch einen an sich bekannten Dienst des Betriebssystems 24. Durch eine unter dem Namen VFS (υirtual filesystem switch) bekannte Softwareschicht des Betriebssystems 24 wird ferner erreicht, daß auf die Dateisysteme 28, 30 völlig transparent - also unabhängig von der unterschiedlichen Technologie der Dateisysteme 28, 30 - zugegriffen werden kann. Der VFS stellt dazu eine Reihe vor definierter Zugriffsoperationen bereit, die einheitlich für den gesamten Dateibaum 26 anwendbar sind und die in die tatsächlich für die Dateisysteme 28, 30 vorhandenen Zugriffsoperationen umgesetzt werden.
In Fig. 1 ist beispielhaft ein Anwendungsprogramm 32 gezeigt, das als Datei im ersten Dateisystem 28 gespeichert ist. Das Anwendungsprogramm 32 implementiert eine Applikation des Datenträgers 10, z.B. eine Applikation als persönliche Geldbörse. Es versteht sich, daß weitere Anwendungsprogramme vorgesehen sein können. Das Anwendungsprogramm.32 setzt zur Speicherung von Nutzdaten 34, 34' ein auf dem Gebiet der Chipkarten übliches Anwendungsprogramm-Dateisystem 36 voraus. Im vorliegenden Ausführungsbeispiel ist das Anwendungsprogramm-Dateisystem 36 gemäß der Norm ISO/IEC 7816-4 mit einem Wurzelverzeichnis MF (masterfile), weiteren Verzeichnissen DF (dedicated file) und Dateien EF (elementary file) für die Nutzdaten 34, 34' ausgestaltet.
Das Anwendungsprogramm-Dateisystem 36 ist im vorliegenden Ausführungsbeispiel in dem zweiten, transaktionsbasierten Dateisystem 30 angelegt. Allerdings spiegelt sich die Verzeichnis- und Dateistruktur des Anwen- dungsprogramm-Dateisystems 36 nicht in einer entsprechenden Struktur des zweiten Dateisystems 30 wider. Vielmehr ist im vorliegenden Ausführungsbeispiel eine einzige Datei im zweiten Dateisystem 30 vorgesehen, die das gesamte Anwendungsprogramm-Dateisystem 36 einschließlich aller Nutz- daten 34, 34' enthält und daher als Container-Datei 38 bezeichnet wird. Jeder Datei des Anwendungsprogramm-Dateisystems 36 - und in manchen Ausgestaltungen auch jedem Ordner - entspricht je ein Abschnitt der Container- Datei 38. Die Container-Datei 38 weist damit eine interne Struktur auf, die der Struktur des AnwendungspiOgramm-Dateisystems 36 entspricht.
Ein Umsetzmodul 40, das in das Betriebssystem 24 integriert oder an dieses angebunden ist, simuliert das Anwendungsprogramm-Dateisystem 36 auf für das Anwendungsprogramm 32 völlig transparente Weise. Zugriffsoperationen, die das Anwendungsprogramm 32 auf Grundlage des Anwendungs- programm-Dateisystems 36 aufruft, werden vom Umsetzmodul 40 in entsprechende Zugriffe auf die jeweiligen Abschnitte der Container-Datei 38 umgesetzt, und die jeweiligen Resultate werden an das Anwendungsprogramm 32 zurückgegeben. In Ausführungsalternativen sind statt einer einzigen Container-Datei 38 mehrere Container-Dateien vorgesehen. Ferner sind auch Ausgestaltungen vorgesehen, bei denen das Anwendungsprogramm-Dateisystem 36 in eine entsprechende Struktur im zweiten Dateisystem 30 abgebildet wird.
Durch die Ausgestaltung des zweiten Dateisystems 30 als transaktions- basiertes, journalführendes Dateisystem wird jede Schreiboperation in die Container-Datei 38 zunächst in einem im nicht-flüchtigen Speicher 22 angelegten Journal (in Fig. 1 nicht gezeigt) vermerkt. Wenn während eines der beiden Schreibvorgänge in das Journal bzw. in die Container-Datei 38 eine unerwartete Betriebsunterbrechung auftritt, kann entweder das Journal oder die Container-Datei 38 eine inkonsistente Struktur oder einen inkonsistenten Inhalt aufweisen. Dies wird beim nächsten Hochfahren des Datenträgers 10 erkannt. Bei einem beschädigten Journal werden die darin enthaltenen Einträge verworfen. Bei einer beschädigten Container-Datei 38 wird die Schreib- Operation in die Container-Datei 38 gemäß dem Inhalt des Journals abgeschlossen. Eine genauere Darstellung dieses Vorgangs am Beispiel des Ext3- Dateisystems findet sich auf den Seiten 600 - 607 des eingangs zitierten Buches "Under standing the Linux Kernel".
In unterschiedlichen Ausgestaltungen umfaßt die vom zweiten Dateisystem 30 bereitgestellte Transaktionssicherung entweder alle in das zweite Dateisystem 30 einzuschreibenden Datenblöcke oder nur Metadaten, die die Struktur des zweiten Dateisystems 30 betreffen. Wenn nur Metadaten in das Journal aufgenommen werden, kann die Container-Datei 38 nach einer Betriebsunterbrechung des Datenträgers 10 einen teils neuen und teils alten Inhalt aufweisen. In diesen Ausgestaltungen sind daher zusätzliche Sicherungsmaßnahmen seitens des Anwendungsprogramms 32 und/ oder des Umsetzmoduls 40 erforderlich. Eine vollständige Transaktionssicherung wird dagegen in Ausgestaltungen erreicht, bei denen das Journal den gesam- ten durch eine Schreiboperation zu ändernden Dateiinhalt und alle zu ändernden Metadaten protokolliert.
In dem in Fig. 1 gezeigten Ausführungsbeispiel wird derjenige Teil des . Dateibaumes 26, der nicht von den Dateisystemen 28, 30 eingenommen wird, durch ein weiteres Dateisystem - z.B. ein ext2-Dateisystem - gebildet. Es sind jedoch auch Ausgestaltungen vorgesehen, bei denen die Dateisysteme 28, 30 den Dateibaum 26 vollständig aufspannen, so daß kein weiteres Dateisystem erforderlich ist. Ferner ist in manchen Ausgestaltungen statt der zwei Dateisysteme 28, 30 für das Anwendungsprogramm 32 und die Container- Datei 38 ein einziges, transaktionsbasiertes Dateisystem vorgesehen. Auch in solchen Ausgestaltungen kann der Dateibaum 26 entweder weitere Dateisysteme aufweisen oder ausschließlich durch das transaktionsbasierte Dateisystem gebildet sein.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Organisation eines Dateibaums (26) bei einem tragbaren Datenträger (10), dadurch gekennzeichnet, daß in den Dateibaum (26) mindestens ein transaktionsbasiertes Dateisystem (30) eingebunden wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das • transaktionsbasierte Dateisystem (30) zumindest teilweise zur Speicherung von Nutzdaten (34, 34') für mindestens ein Anwendungsprogramm (32) dient.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das mindestens eine Anwendungsprogramm (32) zumindest überwie- gend in einem weiteren Dateisystem (28) gespeichert ist, das in den Dateibaum (26) eingebunden und in einer zum transaktions- basierten Dateisystem (30) unterschiedlichen Technologie ausgestaltet ist.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß ein Anwendungsprogramm-Dateisystem (36) zur Speicherung der Nutzdaten (34, 34') für das mindestens eine Anwendungsprogramm (32) simuliert wird, indem Zugriffsoperationen des mindestens einen Anwendungsprogramms (32), die auf das Anwen- dungsprogramm-Dateisystem (36) ausgerichtet sind, in Zugriffe auf mindestens eine Container-Datei (38) des transaktionsbasier- ten Dateisystems (30) abgebildet werden.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß mehrere Dateien (EF) des simulierten Anwendungsprogramm- Dateisystems (36) in einer einzigen Container-Datei (38) des transaktionsbasierten Dateisystems (30) gespeichert werden.
6. Verfahren zur Organisation eines Dateibaums (26) bei einem tragbaren Datenträger (10), dadurch gekennzeichnet, daß in den Dateibaum (26) mindestens zwei in unterschiedlichen Technologien ausgestaltete Dateisysteme (28, 30) eingebunden werden, von denen ein erstes Dateisystem (28) zumindest teilweise zur Speicherung mindestens eines Anwendungsprogramms (32) dient und ein zweites Dateisystem (30) zumindest teilweise zur Speicherung von Nutzdaten (34, 34') für das mindestens eine Anwendungsprogramm (32) dient.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß das zweite Dateisystem (30) ein transaktionsbasiertes Dateisystem ist.
8. Verfahren nach Anspruch 6 oder Anspruch 7, dadurch gekenn- zeichnet, daß ein Anwendungsprogramm-Dateisystem (36) zur Speicherung der Nutzdaten (34, 34') für das mindestens eine Anwendungsprogramm (32) simuliert wird, indem Zugriffsoperationen des mindestens einen Anwendungsprogramms (32), die auf das Anwendungsprogramm-Dateisystem (36) ausgerichtet sind, in Zugriffe auf mindestens eine Container-Datei (38) des zweiten Dateisystems (30) abgebildet werden.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß mehrere Dateien (EF) des simulierten Anwendungsprogramm- Dateisystems (36) in einer einzigen Container-Datei (38) des zweiten Dateisystems (30) gespeichert werden.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekenn- zeichnet, daß das Anwendungsprogramm-Dateisystem (36) ein Dateisystem gemäß ISO/IEC 7816-4 ist.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, daß der Datenträger (10) ein UNIX-artiges Betriebs- System (24), insbesondere ein Linux-Betriebssystem aufweist.
12. Tragbarer Datenträger (10), insbesondere Chipkarte oder Chipmodul, mit einem Prozessor (12) und mindestens einem Speicher (14), wobei der Speicher (14) Prograrrimbefehle enthält, die den Prozessor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 11 veranlassen.
13. Tragbarer Datenträger (10), insbesondere Chipkarte oder Chipmodul, mit einem Prozessor (12) und mindestens einem Speicher (14), wobei der Speicher (14) einen Dateibaum (26) enthält, der durch ein Verfahren nach einem der Ansprüche 1 bis 11 generierbar ist.
14. Computerprogrammprodukt, das maschinenlesbare Programm- befehle für einen Prozessor (12) eines tragbaren Datenträgers (10) aufweist, die den Prozessor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 11 veranlassen.
EP04764398A 2003-08-26 2004-08-23 Organisation eines dateibaums bei einem tragbaren datenträger Withdrawn EP1661042A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10339203A DE10339203A1 (de) 2003-08-26 2003-08-26 Organisation eines Dateibaums bei einem tragbaren Datenträger
PCT/EP2004/009417 WO2005022405A1 (de) 2003-08-26 2004-08-23 Organisation eines dateibaums bei einem tragbaren datenträger

Publications (1)

Publication Number Publication Date
EP1661042A1 true EP1661042A1 (de) 2006-05-31

Family

ID=34223162

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04764398A Withdrawn EP1661042A1 (de) 2003-08-26 2004-08-23 Organisation eines dateibaums bei einem tragbaren datenträger

Country Status (3)

Country Link
EP (1) EP1661042A1 (de)
DE (1) DE10339203A1 (de)
WO (1) WO2005022405A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007054841A1 (de) 2007-11-16 2009-05-20 Giesecke & Devrient Gmbh Verfahren zum Zugriff auf einen Massenspeicher eines tragbaren Datenträgers und tragbarer Datenträger

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5568639A (en) * 1993-11-24 1996-10-22 Menai Corporation Method and apparatus for providing an object-oriented file structuring system on a computer
US5636357A (en) * 1994-12-21 1997-06-03 Eurotronics Company Memory card and method for operation in a plurality of systems having incompatible object code format requirements
US5752005A (en) * 1996-01-22 1998-05-12 Microtest, Inc. Foreign file system establishing method which uses a native file system virtual device driver

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANSLEY C ET AL: "System administration in a single address space operating system", OBJECT-ORIENTATION IN OPERATION SYSTEMS, 1996., PROCEEDINGS OF THE FIF TH INTERNATIONAL WORKSHOP ON SEATTLE, WA, USA 27-28 OCT. 1996, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US LNKD- DOI:10.1109/IWOOOS.1996.557914, 27 October 1996 (1996-10-27), pages 166 - 170, XP010201486, ISBN: 978-0-8186-7693-2 *
See also references of WO2005022405A1 *

Also Published As

Publication number Publication date
DE10339203A1 (de) 2005-03-31
WO2005022405A1 (de) 2005-03-10

Similar Documents

Publication Publication Date Title
DE3586956T2 (de) Speicherzuordnungsverfahren fuer rechnersysteme.
DE69130312T2 (de) Dateisystem mit Schreib/Lesespeicher und einmaligen Schreib- und mehrmaligen Lese-speicher
DE68926693T2 (de) System und Verfahren zur einem Systemfehler nachfolgenden Datenerholung in einer Datenbank eines Rechnersystems
DE3784190T2 (de) Eintragung eines datenbasisindex in das journal zur verbesserten rueckstellung.
DE3780807T2 (de) Verfahren zum schnellen oeffnen von mit pfadnamen identifizierten plattendateien.
DE69516538T2 (de) Speicherung von rechnerdaten
DE69413977T2 (de) Anordnung und verfahren zur verteilten datenverwaltung in vernetzten rechnersystemen
DE69031491T2 (de) Hypertextdatenverarbeitungssystem und Verfahren
DE69311554T3 (de) Massenspeicherkarte mit eingangs- ausgangsfunktion.
DE69031028T2 (de) System zum physikalischen Entwurf von Datenbanken
DE3127825C2 (de)
DE4435751B4 (de) Dateiname- und Verzeichnis- Erfassungsverfahren zur Verwendung mit einem Betriebssystem
DE602004007793T2 (de) System und verfahren zur verwaltung von backupmedien in einer datenverarbeitungsumgebung
DE60306663T2 (de) Verfahren, Vorrichtungen und Programme zur Regelung des Zugriffs auf Datenobjekte unter Verwendung von Sperren
EP1088280A1 (de) Verfahren und system zur schnellen speicherresidenten verarbeitung von transaktionsdaten
DE3807997A1 (de) Ic-karte mit interner fehlerpruefung
DE3586447T2 (de) Kompression von binaerzahlen fuer ihre speicherung.
DE19645128C2 (de) Verfahren zum Verwalten von Dokumenten sowie Gerätetreiber zur Durchführung des Verfahrens
DE19954532A1 (de) Verfahren und System zur Speicherung von JAVA-Objekten in Vorrichtungen mit einer verringerten Unterstützung von höheren Programmierkonzepten
DE69620334T2 (de) Elektronisches Bauelement mit einem elektrisch löschbaren und nichtflüchtigen Speicher
DE60315291T2 (de) Computersystem und Verfahren zum Betreiben eines Computersystems
DE19933584A1 (de) Verfahren zur kompakten Darstellung von Informationspaketen und deren Speicherung oder Übertragung
DE69406138T2 (de) Verfahren zum datenschreiben in einem nicht flüchtigen speicher
WO2005022405A1 (de) Organisation eines dateibaums bei einem tragbaren datenträger
DE10141926B4 (de) Verfahren zur Sicherung der Daten eines Datenspeichers

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060327

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100111

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20140301