EP1741029A2

EP1741029A2 - Managing a file system in a portable data carrier

Info

Publication number: EP1741029A2
Application number: EP05740488A
Authority: EP
Inventors: Robert Hockauf; Thorsten Ulbricht; Rudolf Schubert
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2004-04-22
Filing date: 2005-04-19
Publication date: 2007-01-10
Also published as: WO2005104018A2; WO2005104018A3; DE102004019683A1

Abstract

Disclosed is a method for managing a file system (22) in a portable data carrier. According to said method, process-specific visibility data (32) is managed for at least some structures (26x) in the file system (22) such that an event during which a process (24A) creates or deletes a structure (26x) in or from the file system (22) remains hidden for other concurrently executed processes at least until said event has been successfully completed. A portable data carrier and a computer program product are provided with corresponding characteristics. The invention allows at least some flawed sequences that occur when creating and/or deleting structures (26x) in/from the file system (22) to be prevented with little effort in terms of resources.

Description

Manage a file system in a portable disk

The invention relates generally to the technical field of maintaining a file system in a portable data carrier, the data carrier having an operating system that supports concurrent - that is, parallel or quasi-parallel - processes. A portable data carrier in the sense of the present document can be, in particular, a chip card (smart card) in various designs or a chip module or some other resource-limited system.

Portable data carriers are being manufactured with more and more storage space and ever greater computing power. An internal research project by Giesecke & Devrient GmbH is currently investigating the extent to which a multitasking operating system can be implemented in a modern, portable data carrier. In this context, the implementation of a UΝIX®-like operating system, e.g. of the operating system known under the Linux® brand. However, significant problems arise from the fact that the resource requirements of a typical Linux implementation fully utilize or even exceed the storage and computing capacity of today's portable data carriers. For this reason, the use of resource-saving processes is of crucial importance.

Furthermore, high demands are generally placed on the security and reliability of the hardware, the operating system and the application programs executed in the case of portable data carriers. For example, access conflicts and inconsistencies that can occur when several processes of a multitasking-capable chip card access a shared file system independently of one another must be reliably avoided. It must be ensured that changes in the file system, always atomic, ie either completely or not at all. In this context, for write access to an existing structure of the file system, it is known to lock the structure - a file or a directory - against access by the other processes for the duration of the write access.

However, a special situation arises when a structure in the file system that other processes may access is created or deleted. For example, With a GSM card, a phone book is created by one process and a second process checks whether a phone book is available. If the creation of the phone book fails - e.g. because of a sudden interruption of the energy supply of the data carrier - then the created file must be removed without residue because of the requirement for an atomic execution of the process. If the second process happened to have performed a file query during the brief existence of the file, it could come to the erroneous result that there is a telephone book.

The problem thus arises of reliably avoiding errors of the type just described when executing concurrent processes in a portable data carrier. A corresponding problem arises when deleting a structure in the file system.

US Pat. No. 6,220,510 discloses a chip card which is capable of executing several application programs. Each application program is assigned a static and a dynamic memory area, which are shielded from the other application programs. Tasks can be delegated from a first application program to a second application program via a command / response mechanism; in this connection the commands and responses are written to a public data storage area.

The object of the invention is to provide a mechanism for managing a file system in a portable data carrier, by means of which at least some errors in the creation of structures in the file system and / or deletion of structures from the file system can be avoided with little resource expenditure. In particular, inconsistencies of the type mentioned above, which can occur due to access by concurrent processes to the file system, are to be prevented.

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

The invention is based on the basic idea of managing process-specific visibility information for at least some structures in the file system in order to cause an operation in which a process creates a structure in the file system or deletes it from the file system for the other processes, at least until successful Completion of this process remains hidden. For the other processes, for example, a newly created file will only be visible if the complete process of creating the file - including, if necessary, saving data to the file - has been successfully completed, i.e. if there is no longer any possibility of canceling or failing this process consists. Errors caused by access conflicts can thus be reliably avoided. A particular advantage of the invention is that - with a suitable implementation - only little memory is required for the visibility information. Furthermore, no complex additional operations - for example, making extensive backup copies in a shadow memory or rollback buffer - are required.

In preferred refinements of the invention, the visibility information contains, at least for those structures of the file system which are currently being created or for which the deletion process has not yet been completed, an identifier of the process responsible for the creation or deletion process and a mark ifl g) which indicates whether it is a creation or a delete operation. In other embodiments, the visibility information can consist of a mark that indicates whether or not a visibility check should be carried out first when an attempt is made to access the structure to which the visibility information is assigned. If a visibility check is to be carried out, an attachment can be provided in these configurations, which indicates the process for which the respective structure is visible or hidden.

In some configurations it is provided that structures to which no or no valid visibility information is assigned should be visible to all processes.

In preferred embodiments of the invention, when a new structure is created in the file system, the visibility information for this structure is set such that the structure is only visible to the generating process. Only after the creation process has been successfully completed - for example after confirmation with a Commii command - are the Visibility information set so that the structure is generally visible. Depending on the type and meaning of the visibility information, this setting can be made, for example, by deleting the visibility information or by setting a process identifier contained in it to an invalid value. If the process is terminated, the structure that was never visible to the other processes is deleted from the file system.

To delete a structure from the file system, in preferred configurations only the visibility information is initially set such that the structure is hidden from the process requesting the deletion, but remains visible to all other processes. Only when it is certain that the deletion is to be carried out irrevocably will the structure actually be deleted from the file system. If the deletion process is terminated - if the structure also for the person requesting the deletion

Process should become visible again - the visibility information is set accordingly. In some configurations, this can be done by deleting the visibility information or by setting it to an invalid value.

In preferred embodiments, the process involving the creation or deletion of the structure is an atomic process, which is either carried out completely or is terminated without residue. The termination can be triggered, for example, by an occurring error or power failure or by an abort command. Successful completion requires confirmation by a Co zt command in some embodiments, while in other embodiments the operation is successfully completed if no error occurs. The process can be, for example, an atomic transaction or an atomic process in which initially a file is created and then data is saved in this file.

In general, the invention can be used in connection with all structures in the file system that can be created and / or deleted by concurrent processes - these can be processes of the operating system and / or an application program. Such structures can e.g. Files or directories. Refinements are also provided in which only files are viewed as structures in the sense of the invention. This includes configurations in which directories in the file system are designed as a special type of file.

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 preferred refinements, the data carrier and / or the computer program product have features which correspond to the features described above and / or to the features mentioned in the dependent method claims.

Further features, advantages and objects of the invention will become apparent from the following detailed description of an exemplary embodiment and several alternative embodiments. Reference is made to the schematic drawings, in which:

1 is a block diagram with functional units of a data carrier according to an embodiment of the invention, 2 shows a representation of the access of processes to a file system during the operation of the data carrier from FIG. 1,

Fig. 3 is a flowchart of the creation of a file in the disk of Fig. 1, and

FIG. 4 shows a flow diagram of the deletion of a file in the data carrier from FIG. 1.

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 in FIG. 1) on a single semiconductor chip. The memory 14 is divided in a manner known per se into a plurality of memory fields designed in different technologies - RAM, ROM and EEPROM in the present exemplary embodiment.

In the memory 14 there is program code which implements an operating system 18. In the present exemplary embodiment, the operating system 18 is a variant of the operating system known under the Linux brand, tailored to use in the data carrier 10. Furthermore, the memory 14 contains at least one application program 20 and a file system 22 which has file and directory structures in a tree-like arrangement.

As shown in FIG. 2, several processes 24A, 24B, 24C, ... - referred to in the following in summary with 24x - run quasi-parallel during operation of the data carrier 10. The processes 24x can system processes of the operating system 18 and / or user processes of the application program 20 his. Each of the processes 24x has a unique process identifier PID (process identifier); 2, the process identifiers "1001", "1002" and "1003" are shown by way of example. The operating system 18 controls and coordinates the concurrent flow of the processes 24x. Processes 24x can also access file system 22 via operating system 18. 2 shows two structures 26A, 26B and two files 26C, 26D as structures of the file system 22; these and other structures contained in the file system 22 are referred to in the following as 26x.

There is now a general problem that temporary or inconsistent operations that processes 24x perform on shared file system 22 may experience temporary inconsistencies. This can be particularly the case if a process 24x performs several such operations in one atomic transaction. The methods described below avoid this problem in the operations for creating and deleting structures 26x in the file system 22.

FIG. 3 shows an exemplary sequence in which the process 24 A - process identifier "1001" - creates a new file in a successful transaction - here the file 26C as an example - and writes data to this file. The vertical arrows in Fig. 3 indicate the timing of the process; The sequence of different states of the file system 22 during the process is illustrated in the column headed “file system”.

3 begins with the start of a new transaction by an instruction 28, which the process 24A transmits to the operating system 18. Process 24A also issues a command 30 to create a new one File to the operating system 18. The operating system 18 then creates the new file 26C in the file system 22. In this case, the file 26C is assigned visibility information 32, which contains the identifier PID of the commanding process - in the present case the identifier "1001" of the process 24A - and a label M (fing). The mark M indicates a visibility mode for the file 26C.

The visibility mode "1" used here when creating a file generally means that the process identifier PID contained in the visibility information 32 indicates the process for which the file is to be visible. The file should be hidden for all other processes. A visibility mode "0", on the other hand, would indicate that the process identifier PID contained in the visibility information 32 indicates the - only - process for which the file is to be hidden. This visibility mode "0" is used in connection with the deletion of a file to be described.

In the example of FIG. 3, the file 26C generated after the execution of the command 30 is only visible for the process 24A with the process identifier "1001" and is hidden for all other processes 24B, 24C, .... If such another process 24B, 24C, ... were to request a listing of the structures 26x contained in the file system 22 at the present time, then the file 26C would not be contained therein. Likewise, the other process 24B, 24C, ... would try to get an error message about a non-existent file when trying to access file 26C.

In a subsequent command 34, process 24A writes data to newly created file 26C. The visibility information 32 remains unchanged changed. The file 26C is therefore still only visible to the process 24A and hidden for all other processes 24B, 24C, ...

If the process 24A confirms the transaction with a Corarmt command 36, the successful completion of the transaction is indicated by the process identifier PID contained in the visibility information 32 being set to an invalid value - e.g. the value "0" - is set. The visibility information 32 is thus invalid overall, which means that there are no longer any restrictions regarding the visibility of the file 26C. All processes 24x can now see the file 26C and have unlimited access to it.

If the transaction is not confirmed, but - e.g. in response to an abort command or due to an error - the file 26C is deleted from the file system 22. This can take place immediately in response to the abort command or the next time the data carrier 10 is started up or at another suitable point in time. Except for the process 24A executing the transaction, in this case no other process 24B, 24C, ... could at any time have knowledge of the temporarily created file 26C.

3, four separate instructions 28, 30, 34, 36 are shown. It is understood that these commands can be combined in whole or in part in alternative embodiments. For example, commands 30 and 34 can be combined into a single command that writes data to a new file to be created. In further alternative embodiments, this command - or command 30 shown in FIG. 3 - can implicitly indicate the start of a new transaction, so that command 28 can be omitted. Furthermore, in some Refinements to an explicit transaction confirmation by a Coraraz ^' t command.

FIG. 4 illustrates the course of a process in which an existing file in the file system 22 - here the file 26D as an example - is deleted. The initial state for this process is that the file 26D is contained in the file system 22 and is visible 24x to all processes. This can e.g. are indicated by missing or invalid visibility information 32 - in the present example by an invalid process identifier PID with the value "0".

With commands 38 and 40, process 24A requests operating system 18 to start a new transaction and delete file 26D. However, the operating system 18 does not yet delete the file 26D from the file system 22 at this time, but only hides it from the process 24A requesting the deletion. For this purpose, the value "1001" is entered in the visibility information 32 as the process identifier PID of the process 24A requesting the deletion and the value "0" as the visibility mode M; the meaning of this value for the visibility mode M has already been explained above. The file 26D is thus still visible to all other processes 24B, 24C, ...

The operating system 18 does not actually initiate the actual deletion of the file 26D from the file system 22 in response to the receipt of a Commzϊ command 42 to confirm the transaction. Only at this point in time can the other processes 24B, 24C,.. - Get transaction. If the deletion transaction is not completed successfully, but is canceled, the file 26D remains in the file system 22. The visibility information 32 is then set again - for example by setting the process identifier PID to the invalid value "0" - that the file 26D is available to everyone Processes is visible 24x. If a transaction is aborted by an abort command, this occurs immediately in response to this command; in the event of a transaction abort due to a power failure, the visibility information 32 is reset accordingly the next time the data carrier 10 is restarted. Overall, in this case, the file 26D was for all other processes 24B, 24C, ... during the entire process - that is, all

Processes other than process 24A issuing delete command 40 - continuously visible.

Claims

Patent claims

1. A method for managing a file system (22) in a portable data carrier (10), the portable data carrier (10) having an operating system (18) that supports concurrent processes (24x) that access the file system (22) , and wherein process-specific visibility information (32) is managed for at least some structures (26x) in the file system (22) to cause an operation in which a process (24A) creates a structure (26x) in the file system (22) or deletes from the file system (22), for which other processes (24B, 24C) remain hidden until this process has been successfully completed.

2. The method according to claim 1, characterized in that the process (24A) requests the creation of a new structure (26x) in the file system (22), and that the structure (26x) is then generated in the file system (22), but the visibility information (32) for this structure (26x) is set so that the structure (26x) is only visible to the generating process (24A).

3. The method according to claim 2, characterized in that after the successful completion of the process, the visibility information (32) for the generated structure (26x) is set so that the structure (26x) is visible to all processes (24x) ,

4. The method according to claim 2 or claim 3, characterized in that the structure (26x) is deleted from the file system (22) when the process is terminated.

5. The method according to any one of claims 1 to 4, characterized in that the process (24A) in the process requests the deletion of an existing structure (26x) from the file system (22), and that thereupon the visibility information (32) for this structure (26x) are set such that the structure (26x) is only hidden for the process (24A) requesting the deletion, while the structure (26x) remains in the file system (22).

6. The method according to claim 5, characterized in that after the successful completion of the process, the structure (26x) is deleted from the file system (22).

7. The method according to claim 5 or claim 6, characterized in that when the process is terminated, the visibility information (32) for the structure (26x) is set such that the structure (26x) is again visible to all processes (24x).

8. The method according to any one of claims 1 to 7, characterized in that the visibility information (32) for at least some structures (26x) in the file system (22) contain an identifier (PID) of a process (24A) and information (M) about it whether the structure (26x) should be visible for this process (24A) and hidden for all other processes (24B, 24C) or hidden for this process (24A) and visible for all other processes (24B, 24C).

9. The method according to any one of claims 1 to 8, characterized in that structures (26x) of the file system (22), to which no or no valid visibility information (32) are assigned, are visible to all processes (24x).

10. The method according to any one of claims 1 to 9, characterized in that the process is a transaction that can either be canceled or successfully completed by confirmation.

11. The method according to any one of claims 1 to 10, characterized in that the process is the storage of data in a file to be newly created (26C, 26D).

12. The method according to any one of claims 1 to 11, characterized in that the structure is a file (26C, 26D) or a directory (26A, 26B) in the file system (22).

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

14. 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 are set up to enable the processor (12) to carry out a method to cause according to one of claims 1 to 13.

5. Computer program product which has machine-readable program instructions for a processor (12) of a portable data carrier (10) which are set up to cause the processor (12) to carry out a method according to one of claims 1 to 13.