JP5629438B2 - File management apparatus and control method thereof - Google Patents

Description

  The present invention relates to a technique for managing files stored in a storage medium.

  When files are stored and managed in a randomly accessible storage medium (such as a hard disk or a compact flash (registered trademark) memory), directories are set in several stages in the recent file system, and the file name is very long. Strings can now be handled. In such a file system, when one file is specified, the directory name and the file name until reaching the file are described and managed.

  In addition, as a virtual file name management method for virtually managing file names, a file resource management table storing file names and file positions, and a virtual file name management unit storing virtual file names, their positions, and procedure names And a procedure management table for managing procedure names and procedure definitions, and accessing a real file using a virtual file name (see, for example, Patent Document 1).

Japanese Patent Laid-Open No. 08-110869

  However, as described above, in the method of storing the full path name of each file as a management table, when a single hierarchy name is long or a file path is composed of several layers (directories), the management table Many memory resources are required to store the data.

  In the virtual file name management method as in Patent Document 1, since the capacity to be stored increases in proportion to the number of file names to be managed, many memory resources are required, and the search time for file names is also proportional. The problem of becoming longer will remain.

  Therefore, the present invention is intended to provide a technique for storing and managing each file stored and managed in a multi-level directory with a smaller amount of information and further speeding up access to file data. .

In order to solve this problem, for example, the file management apparatus of the present invention has the following configuration. That is,
A file management device having a memory for managing a file path management table for a file stored in a storage medium formatted in a file system having a hierarchical structure,
Detecting means for searching a directory entry corresponding to each file stored in the storage medium and detecting an absolute address position in the storage medium of the directory entry corresponding to each file;
The information representing the absolute address position detected by the detecting means is converted into a character string having a preset format and the number of characters, and the character string is used as a virtual file name of the corresponding file, and a file name entry in the memory Registration means for registering in the area ;
First determination means for determining the type of a file system for managing the files of the storage medium,
If the file system determined by the first determination unit is exFAT, the registration unit registers the virtual file name in the file name entry area in the memory;
When the file system determined by the first determination unit is other than the exFAT, the registration unit registers an actual file name in a file name entry area in the memory.

  According to the present invention, instead of the storage position of the file in the storage medium on the file system, it is handled as the absolute address position of the storage medium, so the memory capacity for managing the file can be reduced regardless of the file path length. In addition, because the storage location and virtual file name by the full path of the file are reversible conversions that are uniquely determined, there is no need to have a management table that compares the physical location of the file and the virtual file name, memory can be saved, and the file can be saved quickly It becomes possible to access.

1 is a block diagram of a personal computer as an embodiment of the present invention. The flowchart of the file access process of 1st Embodiment. The flowchart of the virtual file name acquisition process of 1st Embodiment. The flowchart of the file access process of 1st Embodiment. The flowchart of the file name acquisition process of 2nd Embodiment. The flowchart of the file name acquisition process of 3rd Embodiment. The flowchart of the file access process of 4th Embodiment. 10 is a flowchart of file access processing according to the fifth embodiment. The flowchart of the real file name acquisition process of 6th Embodiment. The flowchart of the character string conversion process of 1st Embodiment. The figure showing the list respectively stored in the storage area of the real file name and the storage area of the virtual file name of the sixth embodiment. The figure showing the relationship between a virtual file name, a file system, and a real file name. The figure showing the directory entry and data area of a FAT file system as one embodiment of the present invention.

  Hereinafter, embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

  FIG. 1 shows a configuration example of a personal computer (hereinafter, PC) 100 as an example of a content management apparatus in which the present invention can be implemented. As shown in the figure, the PC 100 includes a CPU (Central Processing Unit) 101, a hard disk (HD) 102, a memory 103, a display 104, an input unit 105, a recording medium drive 106, a network interface (I / F) connected by an internal bus 111. 107. The CPU 101 is an arithmetic processing unit that controls the operation of the content management apparatus, receives instructions from the user via the input unit 105 and the like, executes various programs described later, and controls display on the display 104. The HD 102 stores images and operation processing procedures of the CPU 101 (for example, a program such as computer startup processing, basic input / output processing, and each processing of the present invention described later). The memory 103 is used as a work area for the CPU 101. The display 104 is a display unit for displaying the graphic user interface according to the present embodiment, and images and display items to be described later are displayed on the display unit. The input unit 105 is an input unit for receiving instructions from the user, and is an input device such as a keyboard or a mouse as a pointing device. By using the input unit 105, the user can execute the content management program. The recording medium drive 106 is a device that reads data stored in a random-accessible external recording medium 108 such as a CD-ROM, DVD-ROM, or flash memory, and writes data to the external recording medium 108. . The I / F 107 is connected to the network 110 via the communication line 109. The CPU 101 can also execute a program on the network 110 via the I / F 107, and the present invention can also be applied to a program on the network 110.

  FIG. 12 shows a directory entry and data area of the FAT file system. In the directory entry, the file name, attribute, creation / update / modification time of the file stored in the file system, the start cluster number of the actual data, and the like are described. The actual data of the file is stored in the data area, and the location where the actual data is stored is indicated by the start cluster number of the actual data described in the directory entry.

<First Embodiment>
In the first embodiment, whether a file stored in the external recording medium 108 (storage medium formatted with a file system having a hierarchical structure) is managed with a virtual file name or an actual file name is determined. An example of automatic switching will be described.

  FIG. 2 is a flowchart of processing of the CPU 101 that handles virtual file names when the file system of the recording medium is exFAT, and handles real file names when the file system of the recording medium is other than exFAT. . The processing according to this flowchart is executed when the external storage medium 108 is set in the recording medium drive 106 as a trigger. However, for example, an instruction input by a user may be used as a trigger.

  When the file name acquisition process starts, it is determined in step S201 whether the type of the file system of the recording medium is exFAT. If it is determined that the file is formatted in the exFAT file system, the process proceeds to step S202. If it is determined not to be formatted, the process proceeds to step S204. In step S202, scan processing is performed to check what kind of file exists in the external storage medium 108, and a virtual file name having a one-to-one relationship with the name of the detected file is acquired (the virtual file). The name generation process will be described later). In step S203, the real file name or virtual file name of the acquired file is registered in the file name entry area (referred to when accessing a later file) secured in the memory 103. In step S204, the real file name described in the directory entry is acquired using the POSIX-compliant readdir function.

  FIG. 3 is a flowchart of the virtual file name acquisition process in step S202 described above. When the virtual file name acquisition process starts, in step S301, the directory entry is read and a file search (detection) is performed. Then, the process proceeds to step S302. In step S302, the physical location on the recording medium of the directory entry of the file searched in step S301 is acquired. The physical position referred to here is a sector number, a byte offset within the sector, and a starting cluster number of the parent directory, each having a data length of 4 bytes. Then, the process proceeds to step S303. In step S303, the physical position on the recording medium of the file acquired in step S302 is converted into a character string. The character string conversion here converts to an arbitrary character code such as ASCII code or Unicode, and the converted character string length is fixed regardless of the physical position on the recording medium. The character string converted here is used as a virtual file name.

  FIG. 10 is a flowchart of the process of reversibly converting information of 4 bytes in each physical position into a 6-character ASCII character string, which is performed in step S303 described above. In step S1001, the null character position (PosZero) of the converted character string, the slash character position (PosSlash) of the converted character string, and the loop counter (i) are initialized, and the process proceeds to step S1002. In step S1002, it is determined whether or not the loop counter i is less than 4. If it is determined that the loop counter i is less than 4, the process proceeds to step S1003, and if it is determined not, the process proceeds to step S1009. In step S1003, 1 byte tmp is substituted from the physical position data (Data) acquired in step S302, and the process proceeds to step S1004. In step S1004, it is determined whether tmp substituted in step S1003 is a null character. If it is determined that the character is a NULL character, the process proceeds to step S1005, and if it is determined not, the process proceeds to step S1010. In step S1005, the NULL character location is stored. Null character locations are stored by bit assignment. Then, the process proceeds to step S1006. In step S1006, the value of tmp is overwritten. In the flowchart, 0xFF is substituted, but any value can be used as long as it is not a NULL character or '/'. Then, the process proceeds to step S1007. In step S1007, the value of tmp is assigned to the character string area (Moji) secured in advance, and the process proceeds to step S1008. In step S1008, the loop counter is incremented, and the process proceeds to step S1002. In step S1010, it is determined whether tmp substituted in step S1003 is '/'. If it is determined that it is '/', the process proceeds to step S1011. If it is determined not, the process proceeds to step S1007. In step S1011, the location of the slash character is stored. The storage method is the same as that in step S1005. In step S1009, PosZero and PosSlash are stored in the fifth and fourth bytes of the secured character string area, respectively.

  The processing of FIG. 10 is performed for the sector number, the byte offset within the sector, and the starting cluster number of the parent directory, concatenated as a single character string to form an 18-byte file name, and an arbitrary extension at the end of the character string. By adding the child 4 bytes, a virtual file name of a total of 23 bytes (including 1 byte of NULL character) is obtained. In addition to the absolute address position in the storage medium of the corresponding file, the character string of the virtual file name includes the entry in the storage medium of the directory that directly manages the file (directly above the directory that manages the corresponding file). Are also included. This is to obtain the actual file name of the file.

  FIG. 4 is a flowchart of file access processing using a file name. Since step S401 is the same as step S201 described above, description thereof is omitted. If it is determined in step S401 that the format is exFAT, the process proceeds to step S402. If it is determined not, the process proceeds to step S405. In step S402, it is determined whether the file name has the format of the virtual file name acquired in step S202 described above. If it is determined that the file name is a virtual file name, the process proceeds to step S403. In step S403, the virtual file name is converted to the physical location of the recording medium on which the file exists. That is, the conversion opposite to the conversion in step S303 is performed. Then, the process proceeds to step S404. In step S404, the file stored in the recording medium is accessed using the physical location of the file obtained in step S403. On the other hand, in step S405, the specified file is opened using a POSIX-compliant open function.

  As described above, in the case of a file system that does not have a directory entry for storing a short name, such as exFAT, even if the file is managed through a multi-level directory and the file name has any number of characters, the fixed length As a virtual file name can be managed, memory resources can be saved.

  For example, let us consider a case where each layer (directory) is composed of a directory represented by an alphabet of 255 characters, a file exists in the sixth layer, and a file name is also represented by an alphabet of 255 characters. In this case, in order to store the file in ASCII, the absolute path is 1+ (255 + 1) × 6 + 1 = 1538 bytes (including drive name and NULL character). In order to store and manage 1000 similar files, a storage capacity of 1538 × 1000 = 1538000 bytes is required. According to the present embodiment, any file length has 18 characters in one layer and 23 characters in a file name, so 1 file is 1+ (18 + 1) × 5 + 1 + 23 = 120 bytes. In order to store 1000 files, 120 x 1000 = 120000 bytes of storage capacity is sufficient.

  Also, since the virtual file name is uniquely determined from the physical location of the file, high-speed file access is possible. In the embodiment, the virtual file name acquisition process is performed when the file system is exFAT because the limit on the number of characters of the directory name and the file name is looser than that of the previous file system in the case of the exFAT file system. It is. That is, more character strings than before are handled as directory names and file names, and when one file is specified by a name with a full path, the number of characters in the full path name tends to be enormous. However, even if the file system is not exFAT, in the case of another file system having a hierarchical structure, there is no change in specifying a file by a path name of a multi-level directory. I do not care. When the external storage medium 108 is removed from the recording medium 106, the file name entry area secured in the memory 103 is initialized.

<Second Embodiment>
As a second embodiment, an example in which a virtual file name or a real file name is automatically switched depending on whether or not a client that acquires a file name is an external device is described. This is a case where this apparatus functions as a file server on the network, and it is determined based on whether the request source is on the network or whether the operator is operating directly via the input unit 105. It is easy to understand.

  In FIG. 5, when a file name existing in the directory is acquired, if the client from which the file name is acquired is an external device, the real file name is handled, and if the client is not an external device, whether the process is a virtual file name is automatically processed. It is a flowchart of the process which switches and provides a file name. In step S501, it is determined whether an external device is connected to the I / F 107. If it is determined that an external device is connected, the process proceeds to step S502. If it is determined not, the process proceeds to step S505. In step S502, it is determined whether the client that acquires the file name is an external device. If it is determined that the client is an external device, the process proceeds to step S505. If NO is determined, the process proceeds to step S503. Steps S503 to S505 are the same as steps S202 to S204 described above, and a description thereof will be omitted.

  As described above, in an internal application or the like, file management can be performed at high speed and with a small amount of memory using a virtual file name. On the other hand, a real file name can be provided to a client that uses a real file name, such as displaying a file name or sorting the file display order according to the name.

<Third Embodiment>
As a third embodiment, an example will be described in which a virtual file name or a real file name is automatically switched depending on the length of the real file name.

  FIG. 6 is a flowchart of a file name acquisition process in which the virtual file name is automatically handled or the real file name is automatically handled according to the length of the real file name. Since step S601 is the same as step S204 described above, description thereof is omitted. Subsequently, in step S602, the actual file name acquired in step S601 is stored, and the process proceeds to step S603. In step S603, it is determined whether the length of the actual file name stored in step S602 is shorter than a threshold value. Here, the threshold value may be arbitrarily determined according to the file system of the recording medium, the memory capacity to be implemented, and the like. If it is determined that the file name is shorter than the length threshold of the actual file name, the process ends. If it is determined not, the process proceeds to step S604. Since step S604 is the same as step S202 described above, description thereof is omitted. In step S605, the virtual file name acquired in step S604 is stored. Here, when the virtual file name is stored, it may be overwritten and saved in the storage area of the actual file name stored in step S602.

  As described above, since it is possible to manage files using virtual file names without storing long real file names, memory resources can be saved.

<Fourth Embodiment>
As a fourth embodiment, an example will be described in which a virtual file name or a real file name is automatically switched depending on a file extension description format (extension character string).

  FIG. 7 is a flowchart of a process for performing file access by automatically switching whether to handle a virtual file name or a real file name depending on the file extension. In step S701, it is determined whether or not the extension of the file matches a predetermined extension. If it is determined that the extension is a predetermined extension, the process proceeds to step S702. If it is determined not, the process proceeds to step S705. Steps S702 to S705 are the same as steps S402 to S405 described above, and a description thereof will be omitted.

  As described above, files that frequently occur, such as management files and setting files, can be handled as virtual files and accessed at high speed.

<Fifth Embodiment>
As a fifth embodiment, an example will be described in which whether a virtual file name is handled or a real file name is automatically switched depending on whether a file is newly created in file access.

  FIG. 8 is a flowchart of processing for performing file access by automatically switching whether to handle a virtual file name or a real file name depending on whether or not a new file is to be created. In step S801, the client determines whether to create a new file when accessing the file. If it is determined to create a new file, the process proceeds to step S805. If NO is determined, the process proceeds to step S802. Steps S802 to S805 are the same as steps S402 to S405 described above, and a description thereof will be omitted.

  As described above, when a temporary file name cannot be acquired as in the case of creating a new file, it can be accessed with the actual file name, and when it is not, it can be accessed with the temporary file name at high speed.

<Sixth Embodiment>
As a sixth embodiment, an example will be described in which real file names are acquired and sorted using virtual file names. Here, the maximum number of files handled is six, and the maximum number of files handled is 1000.

  FIG. 9 is a flowchart of processing for acquiring a real file name using a virtual file name in order to respond to a real file name request from a higher-level process (such as an application). Since step S901 is the same as step S403 described above, description thereof is omitted. Then, the process proceeds to step S902. In step S902, the actual file name recorded on the recording medium is read using the physical position obtained in step S901.

  FIG. 11 is a diagram showing lists stored in the real file name storage area and the virtual file name storage area. The file name used for sorting is the actual file name. For example, if sorting is performed using bubble sort, two actual file names are required. Since the actual file name of one file is a maximum of 1538 bytes, the actual file name storage area is 1538 × 2 = 3076 bytes.

  Since the virtual file name needs to store the file name of a maximum of 1000 files, the required capacity of the virtual file name storage area is 48 × 1000 = 48000 bytes.

  FIG. 12 is a diagram illustrating a relationship between a virtual file name, a real file name, and a file system. Here, for convenience, the virtual file name is A /######/$$$$$$/%%%%%%.&&&, and the corresponding real file name is A / DCIM / 100CANON / IMG_0001 Assume / JPG and the file system is a FAT file system. If the value when the virtual directory ##### is converted into a physical address is x, x indicates an arbitrary address on the directory entry on the file system. In the directory entry, metadata such as a file (directory) name, creation date / time, attribute, and start cluster number of actual data is described. By reading the directory entry, the real file (directory) name can be acquired, and it can be seen that the real directory name corresponding to the virtual directory name ##### is DCIM.

  Similarly, when the virtual directory name $$$$$$ is converted to a physical address, y is found to be 100GANON when the file name written in the directory entry indicated by y is read. Then, when the virtual file name %%%%%%. &&& is converted to a physical address, z becomes IMG_0001.JPG when the file name written in the directory entry indicated by z is read.

  As described above, the actual file name can be acquired from the virtual file name as necessary, for example, when displaying the actual file name or sorting a plurality of files by the actual file name. Further, since the virtual file name is obtained with a fixed length, it is possible to save memory compared to the case where all the real file names are stored. In addition, when there is a file access request using the real file name, it is necessary to search the directory entry of each layer. However, the virtual file name access request directly accesses the directory where the file exists, so it searches quickly. can do.

[Application example of the embodiment]
This embodiment is particularly convenient when applied to a printer having a memory card slot. Hereinafter, an application example thereof will be briefly described. That is, the image stored in the memory card is printed by a user operation.

  The capacity of memory cards used in recent imaging devices such as digital cameras is increasing, and the number of image files stored therein is inevitably large. Further, since it can be used as an external storage device of a memory card or PC, it is inevitably managed in a multi-level directory in the memory card, and many files are mixed. It is convenient to apply the present invention to such a printer. In other words, the CPU in the printer that detects the installation of the memory card performs processing so as to manage the virtual file name in the memory in the printer. As a result, subsequent interaction with the user (processing related to reading and display of an image to be printed by the user) can be performed with a virtual file name, and does not squeeze the memory in the printer and has a high response user interface. Can be built.

  Although the present invention has been described in detail based on preferred embodiments thereof, the present invention is not limited to these specific embodiments, and various forms within the scope of the present invention are also included in the present invention. included. A part of the above-described embodiments may be appropriately combined.

  Also, when a software program that realizes the functions of the above-described embodiments is supplied from a recording medium directly to a system or apparatus having a computer that can execute the program using wired / wireless communication, and the program is executed Are also included in the present invention.

  Accordingly, the program code itself supplied and installed in the computer in order to implement the functional processing of the present invention by the computer also realizes the present invention. That is, the computer program itself for realizing the functional processing of the present invention is also included in the present invention.

  In this case, the program may be in any form as long as it has a program function, such as an object code, a program executed by an interpreter, or script data supplied to the OS.

  As a recording medium for supplying the program, for example, a magnetic recording medium such as a hard disk or a magnetic tape, an optical / magneto-optical storage medium, or a nonvolatile semiconductor memory may be used.

  As a program supply method, a computer program that forms the present invention is stored in a server on a computer network, and a connected client computer downloads and programs the computer program.

(Other embodiments)
The present invention can also be realized by executing the following processing. That is, software (program) that realizes the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media, and a computer (or CPU, MPU, etc.) of the system or apparatus reads the program. It is a process to be executed.

Claims (7)

A file management device having a memory for managing a file path management table for a file stored in a storage medium formatted in a file system having a hierarchical structure,
Detecting means for searching a directory entry corresponding to each file stored in the storage medium and detecting an absolute address position in the storage medium of the directory entry corresponding to each file;
The information representing the absolute address position detected by the detecting means is converted into a character string having a preset format and the number of characters, and the character string is used as a virtual file name of the corresponding file, and a file name entry in the memory Registration means for registering in the area ;
First determination means for determining the type of a file system for managing the files of the storage medium,
If the file system determined by the first determination unit is exFAT, the registration unit registers the virtual file name in the file name entry area in the memory;
When the file system determined by the first determination unit is other than the exFAT, the registration unit registers an actual file name in a file name entry area in the memory . Second determination for determining whether the format of the file name description registered in the file name entry area in the memory is the format of a real file name with a directory path or the format of the virtual file name Means,
If the second determination means determines that the file format is the virtual file name format, the virtual file name registered in the file name entry area is converted into information indicating the absolute address position of the storage medium. The file management apparatus according to claim 1, further comprising: a reading unit that reads information from the storage medium in accordance with the converted absolute address position. The file management apparatus according to claim 2 , wherein the second determination unit determines whether the file name is the virtual file name based on an extension of the file name. When there is a request for acquisition of a real file name in the file system of a file with a virtual file name from a host process, the reading means stores it in the directory entry based on the character string in the requested virtual file name 4. The file management apparatus according to claim 2 , wherein a real file name is acquired. A control method of a file management apparatus having a memory for managing a file path management table for a file stored in a storage medium formatted in a file system having a hierarchical structure,
Detecting a directory entry corresponding to each file stored in the storage medium, and detecting an absolute address position in the storage medium of the directory entry corresponding to each file;
The information indicating the absolute address position detected in the detection step is converted into a character string having a preset format and the number of characters, and the character string is used as a virtual file name of the corresponding file as a file name entry in the memory. A registration process to register in the area;
A first determination step of determining a type of a file system for managing files on the storage medium,
If the file system determined in the first determination step is exFAT, the registration step registers the virtual file name in the file name entry area in the memory,
When the file system determined by the first determination step is other than exFAT, the registration step registers an actual file name in a file name entry area in the memory . By executing read into the computer, the computer, causes the computer to function as a file management apparatus according to any one of claims 1 to 4. A computer-readable storage medium storing the computer program according to claim 6 .

Images