RU2808634C1 - Dynamic real-time file systems compatibility determination - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: method for dynamically determining compatibility of file systems, a system for accessing data in real time regardless of file systems, and a computer-readable storage medium. A method for dynamically determining file system compatibility and file system-independent data access in real time includes: providing file system access to a passive data memory for an active terminal and a simulator; receiving an access request from the active terminal by the simulator; recognition of the passive data memory file system by the simulator; selecting stored access rules that are suitable for fulfilling the access request in accordance with the recognized passive data storage file system; application of the selected access rules to access data by the simulator, which are specified in the access request; and performing access operations in accordance with the access request.

EFFECT: ability to access passive data memory regardless of the file system managing the passive data memory.

14 cl, 12 dwg

Description

The present invention relates to a method for dynamically determining file system compatibility and a real-time data access system independent of file systems. According to the claims, the end user can access the passive data memory from any terminal, regardless of the file system under which the passive data memory is located. This avoids complex multi-step processes that, for example, involve converting the file system directly on the storage medium. Thus, the proposed method is more efficient and error-resistant. The present invention also relates to an apparatus and system in corresponding configurations. In addition, a computer program product is proposed with control commands that implement the stages of the method.

US 5463772 A1 shows devices for reading and writing active data memory with a specified file system.

WO 2005/086039 A2 proposes a method for creating storage media with a structured record of information, and for this purpose proposes data transformation and the use of a universal data model.

WO 2018/031794 A1 shows a method for recording on a storage medium.

US 5,742,818 A shows a method for converting a file system.

The prior art addresses a compatibility issue when attempting to access data memory from a terminal. For example, the end device does not support the file system under which the memory operates. The prior art assumes that in case of incompatibility, i.e. when working with different file systems, the file system of the data memory is usually converted. In this way, the file system of the data memory is converted into a file system supported by the terminal. This is a complex process and the data on the media is also lost.

Transferring or converting from one file system to another is often accomplished by formatting the entire data memory. Formatting is based on erasing all data in storage during restructuring. It is empty at the start of a write operation. This leads to additional problems, such as the need to back up data or possible data loss.

In addition, the implementation of emulation is known from the prior art, when the functionality of the target system is imitated. Emulation is also a complex process and requires significant effort to provide a layer of abstraction to the underlying hardware and software of the target system. Emulation itself often takes a long time. In addition, for exchanging information with a passive data memory, these implemented functions are redundant. This usually does not provide much functionality. In contrast, the main purpose of data memory is to simply act passively and exclusively store static data. Therefore, emulation also takes a long time and is prone to introduce errors when used.

Thus, the prior art has the disadvantage that there is no way for an end user to connect a passive storage medium to a terminal in such a way that the file systems used are always compatible. The techniques used are complex, and complex conversion of the entire file system is usually performed during the preparation phase. However, this is considered to be disadvantageous for the user since he usually wants to write data to the medium in real time and thus is not inclined to resort to formatting. If this results in a risk of loss of user data, such procedures will not be accepted.

Thus, the object of the present invention is to provide a method that allows a user to connect a passive storage device to a terminal without causing file system compatibility problems. Therefore, it must be possible to access data independent of the file system, which does not entail data loss and can be carried out in real time. It is also an object of the present invention to provide a suitably configured device and a suitably configured system. In addition, a computer program must be provided with control instructions that implement the proposed method or control the device or configured system.

The goal is achieved in a manner consistent with the description in claim 1. Additional preferred configurations are indicated in the related claims.

Accordingly, a method is provided for dynamically establishing file system compatibility and accessing data independent of the file system in real time, including providing access to a file system of a passive storage device to an active terminal device and a simulator that are connected to transmit information between the passive data storage device and active terminal; a method of receiving an access request from an active terminal using a simulator, wherein the access request specifies access data and an access operation to a passive data memory; recognition of the passive data memory file system by the simulator; selecting stored access rules that are suitable for fulfilling the access request in accordance with a predefined passive data storage file system; application by the simulator of selected rules to access the data specified in the access request; performing access operations as requested.

According to the invention, dynamic establishment of file system compatibility occurs in such a way that the hardware of the storage medium is not emulated, but instead adaptation is performed at the data or file level so that data from the terminal can be written to a passive data memory. The hardware is not simulated, the work is done at the file level, which does not require emulation. The passive data memory is also software-free, so there is also no need to assign function mappings. Data memory typically supports only passive read or write operations. This allows the proposed method to be used in real time.

According to the present invention, real time means no significant delays, that is, the user does not notice any delays. Individual steps in the process can be completed in fractions of a second, giving the end user the impression that the process is happening in real time. From a technical point of view, there is certainly a processing time, which, however, cannot be noticed by the human user.

According to the invention, the method avoids the need to emulate or transfer file systems in the preparatory stage of implementing the method. Thus, the end user can connect the storage medium or passive data memory to the terminal using the simulator and immediately begin reading and writing operations on the data memory. This means that the data in the data memory can be accessed independently of the file system. Data access means that both read and write operations are supported on the storage medium.

To do this, you must provide access to the file system. Granting access is also called a MOUNT operation. In this case, you can read information about the file system of the passive data memory and from that moment have information about what data is in memory. This does not require a significant investment of time, so from the user's point of view this step of the process can also be carried out in real time, i.e. without waiting. After access to the file system is granted, the data memory is associated with the active terminal for information transfer, and the simulator is located between them. Providing access includes, for example, connecting connectors between the data memory, the simulator and the active terminal.

The connection of the connectors can be done in such a way that the passive data memory is connected directly to the simulator, which in turn is connected to the active terminal. However, it is also possible to provide a wired connection between the data memory, the simulator and the terminal. According to one aspect of the present invention, access is provided through a physical connection between a storage device, a simulator, and a terminal. One skilled in the art will know the basic methods for doing this, as well as the methods for designing such connector connections. USB is an example, so well-known interfaces can be used for this purpose. So the passive storage device could be an external hard drive, a USB flash drive, or an SD card slot.

The simulator may be designed as a separate hardware device and may, for example, have a data memory containing access rules. The simulator can also be implemented as an embedded system that provides or implements control logic. Typically, the simulator includes at least two interfaces: a passive storage device communicating with the simulator through an interface, and an active terminal communicating with yet another interface. In general, it is also possible to provide additional interfaces so that multiple storage devices can be connected. You can also connect multiple active end devices so that they can perform write or read operations on data memory.

Passive data memory does not implement individual functions, but serves only to store data and therefore can be called passive. The corresponding write and read operations are initiated and transmitted by the active terminal. Thus, the active terminal initiates the method according to the invention to access the passive data memory. The active terminal stores data that is organized according to the existing file system, or requests data that is stored in the passive data memory. According to the invention, the corresponding data is adapted depending on the supported file system of the active device.

Typically, the active terminal supports the first file system, and the passive storage device is controlled by the second file system. If data is then written to passive memory, the data in the first file system format is adapted to be stored in the second file system format. If data is requested from memory, it is translated from the second file system format so that it matches the first file system format. Typically, there is no need to adapt user data for this purpose, only additional data needs to be adapted. For example, metadata can be modeled so that it can be written to memory or stored on the active terminal. Additional data may describe user data or contain file system information. The additional data may also include an offset indicating the physical location of the corresponding data blocks on the storage device.

The simulator accordingly receives an access request from the active terminal, wherein the access request specifies the data to be accessed and the access operations in the passive data memory. Access operations can be read operations or write operations, and access data describes what exactly is to be requested or transferred. The access data may, for example, indicate the name of a file to be written to the data memory in accordance with a write access operation. The access request is initiated by the active terminal and specifies the required data without affecting the file system.

The file system of the passive storage medium is then determined by the simulator. The simulator acts as an intermediary between the active terminal and the passive data memory. Thus, all messages and commands pass through the simulator. Thus, the connected communication participants, that is, the active terminal and the passive storage device, exchange data only through the simulator.

In addition, there is a selection of stored access rules that are suitable for fulfilling the access request in accordance with the previously defined passive data storage file system. Stored access rules can be determined, for example, empirically or can be created during the preparatory phase of the process. Access rules describe how data should be modeled so that once it is received from the first file system, it can be interpreted by the second file system. Additional data, such as metadata, is typically adapted at this stage such that files or data in the first operating system format are encoded according to the second operating system format. If, for example, a write operation is performed, the active terminal transfers files in the format of the first file system or in the format of the file system on the active terminal. They are then modeled according to access rules so that they can be stored in a second file system or file system format. If, on the contrary, a read operation is performed, the data of the second file system is transformed so that it can be interpreted by the active file system. In this way, the data is converted so that it can be stored in the file system of the active terminal.

The access rules can be selected to maintain a table that describes the active terminal's file system in the first column, the passive data storage file system in the second column, and the provided access rules in the third column. The third column may contain a pointer to the corresponding access rules. FAT, FAT32, ExFAT, NTFS and others can be used as file systems.

A data memory with access rules is usually built into the simulator, or the data memory may also be present in the form of an external memory from which data is read. Likewise, the data memory can also be located in the active terminal.

Thus, access rules describe the rules for transforming data for writing or reading so that it is in the appropriate format in each case. That is, analysis of the access data may be provided such that the payload data is separated from other data and the other data is converted into a file system format. Custom data conversion is also an option, with typically only additional data or metadata being converted. In this way, modulation can be performed very efficiently, and therefore the method can be carried out in real time. This way, additional data conversion can be done quickly because it is the data that is being adapted, not the file system, and typically only the metadata is being adapted. This is a very small amount of data that can be adapted without much technical effort.

If access rules are selected, they are applied to the access data, which means that the data being read or written is adapted so that it can be written to the file system of the passive data memory, or when the data is read, it is adapted so that it matches the file system of the active terminal . As already described, it is often sufficient to simply encode or model the additional data rather than the payload data.

Since the data is converted so that it is in a compatible format, the access operations step can be initiated. Access operations can be either read or write operations. Since the data is available in the desired form, it is written to the passive data memory or read from the passive data memory.

The method steps may be performed iteratively such that selected access rules are applied and access operations are performed on a specific data stream. For example, a set of files may be requested by an active terminal, and according to the access operations, it can be determined whether a one-time adjustment of the access data is sufficient or, for example, the access rules must be reapplied after each file write operation. This means that the metadata can be adapted for each file, or that the metadata is adapted only once and all user data is overwritten. The procedure can be stored in the simulator's data memory.

According to one aspect of the present invention, providing access includes a mounting process, embedding a passive storage medium into a simulator, embedding a passive storage medium into an active terminal, a communication connection, establishing at least one connector connection, activating access, setting access rights, and/or transferring data. The advantage of this is that the data memory can be read when access is granted, and therefore the available data can be evaluated during the read operation. For example, file sizes can be known and it can be determined how the data stream being read is structured. Depending on this information, you can optimize the application of selected access rules and the execution of access operations. If, for example, there are many smaller files, individual groups of files may be read as a stream of data, and therefore the application of the selected access rules applies to several files. If the files are large, access rules can be applied to each file. The connection allows the active terminal to communicate with the passive data memory via the simulator. It is also possible to implement additional security mechanisms, for example, you can assign access rights.

According to another aspect of the present invention, the active terminal has an operating system that generates an access request. The advantage is that data streams can be specified in advance and therefore it is known which files are being requested. In this way, the operating system can indicate that a large number of files must be read or written, and therefore the selected access rules can also be applied to one or more files. Consequently, the access data can be segmented and adapted as a whole, or individual segments, i.e. individual data streams, can be adapted. In this way, small amounts of data can be combined, and access rules are applied only once. This means that such files can be written and there is no need to adjust additional data each time.

In accordance with yet another aspect of the present invention, the application and implementation are performed iteratively for each data stream, wherein the operating system determines the data stream. The advantage is that applying access rules and performing write operations can be performed as often as desired, so that after the last iteration, all access data is read or written. In this way, data streams can be selected depending on the files requested or specified.

According to another aspect of the present invention, the access request has at least one read and/or write request. The advantage is that passive data memory can be read or written. In this case, there is no need to emulate the functionality of passive data memory. Rather, according to the invention, there is adaptation of the (meta)data to be written or read, and there is no direct adaptation of the file system to the passive data.

According to another aspect of the present invention, the access request specifies payload data and/or additional data. The advantage is that the access request already specifies which data is user-specific and which is optional. The additional data may be, for example, metadata describing the payload. Such additional data is the file size or file name. If the file system does not support certain additional data, such as using a different character set, access rules are enforced so that the file name is changed to match the file system's character set. For example, the active terminal wants to write files to the passive data memory and specifies user data with file names with an umlaut. If umlauts are not supported in the data storage file system, the access rule stipulates, for example, that umlauts are replaced by another vowel or a vowel and the letter "e".

According to another aspect of the present invention, the access data describes file names, absolute memory addresses, relative memory addresses, file types and/or properties. The advantage is that the access data describes what information potentially needs adaptation. If the passive data memory system only supports certain addresses or has only a certain size, the transmitted memory addresses are adapted so that access data can be written to the data memory. If files are read, these access data can be adapted so that they can be stored in the file system of the active terminal.

According to another aspect of the present invention, access operations describe read and/or write operations. The advantage is that access operations describe how individual operations should be performed. Reading or writing methods can be described for each file system.

According to yet another aspect of the present invention, access rules describe modulation operations that determine how additional access data data should be modeled so that the access data is read and/or written in accordance with the file system. The advantage is that the access rules specify transformations or modulations that transform certain access data such that, if it is formatted by the first file system, it is reformatted so that it is compatible with the second file system.

According to yet another aspect of the present invention, access rules describe how data in a first file system format is to be written to and/or read from a second file system. The advantage is that the conversion can occur from a file system that may be present on the active terminal and a file system that is present on the passive data memory. Thus, access rules describe encoding data or the process of adapting additional data. Typically, only the side data needs to be adapted, not necessarily the payload data.

According to yet another aspect of the present invention, a passive storage medium comprises a storage medium such as a USB flash drive, a hard drive, a memory card, a server, a network component, a DAS, a NAS, and/or a local storage device. The advantage is that standardized specifications as well as a large number of storage media can also be used. In this case, it is also possible to access several passive storage devices. NAS stands for Network Attached Storage. DAS stands for Direct Attached Storage.

According to another aspect of the present invention, the active terminal is a television device, printer, router, DAS, NAS, portable terminal, fixed terminal, computer, telephone or network component. The advantage is that the active terminal can be implemented in a variety of ways, and a common method is created that makes completely different file systems compatible.

Another aspect of the present invention is its ability to distinguish between access requests and decide whether to request access to user data or metadata. Depending on the type of access request, the request is either redirected to passive memory without modification of the data, or the metadata is brought into the appropriate format using translation rules.

Another aspect of the present invention is its ability to retrieve only a portion of metadata from passive memory for sending to the terminal. Thus, only the most necessary information about the requested files is provided in real time and with a short response time.

Another aspect of the present invention is its ability to make available as separate memory only a certain part of the passive memory, which can then be provided by the terminal (usually a specific subdirectory with its contents).

Another aspect of the present invention is its ability to pre-select and thus decide on the availability of file systems for the terminal. This is done either by using a switch or by using predefined files on the external media, such as makeas.exFAT, which instructs the simulator to create external memory with the exFAT file system. In this way, the simulator can make the exFAT file system available to the end device, since this file system has been widely used since its specifications became publicly available (the open source exFAT implementation is maintained by Microsoft developers) and is used in many embedded devices, cellular phones and other multimedia devices.

Another aspect of the present invention is its ability to compensate for the serious shortcomings of FAT32 when this file system is used on a terminal. The big drawback is the file size limit, which is 4 GB on a FAT32 system. FAT32 imposes an additional limit on the number of addressable files in the same subdirectory, which is 65534. External media running FAT32 is likely to be supported by older endpoint models and their limitations may also be a user consideration. You can continue to work with it. The present invention solves the problem associated with large files by allowing the terminal to access multiple files with a maximum allowable size of 4 GB.

The second limitation of FAT32, namely the maximum number of addressable files in a single subdirectory 65534, affects usage if all files are in the same directory or subdirectory. Although it is very unlikely that one would have to retrieve information from a subdirectory with more than 65,534 files, in this case the present invention would inform the user that the limit has been reached and those 65,534 files cannot be accessed at the same time. This way, the user will know that not all files can be displayed on the device, but are still available.

According to one aspect of the present invention, it is assumed that the terminal exclusively supports FAT32. FAT32 support in an end device is used if its modules or components (such as installed file system drivers) can access local, external, or virtual memory in FAT32 format to create, restore, update, or delete files and directories.

Memory is defined in accordance with one aspect of the present invention as a block device, which means that basic operations consist of read and write blocks that are addressed by an offset or location in memory. It is assumed that the end device has a USB interface for connecting to external storage media.

The assumption of FAT32 support in the terminal is generally for illustrative purposes only and is not intended to limit the possible applications of the present invention to the FAT32 system. The assumption that the terminal has a USB interface for connecting to external storage media is also taken as an example and is not intended to limit the possible applications of the present invention to connection via a USB interface. When standards such as FAT or FAT32 are mentioned here, it usually refers to a file system.

The object is also achieved by using a simulator that can be connected between the passive data memory and the active terminal and is configured to allow the active terminal to access a file system of the passive data memory, wherein the simulator is also configured to receive an access request from the active terminal, wherein in the request access specifies access data and access operations to the passive data storage device and further contains information for recognizing the passive data storage file system, and the database module is configured to select stored access rules that are suitable for executing the access request in accordance with the recognized passive storage file system data, and further configure the simulator to apply selected access rules to the access data that are specified in the access request, and are further configured to provide access operations in accordance with the access request.

The simulator is suitable for use in the proposed method. In addition, the simulator can be used in the proposed system configuration.

The goal is also achieved by system configuration to dynamically establish file system compatibility and file system independent data access in real time with at least one interface module configured to provide passive data memory file system access to the active terminal and simulator. which supports the passive data memory, and the active terminal is connected between them; the simulator is configured to receive an access request from the active terminal, wherein the access request specifies access data and access operations to the passive data memory; the simulator is configured to recognize the passive data memory file system; a database module for selecting stored access rules that are suitable for executing an access request in accordance with the recognized passive data memory file system; the simulator is configured to apply the selected access rules to the access data that are specified in the access request; and a passive data memory configured to perform access operations in accordance with the access request.

The object is also achieved by a computer program product with control instructions that implement the method and control the proposed configuration when executed on the computer.

According to the invention, it is particularly preferred that the method can be used to operate the proposed devices and modules or system configuration. The proposed devices and devices are also suitable for implementing the method according to the invention. Thus, the device or system in each case implements structural elements suitable for carrying out the corresponding method. However, structural elements can also be developed as method steps. The proposed method also includes stages of implementing the function of structural elements.

Additional advantages, elements and details of the invention will appear from the following description, in which aspects of the invention are described in detail with reference to the drawings. The elements mentioned in the claims and description may be essential to the invention individually or in any combination. The elements mentioned above and described can also be used individually or together in any combination. The terms “left”, “right”, “top” and “bottom” as used in the description of exemplary embodiments refer to the drawings in an orientation with commonly read drawing legends and reference symbols. The embodiments shown and described are not to be construed as definitive, but are illustrative for explaining the invention. The detailed description is provided for the information of those skilled in the art; Therefore, in the description, known circuits, structures and methods are not shown or explained in detail so as not to complicate the understanding of the present description. The pictures show the following:

FIG. 1: Block diagram of a known system configuration;

FIG. 2: Block diagram of a system for dynamically establishing file system compatibility and real-time data access that is file system independent, in accordance with an aspect of the present invention;

FIG. 3: Block diagram of a system for dynamically establishing file system compatibility and real-time data access that is independent of the file system, in accordance with another aspect of the present invention;

FIG. 4: Flowchart of a method for dynamically establishing file system compatibility and real-time data access that is file system independent, in accordance with another aspect of the present invention;

FIG. 5: Flowchart of method steps that can be performed by the simulator;

FIG. 6: Flowchart of steps of a method according to the invention for processing an access request;

FIG. 7: Flowchart of steps of a simulator method for reading file system parameters from passive memory according to the invention;

FIG. 8A, 8B: Tables for illustrating steps of a method for applying stored access rules according to one aspect of the present invention;

FIG. 9A, 9B: Tables for illustrating steps of a method for applying stored access rules according to another aspect of the present invention;

FIG. 10: Tables for illustrating steps of a method for using stored access rules according to one aspect of the present invention;

In fig. 1 shows a system configuration in accordance with the prior art. The storage medium is located on the left side and the terminal device is on the right side, only the connection of the connectors is shown on the right. The simulator is designed in such a way that the hardware is emulated on both the right and left sides. This is the case in the prior art because the device in the middle is suitable for forwarding control commands to peripheral devices. Thus, the current state of the art does not typically provide a passive storage medium, but rather a peripheral device such as an input device may be connected. Thus, the prior art also requires emulation of functionality, which is not necessary according to the invention.

As can be seen from the presented Fig. 1, a particular disadvantage of the prior art is the need for emulation by emulator 1 on the left side and emulator 2 on the right side. Thus, the state of the art requires that all connected terminals must be emulated, which requires significant technical effort and may even lead to errors.

According to the invention, this disadvantage has been overcome in the current state of the art, and it has surprisingly been discovered that adjustments are only necessary at the file or data level. In addition, the state of the art does not allow compatibility to be determined in real time. If, for example, there is actually a storage medium on the left, then the state of the art provides for adaptation of the file system. According to the invention, it is not the file system that is adapted, but only the data to be read or written.

In fig. 2 shows a system configuration in accordance with the present invention. The passive storage medium is located on the left side, and the active terminal, which is not shown, is located on the right side. In the middle there is a simulator M, which is connected between the storage medium and the terminal for information exchange. For this purpose, connections via connectors can be provided on both the left and right sides, or cables can be provided in each case.

In fig. 2 also shows in the lower part a data memory which stores the access rules in the simulator M. The data memory may be located external to the device, the data memory being preferably built into the simulator. It is particularly advantageous compared to the current state of the art that according to the invention it is not necessary to provide emulation components 1, 2, but instead it is sufficient to provide a modulation unit. It is located in the center of the M simulator.

In fig. 3 shows the proposed system configuration in another view, with a connector connection provided for the passive data memory on the left side and a cable connection provided on the right side. Another implementation is possible, and the cable connection could be located on the left side. The interfaces used can be designed according to standard specifications. Preferably, the interfaces are implemented in the USB standard.

In fig. 4 shows a flow diagram of a method for dynamically establishing file system compatibility and file system independent data access in real time to provide passive memory file system access 100 to an active terminal and a simulator M that is connected between them to transfer information between them. ; receiving 101 an access request from the active terminal using the simulator, wherein the access request specifies access data and an access operation to the passive data memory; recognizing the passive data memory file system 102 by the simulator; selecting 103 stored access rules that are suitable for fulfilling the access request in accordance with the predefined 102 passive data memory file system; the simulator 104 applying selected rules to access the data specified in the access request; perform 105 access operations as requested.

One skilled in the art will recognize that steps may have additional sub-steps and, in particular, each step of the method may be performed iteratively and/or in a different order.

All the following processes are described from the point of view of the end device, which is controlled by the user as the main actor.

In fig. 5 shows what actions the simulator 202 can perform in accordance with the invention when the terminal device 201 generates read access requests. In this case, the terminal supports FAT32 as a file system, which will henceforth be called file system 1.

According to one aspect of the present invention, access requests are made through a communication interface between the terminal and the simulator: the USB interface 204.

According to one aspect of the present invention, two methods are implemented in the simulator. A method for storing additional data 206 and a method for simulating data 207. If data is read from the passive memory 203, this process is performed using the communication interface 205. However, it is not necessary that the passive memory also be connected through the USB interface to which the simulator is connected 205 as well can be replaced by a data bus so that the passive memory is implemented directly as a component of the simulator.

According to one aspect of the present invention, the sequence of events depends on which access requests have been initiated by the terminal, whereby a simulator that already has passive memory attached is connected to the terminal. Depending on the version of the end device, this order may differ from the following illustrations.

According to one aspect of the present invention, the terminal communicates with the simulator in two ways: on the one hand, the terminal operating system component responsible for USB devices must recognize the simulator connected via USB as an external USB memory device. On the other hand, another component of the operating system must determine how the attached storage device should be accessed at the logical level, in particular what file system can be defined in memory.

For first communication using the USB protocol, according to one aspect of the present invention, it is at least necessary for the simulator to have important parameters, such as reporting the number of addressable blocks or block size, as necessary actions within the scope of USB protocol support. For this purpose, a so-called 301 identification request can be initiated, which, however, may not be mandatory depending on the operating system implementation. Specific actions in accordance with the USB protocol are not discussed, since this protocol can essentially be performed by one skilled in the art without any problems. It should only be noted that this first identification request already causes the simulator to be aligned accordingly, and the data required to process such identification requests (number of addressable blocks) must remain available.

According to one aspect of the present invention, the first necessary action on the part of the simulator to do this is to read file system parameters from passive memory 314, as shown in detail in FIG. 7. The file system in the passive memory, hereinafter referred to as file system 2, is recognized by the simulator at run time 314, wherein the data read is not limited to satisfying the first identification request, but instead is first converted in accordance with the invention such that it is used in as boot sector data of file system 1, and then also stored in the simulator 206. Thus, the essential parameters for the identification request are also sufficiently defined (number of addressable blocks, block size), the simulator performs the identification request 310 in accordance with the USB protocol.

In the next step, the terminal operating system must determine how the attached storage device should be accessed at the logical level, in particular, what file system can be defined on the storage device.

To do this, the terminal can generate at least one access request aimed at reading at least block 0 from memory, since it contains information to determine the file system.

To fulfill this access request, according to the invention, the following steps can be performed, which are shown in FIG. 5 as an example.

First access request 311 terminal: read sector starting from position 0.

In a first step 312, according to one aspect of the present invention, it is checked whether the requested data is already stored in the simulator. It is possible that the terminal identification request 301 has not yet been made, but has been replaced by an access request 311. Although the passive memory parameters would not yet be known to the end device when executing 311, this does not prevent the end device from generating an access request 311 because position 0 can always be read when the storage device is addressable. As an example, it is assumed that the 301 identity request has not been made in advance. Thus, the data for the first sector at position 0 is not yet stored according to 206.

In a second step 313 according to one aspect of the present invention, it checks which data from the point of view of the file system 1 is involved when the sector is read from position 0. Therefore, the action 313 would typically be described such that the read process checks whether the data is optional or user data, and, if it is user data, from which file from the point of view of file system 1 it is obtained.

Access rules are used for this. As shown above, access rules define how metadata from one file system should be converted to metadata from another file system. These rules also determine which file system areas provided for file system structures correspond to similar areas of another file system, and thus determine whether an access request includes metadata as additional data.

According to the existing access rule 400, it includes special additional data, in particular the so-called boot sector if the sector is read from position 0.

According to the access rules, the boot sector for file system 1 is summed up 314 in such a way that all file system parameters (file system size, size of logical blocks in the file system (the so-called cluster), starting position for the first directory, etc.) are already sufficient defined. This assumes that this data must be available to the terminal device to process the very first access request 311. Basically all parameters of the file system 1 are obtained or calculated from the corresponding parameters of the passive memory file system 2. Access rule 401 contains this method, in particular, it specifies how the parameters of file system 1 depending on file system 2 are to be calculated for the corresponding file system 1/file system 2 combination and which specific access rule is used. The figure shows how this 401 boot sector access rule is applied. This application does not cause problems because the file system size is known and the logical block size can be taken from file system 2 (if this is not possible, additional access rules apply to the block size setting) .

Thus, the simulator has simulated and stored data for sector 0 so that the terminal can use it to initiate further access processes.

According to one aspect of the present invention, the specific present request 311 is executed when simulated boot sector data is provided.

The requested data 315 is provided via a communication interface (USB in this case). Thus, the access request 311 is completed.

The fact that the first access request results in reading the FAT32 boot sector as block 1 determines the further actions of the terminal.

In principle, according to one aspect of the present invention, it can be assumed that if the first block is recognized as a valid boot sector with valid contents (file system parameters), the terminal device operating system continues access requests to determine the file system on the memory provided by the interface USB. This process can also be called "polling", the purpose of which is to recognize memory as a specific, logically organized file system and expose its own logical interface (the so-called "mount point") within the operating system.

Alternatively, after the first access request has been granted and the contents of the first block appear to resemble the boot sector, the terminal operating system can also send a message (called a "broadcast message") to its components or applications to inform them of the presence of a new drive. As a result, the responsible file system component and driver can initiate another process, often called a "mount".

Both options lead to the same result, namely that the new available memory is recognized as FAT32 and can be accessed as a logical file system by the end device operating system or at least one of the components or applications.

According to one aspect of the present invention, mounting this file system for read-only operations or also for write operations depends on the following factors: the operating system of the terminal, the amount of support for the corresponding file system, and the task that the terminal has for external mountable media. The following explanations apply to read-write mode. The case where the file system is mounted into memory only in read mode does not need to be considered separately, because the method proposed according to the invention can even more so be used for read mode if it leads to the expected success in read-write mode.

Thus, further access requests from the end device depend on what tasks are scheduled in the event of a New Memory Available event. The terminal may be running a specific application that is trying to read the contents of the detected memory, meaning that the contents of the root directory are accessed first. If no application starts automatically, the user who connects the simulator to the device takes further action to recall the contents of the memory and starts with the action "call the contents of the root directory" to then determine further actions. To get the contents of the root directory, the user can also enter terminal commands such as "dir" or "ls". At best, you can expect the terminal device to try to read the contents of the root directory on the next access request. To fulfill this access request, the following actions can be performed according to the invention, which are also shown in FIG. 5 as an example.

In accordance with one aspect of the present invention, it is assumed that the root directory area begins at sector X, occupies 100 sectors, and this was determined by the rule applied to step 314. Accordingly, in the second read access request 321 there will be: 100 sectors read, starting at sector X.

In a first step 312, according to one aspect of the present invention, it is checked whether the requested data is already available. In this case, the data is not yet available because until now the terminal has only read sector 0.

A second step 313 checks which data from the point of view of file system 1 is involved if 100 sectors are read starting at position X. Access rules are used for this.

According to access rule 400, this is what is called the root directory if sector X is accessed for the simulated file system, specifically the entire requested length (100 sectors).

In order for the simulator 202 to store 206 data for the root directory of the terminal, in the next step 324 (see FIG. 9) additional access rules are applied such that metadata is generated in real time for files in the root directory of this file system 1 in the root data format catalogue.

Thus, this metadata is suitable for overwriting files in file system 2 such that each terminal component that supports file system 1 (in this case FAT32) interprets it as if these overwritten files were stored in the simulator. According to the invention, this metadata is stored 206 for current and future access requests from the terminal.

Applying access rule 324 may require reading additional metadata from file system 2 to obtain complete information about which files in the root directory structure are addressed by the requested 100 sectors and what their size is, and method 404 (see FIG. 10) to determine in which areas of file system 2 the files mentioned above are located.

As an intermediate result, when simulating the root directory in a file system 1 format, more data may be read than requested, which is not harmful because such data, which is initially read redundantly, remains available for further access rule applications.

The actual read access request from the terminal from step 321 is fulfilled by providing 100 sectors modeled using the access rule.

The requested data is provided to the 325 via a communication interface (USB in this case). Thus, the access request 321 is completed.

Once the contents of the root directory are made available to the terminal, its application can prompt the user to perform further actions, such as opening files or selecting file contents for specific processes (printing, playing video/audio files, etc.). At this point, the file's contents must be accessed from external media, and the target device's operating system component (or its file system driver) must issue requests to the mounted logical volume to obtain the required content from the file.

In accordance with one aspect of the present invention, it is assumed that the contents of the file ABC.ZYZ are being accessed, and the file size is assumed to be 10 blocks.

To fulfill this access request, the following actions can be performed according to the invention, which are also shown in FIG. 5 as an example.

Access request 351 is initiated, which consists of reading 10 blocks from position Pos1, which correspond to the first cluster of file ABC.ZYZ SC1 in file system 1.

This data has not yet been requested, so 206 is not yet available.

The first step is to determine whether this request includes user data or additional 313 data.

The fact that this request concerns user data already follows from the fact that when modeling FAT 402 structures to execute request 321, the size of the ABC.XYZ file was taken into account and there is a continuous modeled chain for its contents in the file allocation table.

That is, the modeling method 402 is suitable for placing existing files of file system 2 in the simulated file system 1 such that they are not fragmented, regardless of whether those files in file system 2 arise from multiple fragmented pieces of content.

Thus, it was the user data that was read using access request data 351.

In a next step 354, according to one aspect of the present invention, it is necessary to verify what user data is actually being accessed. It is possible that the end device may request access to multiple files, not just ABC.XYZ. This is determined by method 404 (see FIG. 10), which determines which files in file system 2 are actually accessed when certain blocks are accessed from the point of view of file system 1. Thus, this method 404 is suitable for determining further actions that should be taken. taken in specific contexts for the contents of various files when accessed. This context establishes that when certain blocks are read from file system 1 that correspond to user data, the corresponding blocks to read are always identified in file system 2. As a result, the user data is read by a corresponding access request 355 directed to passive memory. Process 355 is repeated until all data requested by request 351 has been read, unless the requested content is located on file system 2 in a continuous chain.

The requested data is provided to the 356 via the communication interface (USB in this case). Thus, the access request 351 is completed.

After providing the contents of the root directory to the target device, its application can prompt the user to take further actions, such as storing data generated on the target device on a mounted logical volume. If, for example, new documents are being scanned, a mounted logical volume can be selected as the target storage.

It is assumed that the end device attempts to create this user data as a file named XXX.ABC in the root directory of file system 1 after 19 blocks of user data have been generated on the end device, and the contents of the newly created XXX.ABC files starting with positions Pos2.

Moreover, in accordance with one aspect of the present invention, it is assumed that the terminal does not create an access request whose purpose is to describe the name and size of a file in the root directory of file system 1 for a new file if user data has not yet been defined, and such a request is made only in the event that all user data for this newly created data is described.

The reason for this assumption is the possibility of implementing a method for optimizing read and write access requests on the terminal.

If it is assumed that the terminal is attempting to write user data before the metadata for the corresponding file has been described by another access request, there is an ambiguity in the sense of method 404 in that new blocks to be written cannot yet be assigned to the file. However, this waiting state ends no later than the generation of an access request by the terminal to update the metadata of newly created files in memory.

To fulfill this access request, the following actions can be performed according to the invention, which are also shown in FIG. 6 as an example.

Access request 331 is initiated, which consists of writing 19 blocks, starting at position Pos2, which correspond to SCN + 1.

First, it is necessary to check 332 whether this write data 206 is available. Since the data at position Pos2 has neither been read nor written, it is also not available yet.

The next step is to determine whether the request is for user data or additional data 333. Therefore, action 333 would typically be described such that the recording process checks whether the request is for additional or user data and, if it is for user data, from which file from the point of view of file system 1 they are obtained.

This cannot yet be clearly defined because these blocks are not stored either as metadata 206 or as user data in the sense of 351. In the next step 334, in accordance with method 405 (see FIG. 9), it is initially assumed that user data is involved , and blocks to be written are processed accordingly. This begins the so-called floating state, since blocks cannot yet be assigned to the file. The simulator will store the data to be written as user data until further notice 206, but the completion of the writing process is reported 335 through the communication interface 204. Thus, the access request 331 is completed.

It is assumed that when updating the contents of the root directory for file system 1, an additional access request 336 is initiated, which is intended to write the block starting at position X + 99. Specifically, this is the last sector of the root directory.

First, it is necessary to check 332 whether this write data is available 206. This is the case in this case because the block at position X+99 has already been modeled 324 and reserved 206 in step 321 as the root directory for filesystem 1.

If a block of data is already available and if it is metadata, the application of access rules can be used to determine 339 which specific changes are involved. A corresponding method is shown 406 in FIG. 9, which consists of qualifying changes to the root directory structure and defining them as an abstract description from which it can be inferred what corresponding changes should be made to file system 2. This is a new entry for the file XXX.ABC, which was not previously in the root catalogue. This change can be described as if the end device needs to create a new file called XXX.ABC with a size of 19 sectors, starting with Pos2. This abstract description of an action may also be similar to the description in the Posix standard.

In a next step, according to one aspect of the present invention, the specific change is to be applied to file system 2 by converting the abstract description into a corresponding passive memory request. As a result, an entry is created on file system 2 for data XXX.ABC, which, however, does not yet indicate the starting position of this file on file system 2, although the starting position is already specified on file system 1. This implies that the pending state is still There is uncertainty in the sense of 404 regarding the assignment of user data of specific files to file system 1. However, this uncertainty is resolved by an access request aimed at updating the area using FAT - more on this later.

Finally, completion of the write process is communicated 340 via communication interface 204. Thus, the access request 336 is completed.

After the end device or its application has completed all necessary user tasks, such as scanning documents and placing that data on external media or transferring other user content, the external media can be disconnected from the end device.

Some end devices explicitly ask the user to disable the external device in order to be able to ensure data security for these processes. The user will then only be responsible for possible data loss if he removes the external media before the end device requests the unmount process that was expected to complete before the removal of the external media from the end device takes place. This secure method of disconnecting external storage is not easy to implement as a standard because users are impatient when it comes to disconnecting external storage from the end device. They do not wait for the unmount process to complete, which takes time, but rather simply want to remove the external storage media once the device activities are completed and the device is in a standby state, which can be easily understood by the end device. To meet these user expectations, the terminal device operating system typically supports synchronization technology for the file system driver so that it can work with external storage media.

This technology always keeps external storage media up to date by clearing the contents of file system data stored in the main memory of the target device - usually initiated by the operating system itself. This means the following. After an end device or its application has completed its tasks, which may involve external storage media, and has entered a standby state (and awaits further action or instructions from the user), a file system driver or similar component can clear blocks that are not yet were not recorded on external media - this ensures data security if the external media suddenly turns off. This synchronization method results in additional requests to access external memory.

To facilitate such an attempt to read and write using FAT, the following actions can be performed in accordance with the invention, such as reading FAT from file system 1.

It should be noted that a FAT read access request occurs no later than the first attempt to read a file after mounting or the first attempt to access a subdirectory after mounting.

Since the FAT (FAT Allocation Table) is a table that defines the placement of files in file system 1, such structures do not exist in any way in file system 2 and only arise through the application of access rules to the parallel structure of file system 2. As a result, the FAT is stored on the simulator 202. In addition, such structures overwrite metadata not for individual files, but for all files located in file system 1, and represent a type of additional data that is not user data.

However, FAT 324 is not modeled cumulatively for all files present in file system 2, but only for files requested 314 during an access request by directly specifying the file path) unless metadata describing its location is modeled for that file. The result of this modeling is the applicability of a method 404 that allows files to be assigned to user data.

The corresponding method is shown in Fig. 9, which consists of qualifying changes 405 to FAT and defining them as an abstract description from which it can be inferred what corresponding changes should be made to file system 2.

The first thing to note is that using access rule 400, you can easily determine whether the data for an access request is in the FAT zone.

The FAT update is expected to at least match the placement chain for the XXX.ABC file. Since write operations on the end device are performed in an optimized manner, the FAT update cannot be expected to focus only on a specific allocation chain for a specific file. Rather, FAT updates to multiple files are expected to be cumulative. Exactly what changes are expected can be determined by 405 by comparing the FAT status.

This is a new entry for file XXX.ABC for which there is no distribution chain yet. Thus, this change can be described as if the end device needs to create a continuous allocation chain for a new file named XXX.ABC, which includes 19 sectors starting at (SCN + 1).

In the next step, the target change must be applied 405 to filesystem 2, since this abstract description must adapt the structures of filesystem 2 that control the placement of user data in the filesystem. This also means that there is no longer any uncertainty regarding the assignability of user data in the sense of method 404, and this user data to be written according to request 331, which was still stored in the simulator, is now written to the corresponding passive memory location.

This not only creates an entry for the XXX.ABC data on file system 2, as was done when processing request 336, but also specifies the location of the XXX.ABC file on both file system 1 and file system 2.

Finally, the completion of the writing process is signaled through the communication interface 204. Thus, the FAT access request is completed.

Finally, it should be noted that terminal device actions performed elsewhere may occur in a different order, and all changes to filesystem 1 always result directly in an access request. As a result, the above simulator actions do not change, since always a sequential update of file system 1 results in a wait state in the sense of method 404 exception.

List of reference symbols

1 emulator 1

2 emulator 2

M Simulator

(100) - (105) see detailed description

(201) Terminal

(202) Simulator

(203) Passive storage device

(204) Communication interface (201) - (202)

(205) Communication interface (202) - (203)

(206) Additional data storage procedure

(207) Data modeling methods

(301), (310), (311), (312), (313), (315), (325), (351), (355), (356) - see detailed description.

(314) Modeling the structure of the boot sector and file system parameters

(324) Catalog data modeling

(354) Specifying user data when reading

(331), (332), (333), (335), (336), (349) - see detailed description.

(334) Specifying user data when writing

(339) Qualification of metadata changes

(314) Modeling the boot sector structure for (file system 1) based on (file system 2)

(File system 1) File system 1

(File system 2) File system 2

(BytesPerSector) Sector size in bytes: a parameter that has an original (IN) value (Value1_2) and possibly receives a new (OUT) value and a new format (Value1_1) through conversion according to an access rule (BS1)

Additional file system options or characteristics:

(SectorPerCluster) Number of sectors in the cluster

(ClusterPerVolume) Number of clusters in the volume

(VolumeLabel) Volume label

(Etc) - etc.

(FSPropertyN) Filesystem N property: another parameter in (Filesystem 2) that has an original (IN) value (ValueN_2) and possibly a new (OUT) value and a new format (ValueN_1)

(IN) initial value

(ValueN) Value of N

(Rule) rule, access rule (BS2, BS3, etc.)

(Out) final value

(BSMemberN)

(AV) Available: Availability notification for sectors reserved in (206). (EMPTY) means "not busy" - (AV) means "busy"

(Last) Last: reserved sector position

(324) Catalog data modeling

(StateNow) Current State: Current state of FAT on file system 1

(StateNow-1) Previous FAT state on file system 1, possibly unknown, not yet initialized state.

(Directory, Filesystem 1) Directory structure in filesystem 1 (simulated)

(Directory, Filesystem 2) Directory structure in filesystem 2

(File1... FileN) File 1... File N: File object names

(Ext1… ExtN) Extension 1… Extension N: file object extensions

(Size1..SizeN) Size 1 ... Size N: size of file objects.

(Sc1... ScN) Start cluster 1... Start cluster N: the first cluster of the file from the point of view of FAT. This value is modeled for file system 1 according to (402).

(Nc1ofN) Next cluster 1 of N: next cluster 1 of N

(M+1) next free position in FAT on (filesystem 1)

(402) This method simulates the FAT structures in file system 1 for files requested by file system 2. As a result, the placement of files in file system 1 is not initially fragmented.

(402a) Starting the iterative process "Reading the contents of the root directory (file system 2)"

(402b) Evaluating the definition of initial clusters for iteratively processed content.

(402c) Simulation of (file system 1) in an area with iteratively processed content

(402d) Ending the iterative process "Reading the contents of the root directory (file system 2)"

(405) Qualification of changes to FAT

(StateNow) Current State: Current state of FAT on file system 1

(StateNow-1) Previous FAT state on file system 1

(ScN) Start cluster N: the first cluster of the file in terms of FAT N

(Nc1ofN) Next cluster 1 of N: next cluster 1 of N

(LcofN) Last cluster of N: last cluster of N

(Free) free: unoccupied sector

(M+1) next free position in FAT on (filesystem 1)

(Last) Last sector: reserved sector position

(QualifiedDifferenceFAT) Evaluation, i.e. result of qualification of these changes: the difference between (StateNow) and (StateNow-1) can be described as a new chain for "Create_a_new_file"; the new chain must start from a cluster (K + M + 1) and have a length of 19 sectors (L).

(406) Qualifying changes to directory structure

(StateNow) Current State: The current state of the directory structure in file system 1

(StateNow-1) Actual State 1: Initial state of the directory structure in file system 1

(File1), (File2), (File3), (FileN) File 1, File 2... File N: names of file objects according to entries in the directory structure, from 1 to N

(Ext1), (Ext2), (Ext3), (ExtN) Extension 1... Extension N: extensions of file objects, according to entries in the directory structure, from 1 to N

(Size1), (Size2), (Size3), (SizeN) Size 1... Size N: sizes of file objects, according to entries in the directory structure, from 1 to N

(Sc1), (Sc2), (Sc3), (ScN), (Sc N+1) Starting clusters of file objects corresponding to entries in the directory structure, from 1 to N+1

(QualifiedDifferenceDir) The result of qualifying these changes: the difference between (StateNow) and (StateNow-1) can be described as the operation of creating a new file; the new file is named XXX with extension ABC, starts with (SC N+1) and is 19*512 bytes long.

(404) Determining whether user data belongs to files

(ScN) Start cluster N: the first cluster of the file in terms of FAT N

(Nc1ofN) Next cluster 1 of N: next cluster 1 of N

(LcofN) Last cluster of N: last cluster of N

(M+1) next free position in FAT on (filesystem 1)

(Free) free: unoccupied sector

(Last) Last sector: reserved sector position

(Range) Range: sectors occupied by the file system

(File system 1) File system 1

(OFFSET) Offset: in addition to the segment part, the second component (integer value) in the memory address

(Size1) Size 1: The size of the file object.

(File1_fs2) File 1 on file system 2

(File1_fs2) File 1 on file system 2

(Ext1), (Ext2), (Ext3), (ExttN) Extension 1… Extension N: file object extensions,

(Size1), (Size2), (Size3), (SizeN) Size 1… Size N: file object size

(File1), (File2), (File3), (FileN) File 1... File N: names of file objects.

Claims (26)

1. A method for dynamically determining file system compatibility and data access regardless of the file system in real time, including: - providing access (100) to the file system of the passive data memory for the active terminal and the simulator (M), which is communicatively connected between the passive data memory and the active terminal; - receiving (101) an access request from the active terminal by the simulator (M), while the access request specifies access data and access operations to the passive data memory; - recognition (102) of the file system of the passive data memory by the simulator (M); - selecting (103) stored access rules that are suitable for fulfilling the access request in accordance with the recognized (102) file system of the passive data memory, wherein the access rules are selected in such a way that a table is provided, the first column of which describes the file system of the active terminal, the second column of which describes the passive data storage file system and the third column of which contains a pointer that points to the corresponding access rules; - application (104) of selected access rules to access data by the simulator (M), which are specified in the access request; And - performing (105) access operations in accordance with the access request. 2. The method according to claim 1, characterized in that granting access (100) includes recognition of boot sectors, a mounting process, integration of a passive data memory into a simulator (M), integration of a passive data carrier into an active terminal, communication interaction, establishment of at least at least one connection through a connector, activating access, setting access rights and/or exchanging data. 3. The method according to claim 1 or 2, characterized in that the active terminal has an operating system that generates an access request. 4. The method according to claim 3, characterized in that application (104) and execution (105) are carried out iteratively for each data stream, while the operating system determines the data stream. 5. A method according to any one of the preceding claims, characterized in that the access request contains at least one read and/or write request. 6. A method as claimed in any one of the preceding claims, characterized in that the access request specifies a payload and/or additional data. 7. A method as claimed in any one of the preceding claims, characterized in that the access data describes file names, absolute memory addresses, relative memory addresses, file types and/or properties. 8. A method according to any of the preceding claims, characterized in that the access operations describe read and/or write operations. 9. A method as claimed in any one of the preceding claims, characterized in that the access rules describe modulation operations that determine how additional access data data should be modeled so that the access data is read and/or written in accordance with the file system. 10. A method according to any one of the preceding claims, characterized in that the access rules describe how to write data corresponding to the first file system to the second file system and/or read from the second file system. 11. A method according to any one of the preceding claims, characterized in that the recognition (102) of the file system includes the recognition of boot sectors. 12. The method according to any one of the preceding claims, characterized in that performing (105) write operations in accordance with the access request when the file size is limited by the file system splits the corresponding file into at least two separate files. 13. A system for dynamically determining the compatibility of file systems and accessing data in real time, regardless of the file system, including: - at least one interface module configured to provide access (100) to the file system of the passive data memory for the active terminal, and a simulator (M) that is communicatively connected between the passive data memory and the active terminal; - the simulator (M) is configured to receive (101) an access request from the active terminal, wherein the access request specifies access data and access operations to the passive data memory; - the simulator (M) is designed to recognize (102) the file system of the passive storage medium; - a database module configured to select (103) stored access rules that are suitable for executing an access request in accordance with the recognized (102) passive data memory file system, wherein the access rules are selected such that a table is provided in the first column which describes the file system of the active terminal, the second column of which describes the file system of the passive data memory, and the third column of which contains a pointer that points to the corresponding access rules; - the simulator (M) is configured to apply (104) selected access rules to the access data, which are specified in the access request; And - a passive data memory configured to perform (105) access operations in accordance with an access request. 14. A computer-readable storage medium containing a processor and memory containing control commands executed by the processor, which implement the methods according to any one of claims. 1–12.