WO2005022405A1

WO2005022405A1 - Organization of a file tree for a portable data carrier

Info

Publication number: WO2005022405A1
Application number: PCT/EP2004/009417
Authority: WO
Inventors: Erich Englbrecht; Robert Hockauf; Thorsten Ulbricht; Rudolf Schubert
Original assignee: Giesecke & Devrient Gmbh
Priority date: 2003-08-26
Filing date: 2004-08-23
Publication date: 2005-03-10
Also published as: EP1661042A1; DE10339203A1

Abstract

The invention relates to a method for organizing a data tree (26) for a portable data carrier (10), according to which at least one transaction-based data system (30) is integrated in said data tree (26). In an additional method, at least two file systems (28, 30) that have been configured by different technologies are integrated in the data tree (26), the first (28) of which is at least partly responsible for saving at least one application program (32) and the second (30) of which is at least partly responsible for saving useful data (34, 34') for the application program(s) (32). A portable data carrier (10) and a computer program product comprise corresponding characteristics. The invention provides a technology for organizing a data tree (26) that is specifically tailored to the conditions existing in portable data carriers (10).

Description

Organization of a file tree for a portable data carrier

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.

A portable data carrier in the sense of the present document can in particular be a chip card (smart card in different designs or a chip module or another resource-limited system. Typical circumstances with portable data carriers are the considerable limitation of storage space and computing power as well as the requirement that even after a sudden Failure of the supply voltage - for example by disconnecting the data carrier from a terminal - no undefined operating states may occur.

An internal research project by Giesecke & Devrient GmbH is currently investigating the extent to which a UNIX®-like operating system can be implemented on a data carrier available today or expected in the future. In this context, an implementation of the operating system known under the Linux® brand is planned. The book "Understanding the Linux Kernel" by D. P. Bovet and M. Cesati, O'Reilly Verlag, 2nd edition, December 2002, contains a detailed technical description of this operating system.

The file trees, file systems and file system organization techniques commonly used in the Linux operating system are explained in particular on pages 12-16 and in chapters 12, 15 and 17 of the book just cited. Reference is made to these sites. However, neither the use of the Linux operating system for portable data carriers nor a special adaptation of file systems to the conditions of portable data carriers is disclosed there. The invention therefore has the abe to provide a technique for organizing a file tree, which is specifically tailored to the circumstances of portable data carriers. According to a first aspect, the invention is intended in particular to help prevent undefined operating states with little effort. According to a second aspect, the invention is intended to provide the technical foundations for a particularly space-saving and / or efficient file management in the portable data carrier.

According to the invention, this object is achieved in whole or in part by a method according to claim 1 or claim 6, a portable data carrier according to claim 12 or claim 13 and a computer program product according to claim 14. The dependent claims relate to preferred embodiments of the invention.

The invention is based on the basic idea of using the known technique of integrating file systems into a file tree in a manner which is particularly advantageous for portable data carriers. The term "file tree" used in the present document is to be understood in particular to mean any hierarchical structure which is able to accommodate directories and files. This does not exclude that there are other elements in the file tree, such as cross references (left) or device files (device flies). If in the present document a file system is referred to as mounted in the file tree, this should not necessarily mean that the file system represents only part of the file tree. In extreme cases, the entire file tree can also be formed by the file system as a result of the integration. According to a first aspect of the invention, at least one transaction-based file system is integrated into the file tree. In such a file system, file operations are at least partially treated like atomic transactions. If the supply voltage of the data medium fails during a file operation, undefined intermediate states of the file system are reversed at the latest when the data medium is started up again. Overall, transaction security tasks are at least partially performed by the file system. Application programs that are executed from the data medium then no longer have to do these tasks themselves. This simplifies programming, increases the security of the data carrier and generally leads to a significant increase in efficiency.

According to a second aspect of the invention, 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. This teaching enables a particularly advantageous combination of the properties of different ones

File systems. For example, a simple, space-saving file system can be used for the at least one application program. In contrast, preferred configurations use a powerful and / or transaction-based file system for the user data.

The transaction-based file system is preferably a journaling file system. Such file systems are known per se, for example, under the names Extθfs, ReiserFS, XFS and JFS. In the case of journal-leading file systems, the data blocks to be written into the file system initially recorded in a journal. Only when this process has been successfully completed does the actual writing into the file system take place. If an operational interruption occurs while writing to the journal, the entries in the journal are discarded the next time the data medium is started up. However, the business interruption only takes place when the

When the writing process to the journal has been completed, the entries from the journal are transferred to the file system the next time the data medium is started up.

An operating mode of the journal-carrying file system is particularly preferably used in which not only metadata but also all data blocks to be written to the file system are recorded in the journal. Such an operating mode offers full transaction protection, which guarantees that a write operation is either carried out completely or is canceled without any residues. In some configurations, on the other hand, journal-leading file systems and / or operating modes are used which only record metadata, but not the actual content, in the journal. In this case, only the consistency of the structures of the file system, but not the consistency of the saved files, is guaranteed in the event of a business interruption. Such configurations should preferably also be regarded as “transaction-based file systems”.

In advantageous configurations, the at least one application program is not stored in a transaction-based file system. Rather, a simple, memory-saving file system is preferably provided for such user data, for example one of the file systems known per se under the names Minix-FS and Flash-FS. In preferred embodiments, an application program file system for storing the user data of the at least one application program is simulated. From the point of view of the application program, the application program file system can have a structure that is customary for portable data carriers, for example according to ISO / IEC 7816-4. This structure is retained in the file tree of the data carrier in some configurations. However, it is preferably provided that the application program file system is mapped into a single container file or a few container files of the file tree. Accesses by the application program to a file in the application program file system are then mapped to corresponding accesses to a section of the container file that corresponds to the file.

As already mentioned at the beginning, the data carrier preferably has a UNIX-like operating system. In preferred embodiments, at least one file system known per se from the Linux operating system is used in a suitably modified form. However, the invention can also be used for other operating systems in which similar circumstances exist. It is particularly advantageous if the operating system has a mechanism for integrating different file systems into a file tree. Such a mechanism is known per se in the Linux operating system as VFS (virtual filesystem switch).

According to a first aspect, the data carrier according to the invention is set up to carry out a method according to the invention for organizing a file tree. According to a second aspect, the data carrier contains a file tree which can be generated or was generated by a method according to the invention. In preferred configurations, the data carrier and / or the computer program product have features that correspond to the described above and / or correspond to the features mentioned in the dependent method claims.

The computer program product according to the invention can be a physical medium with stored program instructions, for example a semiconductor memory or a floppy disk or a CD-ROM. However, the computer program product can also be a non-physical medium, for example a signal transmitted over a computer network. In particular, the computer program product can contain an operating system or an operating system module which is introduced into the portable data carrier in the course of the manufacture or initialization or personalization thereof.

Further features, advantages and objects of the invention will become apparent from the following description of an exemplary embodiment and several alternative embodiments. Reference is made to the drawing.

Fig. 1 as the only drawing figure shows a block diagram of a data carrier according to an embodiment of the invention.

The data carrier 10 shown in FIG. 1 has a processor 12, a memory 14 and an interface circuit 16 for contactless or contact-based communication with an external terminal (not shown) on a single semiconductor chip. The memory 14 is subdivided into several memory fiders. In the present exemplary embodiment, a working memory 18 configured as RAM, a read-only memory 20 configured as ROM and a non-volatile memory 22 configured as EEPROM are provided as memory fields. In the memory 14 - partly in the read-only memory 20 and partly in the non-volatile memory 22 - there is program code which implements an operating system 24. In the present exemplary embodiment, the operating system 24 is a variant of the operating system known under the Linux brand, tailored to use in the data carrier 10. In particular, the operating system 24 is adapted to the considerable resource limitation of the data carrier 10 with regard to the computing power of the processor 12 and the size of the memory 14.

The non-volatile memory 22 contains data structures that form a file tree 26. The file tree 26 has the structure customary for UNIX systems with a root identified by a slash "/" and hierarchically structured directories and files. 1 shows an example of a directory "etc" for configuration files and a directory "bin" for various system-related programs. Other structures of the file tree 26 are e.g. Cross references (left) and device files (deυice files) via which the input and output operations of the data carrier 10 are carried out.

A first and a second file system 28, 30 are integrated into the file tree 26. The first file system 28 is a memory-saving, non-transaction-based and non-journal-keeping file system, for example the Minix file system known per se. In contrast, the second file system 30 is designed as a powerful, transaction-based file system. In the present exemplary embodiment, the second file system 30 is a journal-leading file system, for example the file system known under the name JFS. In alternative versions, the use of other file systems is provided. In particular, other journal systems 30 leading file systems are used, which take over the tasks of transaction security completely or partially.

The mounting (mounting) of the file systems 28, 30 into the file tree 26 is carried out by a service of the operating system 24 which is known per se. A software layer of the operating system 24 known as VFS (virtual filesystem switch) also ensures that the file systems 28 , 30 can be accessed completely transparently - that is, regardless of the different technology of the file systems 28, 30. For this purpose, the VFS provides a series of predefined access operations which can be used uniformly for the entire file tree 26 and which are implemented in the access operations actually available for the file systems 28, 30.

1 shows an example of an application program 32 that is stored as a file in the first file system 28. The application program 32 implements an application of the data carrier 10, e.g. an application as a personal wallet. It is understood that further application programs can be provided. The application program 32 requires an application program file system 36 which is customary in the field of chip cards for storing useful data 34, 34 '. In the present exemplary embodiment, the application program file system 36 is designed in accordance with the ISO / IEC 7816-4 standard with a root directory MF (master file), further directories DF (dedicated file) and files EF (elementary file) for the useful data 34, 34 '.

In the present exemplary embodiment, the application program file system 36 is created in the second, transaction-based file system 30. However, the directory and file structure of the user is reflected application program file system 36 is not reflected in a corresponding structure of the second file system 30. Rather, in the present exemplary embodiment, a single file is provided in the second file system 30, which contains the entire application program file system 36 including all user data 34, 34 'and is therefore referred to as a container file 38. Each file of the application program file system 36 - and in some embodiments also each folder - corresponds to a section of the container file 38. The container file 38 thus has an internal structure which corresponds to the structure of the application program file system 36.

A conversion module 40, which is integrated into or connected to the operating system 24, simulates the application program file system 36 in a manner that is completely transparent to the application program 32. Access operations that the application program 32 calls based on the application program file system 36 are converted by the conversion module 40 into corresponding accesses to the respective sections of the container file 38, and the respective results are returned to the application program 32. In alternative embodiments, multiple container files are provided instead of a single container file 38. Embodiments are also provided in which the application program file system 36 is mapped into a corresponding structure in the second file system 30.

By designing the second file system 30 as a transaction-based, journal-leading file system, each write operation to the container file 38 is first noted in a journal (not shown in FIG. 1) that is stored in the non-volatile memory 22. If an unexpected interrupt occurs during one of the two writes to the journal or container file 38, either the journal or container file 38 has an inconsistent structure or content. This is recognized the next time the data carrier 10 is started up. If the journal is damaged, the entries in it are discarded. If the container file 38 is damaged, the write operation to the container file 38 is completed in accordance with the contents of the journal. A more detailed description of this process using the example of the Ext3 file system can be found on pages 600 - 607 of the book "Under standing the Linux Kernel" cited at the beginning.

In various configurations, 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.

In the embodiment shown in Fig. 1 that part of. File tree 26, which is not occupied by the file systems 28, 30, is formed by a further file system - for example an ext2 file system. However, configurations are also provided in which the file systems 28, 30 span the file tree 26 completely, so that no further file system is required. Furthermore, in some configurations, instead of the two file systems 28, 30 for the application program 32 and the container File 38 provided a single, transaction-based file system. In such configurations, too, the file tree 26 can either have further file systems or be formed exclusively by the transaction-based file system.

Claims

Patent claims

1. A method for organizing a file tree (26) in a portable data carrier (10), characterized in that at least one transaction-based file system (30) is integrated in the file tree (26).

2. The method according to claim 1, characterized in that the ^• transaction-based file system (30) is used at least partially for storing useful data (34, 34 ') for at least one application program (32).

3. The method according to claim 2, characterized in that the at least one application program (32) is at least predominantly stored in a further file system (28) which is integrated in the file tree (26) and in a transaction-based file system (30 ) different technology is designed.

4. The method according to claim 3, characterized in that an application program file system (36) for storing the user data (34, 34 ') for the at least one application program (32) is simulated by access operations of the at least one application program (32) are oriented towards the application program file system (36) and are mapped into accesses to at least one container file (38) of the transaction-based file system (30).

5. The method according to claim 4, characterized in that a plurality of files (EF) of the simulated application program file system (36) are stored in a single container file (38) of the transaction-based file system (30).

6. A method for organizing a file tree (26) in a portable data carrier (10), characterized in that in the file tree (26) at least two file systems (28, 30) configured in different technologies are integrated, of which a first file system (28 ) is used at least partially to store at least one application program (32) and a second file system (30) is used at least partially to store user data (34, 34 ') for the at least one application program (32).

7. The method according to claim 6, characterized in that the second file system (30) is a transaction-based file system.

8. The method according to claim 6 or claim 7, characterized in that an application program file system (36) for storing the user data (34, 34 ') for the at least one application program (32) is simulated by access operations of the at least one application program (32), which are aimed at the application program file system (36), are mapped into accesses to at least one container file (38) of the second file system (30).

9. The method according to claim 8, characterized in that several files (EF) of the simulated application program File system (36) can be stored in a single container file (38) of the second file system (30).

10. The method according to any one of claims 1 to 9, characterized in that the application program file system (36) is a file system according to ISO / IEC 7816-4.

11. The method according to any one of claims 1 to 10, characterized in that the data carrier (10) has a UNIX-like operating system (24), in particular a Linux operating system.

12. Portable data carrier (10), in particular chip card or chip module, with a processor (12) and at least one memory (14), the memory (14) containing program instructions which the processor (12) has to carry out a method according to one of the claims Initiate 1 to 11.

13. A portable data carrier (10), in particular a chip card or chip module, with a processor (12) and at least one memory (14), the memory (14) containing a file tree (26), which by a method according to one of claims 1 to 11 can be generated.

14. Computer program product which has machine-readable program instructions for a processor (12) of a portable data carrier (10), which cause the processor (12) to carry out a method according to one of claims 1 to 11.