JP2005174063A - File management apparatus, dynamic name space generation method and dynamic name space generation program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable a user to acquire own target file, even when the user does not have any knowledge related with the accurate configuration of a tree structure, by providing a means for dynamically configuring the tree structure in a file system, according to the use conditions of the user. <P>SOLUTION: A registering part 12 registers both the meta data constituted of one or more meta data elements defined for each file and file ID to identify a file in a meta data definition information storing part 120. A retrieving part 13 refers to the meta definition information storing part 120, in response to the acquisition request of directory contents to designate some of the arbitrarily selected meta data elements, and retrieves the file corresponding to the meta data including the designated meta data elements, and determines the file as the file under the designated directory. Also, the file name of the file as the retrieval result is prepared from the residual meta data elements of the meta data of the file. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a technology for accessing a file stored in a computer system, and more particularly, to a file management apparatus and a dynamic namespace generation method for dynamically configuring a directory and file hierarchical structure according to the usage status of a user. .

  A file system is software for managing data files recorded in a storage device in a computer system, and the management targets include a management area and management information provided in a storage medium in addition to files. In many existing file systems represented by NTFS (NT File System), which is a file system of Microsoft Windows widely used at present, files are managed in a tree structure.

  In a tree-structured file system, a hierarchical structure including “nodes” called directories and “leaves” as files starts with “roots” called roots. One or more directories and files are placed in the root. A directory acts like a box that can contain files and other directories, and a directory contains one or more directories and files. A directory including itself, that is, a directory closer to the root when viewed from a certain directory is hereinafter referred to as an “upper directory”. From the perspective of a directory, the directory that it contains is expressed as a “subordinate directory” hereinafter.

  A file has an individual name called a file name, and is unique within the directory containing the file. Similarly, a directory has an individual name called a directory name, and becomes a unique name in an upper directory including the directory. In general, a directory name is a word corresponding to the meaning or description of a directory or file included in the directory name such as “time”, “location”, or “field”.

  A sequence of directories that follow a tree structure in order from the root of a file is called a path, and a sequence of directory names that constitute a path is called a path name. Each file becomes a unique name in the file system by combining the path name and the file name.

Note that the NFTS described in Patent Document 1 defined in the following RFC1813 can use a file system of a different computer from a user's own computer via a communication path. It is a structured file system.
NFS Version 3 Protocol Specification (RFC1813)

  The existing file system has the following problems. The first problem is that the upper and lower relations of the directory names such as “time”, “location”, and “field” are statically determined when the user configures the tree structure. Users can freely determine the hierarchical relationship of multiple directories, but this may result in an inconsistent hierarchical structure if the policy for configuring the tree structure is not predetermined. Means that. On the other hand, since the file name and path name are required to obtain the target file, the user knows not only the directory name included in the file name or path but also the order in the tree structure of the directory name. Must be.

  The second problem is the possibility that the file name alone does not make sense. As described above, the directory name is a word corresponding to the meaning or description of the directory or file included in the directory name. For example, when 10 image files are included in a directory named “Travel”, the description of “Travel” is generally common to the 10 image files.

  At this time, the user can make the file names of the ten image files serial numbers from “1” to “10”. As long as the file name consisting of this serial number is included in the directory “travel”, it can be said that it has the meaning of the order. However, when the file named “5” is copied to another directory called “Photo”, the name “5” loses the meaning of the order and is called “Travel” given by the directory name. The meaning will be lost.

  The third problem is duplication of meaning in path names and file names. One way to solve the problem of losing meaning due to file duplication, as exemplified in the second task, is to include the word “travel” in the file name and use “travel 5” as the file name. Can be considered. However, in this case, the file “Travel 5” is included in the directory “Travel”, and the meaning is duplicated between the path name and the file name. Similar problems can occur between directories in the path. Management with such redundant names is more likely to lose semantic consistency.

  The fourth issue is the need for reconstruction of the tree structure. Unless the file system is used for a special purpose, the number of directories and files to be managed increases as the computer is used. At this time, unless the tree structure is strictly designed in advance, directory integration, division, and directory name change occur. As an example, the directory “travel” is divided into two directories, “domestic travel” and “overseas travel”. As with the first issue, the user must know the new tree structure accurately to obtain the desired file.

  The fifth issue is the problem of duplicate file names. Copying the file “5” contained in the directory “Landscape” to the directory “Photo” where the file named “5” mentioned in the second example is already copied. Since the file name “5” is duplicated in the directory “photo” at the copy destination, and the uniqueness of the file name in the same directory cannot be maintained, it cannot be performed. This is because, like the second problem, two files originally given different meanings including the path lost their meaning other than the file name by copying them to another directory.

  The object of the present invention is to solve the above first and fourth problems by enabling a user to obtain a target file even if the user does not have knowledge about the exact structure of the tree structure or its change. The above mentioned second and fifth problems can be solved by avoiding the lack of meaning and explanation by moving and copying files, and the consistency can be improved by eliminating redundancy of meaning and explanation of files. It is to realize a file system that solves the third problem.

  In order to solve the above problems, the present invention realizes a file system in which a tree structure is dynamically formed when a user uses the file system, instead of a conventional static tree structure file system. is there. The data describing the meaning of the file is hereinafter referred to as “metadata”. Specifically, the metadata is a data string of one or more metadata elements including “value” or “attribute / value pair” representing the meaning of the file. In the present invention, directories and files do not have a fixed name, and metadata related to the file is used as a directory name or a file name by a user operation.

  That is, according to the present invention, in a file management apparatus having a file system for managing a set of data handled by a computer as a file, metadata including one or more metadata elements defined for each file is stored in each file. Metadata definition information storage means for storing together with identification information; registration means for registering metadata in the metadata definition information storage means; changing and deleting metadata registered in the metadata definition information storage means; In response to an operation request for a file in which some of the metadata elements are specified as a directory, the metadata definition information storage unit is referred to, and a file corresponding to the metadata including the specified metadata element is specified. Search means for determining the operation target file under the directory. The hierarchical structure of directories and files in the filesystem, wherein the dynamically configuring based on usage of the user.

  Also, in response to an operation request for a file in which some of the metadata elements are specified, a set of metadata elements excluding the specified metadata element from the file metadata including all the metadata elements is filed. Means for presenting to a user as a name is provided.

  In the file management apparatus, the metadata element constituting the metadata registered in the metadata definition information storage means is a value representing the meaning of the file or a combination of an attribute and a value.

  Further, the search means has a search result cache mechanism for storing information of a set of metadata obtained by searching the metadata definition information storage means and a list of information for identifying files corresponding to the metadata, A file corresponding to the specified metadata is specified by the search result cache mechanism, and the metadata definition information storage means is searched when the file cannot be specified by the search result cache mechanism.

  The present invention also relates to a dynamic name space generation method for dynamically configuring the hierarchical structure of directories and files in a file system in accordance with the usage status of a user. Registering in the metadata definition information storage means a set of file identification information for uniquely identifying a file and metadata comprising one or more metadata elements defined for the file; and the metadata definition information Of the metadata for each file registered in the storage means, a set of metadata elements designated by the user is defined as a directory, and the remaining metadata elements excluding the metadata elements of the directory from the metadata. The set is presented to the user as a file name, and the set of directory and file name that changes according to the usage status of the user And having basis and performing the processing for the file operation request.

  The present invention also relates to a dynamic name space generation method for dynamically configuring the hierarchical structure of directories and files in a file system in accordance with the usage status of a user. Registering in the metadata definition information storage means a set of file identification information for uniquely identifying the file and metadata comprising one or more metadata elements defined for the file, and accepting from the file operation interface Performing a file operation according to the type of the file operation request. In the step of performing the file operation, when the type of the file operation request received from the file operation interface is acquisition of directory contents, The metadata contained in the file operation request is divided into metadata elements. The file definition information corresponding to the metadata including all the divided metadata elements is retrieved from the metadata definition information storage means, the retrieved file identification information list, the metadata corresponding to the retrieved file identification information, or the retrieval The remaining metadata obtained by removing the metadata element in the metadata included in the file operation request from the metadata corresponding to the file identification information is returned to the request source of the file operation request.

  In addition, as the file operation interface, an existing interface that handles a fixed directory and a fixed file name is used, and a file operation using the file operation interface is determined according to the usage status of the directory and file name by the user. The method includes a step of converting the metadata operation into a dynamically changing metadata operation.

  The operation of the present invention is as follows. The dynamic namespace creation method of the present invention dynamically constructs a tree structure in the file system according to the usage status of the user. In the file system using this dynamic namespace generation method, the user does not need to have knowledge about the structure of the tree structure. This file system is characterized by not having a fixed directory name and file name. In addition, this file system is characterized in that a name space is generated by using metadata for a file. In addition, this file system is characterized by identifying files in a directory by a meaningful name alone.

  Furthermore, the file system using the present invention is characterized in that it is easy to ensure the consistency of meaning by eliminating the need for duplicate metadata definitions for the same file. Further, the file system using the present invention is characterized in that a file operation using a conventional interface by a user is converted into a metadata operation for the file.

  In the present invention, the tree structure in the conventional file system is dynamically configured by the user specifying the metadata element according to his / her purpose of use, that is, performing the directory content acquisition operation. As a result, the user can use the file system and update the metadata even if he / she does not have knowledge about the exact structure of the tree structure or its change. The fourth problem can be solved.

  In the present invention, the name of the file is determined using metadata that is not used as the name of the directory, that is, metadata that has not yet been specified by the user. As a result, the file can always have an appropriate file name for identification in the directory, and the second and fifth problems described above can be solved.

  In the present invention, one metadata for a certain file can be used as a directory name or a file name, and it is not necessary to define the metadata redundantly. This makes it easy to maintain the consistency of meaning and solve the third problem described above.

  As shown in the following embodiment, the user can acquire a file from the file server of the present invention using the same interface as that of the conventional file system. Furthermore, the user can perform the metadata operation of the system of the present invention by the conventional file operation by the conventional interface.

  Thus, the present invention can provide a highly consistent file system that eliminates lack of meaning and explanation and redundancy without imposing a burden on the user.

  Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram for explaining the outline of the present invention. In FIG. 1, a file entity management unit 10 is a means for providing an access function to a file that is a set of data stored in a disk device 111 or the like, and is a file management that an existing general operating system (OS) has. It has the same function as the function. Each file is assigned and managed with a file ID (f1, f2,...) That uniquely identifies the file.

  The metadata definition information storage unit 120 is a means for storing metadata including one or more metadata elements defined for each file, together with a file ID for identifying each file. The registration unit 12 performs a process of registering a set of metadata corresponding to the file ID in the metadata definition information storage unit 120.

  When some of the metadata elements are specified in the file operation request, the search unit 13 searches the metadata definition information storage unit 120 for a file corresponding to the metadata including the specified metadata element, This is means for determining a search result file as an operation target. The search unit 13 includes a search result cache mechanism 133 that stores information on a set of metadata obtained as a result of searching the metadata definition information storage unit 120 and a list of file IDs that identify files corresponding to the metadata. When searching for a file corresponding to the specified metadata, the search result cache mechanism 133 is first searched to speed up the metadata search.

  The registration unit 12 and the search unit 13 dynamically configure the hierarchical structure of directories and files in this file system according to the usage status of the user. Specifically, it is as follows.

  In this example, in the metadata definition information storage unit 120, metadata including four metadata elements having values a1, a2, a3, and a4 is registered for the file with the file ID f1. . In the file whose file ID is f2, metadata including four metadata elements having values of a1, a5, a3, and a4 is registered. The content and number of metadata elements can be arbitrarily defined for each file by the file registrant. Here, the order of arrangement of the metadata elements has no meaning, and the user can rearrange the metadata elements as necessary.

  Metadata elements can be defined as attribute / value pairs. The metadata elements 3 and 4 of the file with the file ID f3 and the metadata element 4 of the file with the file f4 are examples of attribute / value pairs. Here, it is described as “attribute → value”, and in the case of the metadata element 3 of the file whose file ID is f3, “x1” is the attribute and “a6” is the value of the attribute.

  In this system, the directory name and the file name are not fixedly determined in advance, but are dynamically generated from a set of metadata elements in the metadata according to the usage status of the user. For example, when the metadata element “a1” is designated as a directory, all files including the metadata element “a1” are extracted as files under the directory “a1”.

  FIG. 1B shows an example. “Z:” in “Z: ¥ a1” shown as the directory name in FIG. 1B designates the device name of the disk device 111, but is not essential to the present invention. In the following description, it is omitted. When the search unit 13 searches the metadata definition information storage unit 120 using the directory name “¥ a1”, f1, f2, and f4 files including the metadata element “a1” are obtained as search results. When presenting each of these files to the user via the file operation interface, a file obtained by concatenating metadata elements obtained by removing the metadata element “a1” from the metadata of each file with “_” is used as the file. Name. That is, the file name of the file f1 is “a2_a3_a4”. The file name of the file f2 is “a5_a3_a4”. The file name of the file f4 is “a2_a4_a8 (x1)”. Here, when the metadata element is a combination of an attribute and a value, the metadata element is displayed in the format of “value (attribute)”.

  For example, if the metadata elements “a1” and “a2” are specified as a directory “¥ a1 ¥ a2”, the metadata includes metadata including the metadata elements “a1” and “a2”. All the file IDs are extracted as files under the directory “¥ a1 ¥ a2”. In this example, the files f1 and f4 correspond to each other, and a list of these files is displayed with file names “a3_a4” and “a4_a8 (x1)” as shown in FIG.

  Similarly, when “\ a3 \ a4 \ a5” is designated as a directory as shown in FIG. 1D, only the metadata of the file of f2 is changed to the metadata elements of “a3, a4, a5”. As a result, the search result is the file f2, and the metadata element “a1” obtained by excluding the metadata elements “a3, a4, a5” specified in the directory from the metadata of the file f3 is displayed as the file name. Is done.

  FIG. 2 is a diagram showing a system configuration example of the present invention. In FIG. 2, 1 is a file server for managing files used by the user, 2 is a user terminal operated by the user, and 300 is a communication path connecting the file server 1 and the user terminal 2. The file server 1 includes a disk management unit 11, a registration unit 12, and a search unit 13. Reference numeral 100 denotes a registrant who registers a file in a file server described later, and reference numeral 200 denotes a user who uses the system according to the present invention.

  The disk management unit 11 corresponds to the file entity management unit 10 shown in FIG. 1, and includes a disk device 111 and a disk access mechanism 112. The disk device 111 stores files, and each file has a unique identifier (hereinafter referred to as a file ID) on the disk device 111.

  The registration unit 12 includes a metadata definition table 121, a metadata registration acceptance mechanism 122, and a metadata generation mechanism 123. The metadata definition table 121 corresponds to the metadata definition information storage unit 120 shown in FIG. 1, and is a table (table) including entries for each file ID. One entry includes a file ID and metadata. The file ID corresponds to the file ID of the disk device 111 described above, and is a unique identifier in the metadata definition table 121.

  The metadata is a column of data composed of one or more metadata elements, and the metadata element is either “value” or “attribute / value pair”. The value is an arbitrary character string or numerical value, and examples thereof include “Taro Suzuki” and “2003/1/1”. The attribute is an arbitrary character string that describes the meaning of the value, and examples include “creator” and “update date”.

  The search unit 13 includes a metadata search mechanism 131, a file operation request reception mechanism 132, and a search result cache mechanism 133. The search result cache mechanism 133 holds a plurality of cache contents. One cache content is composed of a set of a certain “metadata” and a “file ID list” of a file whose metadata is included in the metadata definition table 121. Hereinafter, the “file ID list” is referred to as a “search result string”.

  The user terminal 2 includes a file operation interface 21 that inputs and outputs file operation information with the user 200, and a file operation request unit 22 that communicates with the file server 1 related to file operation information via the communication path 300. And have.

  Next, the operation of this system will be described. FIG. 3 is a diagram illustrating an example of a processing flow of the registration unit 12. The registrant 100 registers a file to be registered in the file server 1 from the metadata registration receiving mechanism 122 of the registration unit 12. The metadata registration receiving mechanism 122 receives the command (step S1). The registration unit 12 that has received an instruction from the registrant 100 determines the type of instruction (registrant's request) (step S2).

  When the instruction from the registrant 100 is “registration”, the process proceeds to step S3. In step S3, a copy of the file (entity) requested to be registered is created, and the copy is transferred to the disk management unit 11 (step S3). The disk management unit 11 stores the file in the disk device 111 and returns a unique file ID on the disk device 111 to the registration unit 12. The registration unit 12 acquires the file ID (step S4).

  The registration unit 12 moves the file information registered from the metadata registration acceptance mechanism 122 to the metadata generation mechanism 123, and generates metadata (step S5). The registration unit 12 creates a new entry in the metadata definition table 121 with the set of the file ID passed from the disk management unit 11 and the generated metadata (step S6), and creates the created entry in the metadata definition table 121. Register (step S7).

  The registrant 100 can change or delete the metadata registered in the metadata definition table 121 from the metadata registration receiving mechanism 122 of the registration unit 12. When the registrant 100 issues a command to change the metadata registered in the metadata definition table 121, the metadata registration receiving mechanism 122 receives the command (step S1). When the registration unit 12 determines that the command received from the registrant 100 is “change” (step S2), the registration unit 12 changes the metadata in the metadata definition table 121 (step S8), and sends the search result cache to the search unit 13. Clearing is requested (step S9). As a result, the search unit 13 clears the cache contents of the search result cache mechanism 133.

  If the registration unit 12 determines that the instruction received from the registrant 100 is “delete” (step S2), the registration unit 12 deletes the specified metadata (element) in the metadata definition table 121 (step S10). It is determined whether or not there is no metadata element corresponding to the file ID (step S11). If one or more metadata elements of the corresponding file ID remain, the process proceeds to step S14, and the search unit 13 is requested to clear the search result cache. As a result, the cache contents of the search result cache mechanism 133 are deleted.

  When all the metadata elements corresponding to the file ID have disappeared, the registration unit 12 sends a deletion request for the file identified by the file ID to the disk management unit 11 (step S12). The disk management unit 11 deletes the file from the disk device 111 using the disk access mechanism 112. Next, the registration unit 12 deletes the entry of the file ID from the metadata definition table 121 (step S13). The registration unit 12 requests the search unit 13 to delete the search result cache (step S14). As a result, the cache contents of the search result cache mechanism 133 are deleted.

  4 and 5 are diagrams illustrating an example of a processing flow of the search unit 13. The user 200 obtains directory contents, obtains a file, copies a file, deletes a file, moves a file from the file operation interface 21 of the user terminal 2 in the same manner as the operation for the conventional hierarchical file system. You can create a new file.

  Each operation request includes metadata indicating the current directory in addition to the request type. For file acquisition and file deletion, the target file ID is also included in the operation request.

  For file copying, in addition to the target file ID, metadata indicating the file copy destination directory and the copy destination file name are also included in the operation request. Regarding the movement of a file, in addition to the target file ID, metadata indicating the destination directory of the file and the name of the destination file are also included in the operation request. For creating a new file, the name of the file to be created is also included in the operation request.

  The above operation is transferred from the file operation request unit 22 to the search unit 13 of the file server 1 through the communication path 300, and processing is performed inside the file server 1. The operation processing result is returned from the search unit 13 to the file operation request unit 22 via the communication path 300 and displayed on the file operation interface 21.

  The file operation request transferred from the file operation request unit 22 of the user terminal 2 to the file server 1 is received by the file operation request reception mechanism 132 of the search unit 13 (step S21) and transferred to the metadata search mechanism 131. . The metadata search mechanism 131 determines the type of file operation request (step S22), and performs the processing described below according to the type of file operation request.

[Obtain directory contents]
When the file operation request is “acquisition of directory contents” (step S22), the metadata search mechanism 131 divides the metadata included in the file operation request into metadata element units from the beginning, and generates a search metadata string. (Step S23). Next, the metadata search mechanism 131 performs a search process (step S24). Details of this search processing will be described later with reference to FIG.

  The metadata search mechanism 131 checks whether the search result is empty after the search process of step S24 (step S25). If the search result is not empty, the metadata search mechanism 131 is included in the file operation request among the list of file IDs of the search result and the metadata defined in the metadata definition table 121 of each file ID. The data excluding the metadata is returned to the file operation request receiving mechanism 132 as a search result. The file operation request receiving mechanism 132 returns the search result to the file operation request unit 22 of the user terminal 2 (step S26). When the search result is empty, the metadata search mechanism 131 returns an empty search result to the file operation request reception mechanism 132. The file operation request receiving mechanism 132 returns an empty search result to the file operation request unit 22 of the user terminal 2 (step S27).

  Before explaining the details of the search processing of the search unit 13 shown in step S24 using FIG. 5, an example of the metadata definition table 121 used for the description and an example of the cache held in the search result cache mechanism 133 are described. Will be explained. FIG. 6 is a diagram showing an example of the metadata definition table, and FIG. 7 is a diagram showing an example of the cache of the search result cache mechanism 133.

  In the metadata definition table 121, for example, as shown in FIG. 6, it is assumed that metadata including a data string of metadata elements is registered for each file ID. A, B, C,..., E in the figure are metadata elements composed of “values” (or “attribute / value pairs”) defined for each file.

  The search result cache mechanism 133 stores, for example, metadata and a search result string as shown in FIG. The search result cache mechanism 133 is provided to speed up the search process of the metadata definition table 121, and stores the result of searching the metadata definition table 121 once with metadata. When the metadata definition table 121 is updated, the cache contents in the search result cache mechanism 133 are cleared in order to maintain consistency between the contents of the metadata definition table 121 and the cache contents.

  In the example of FIG. 7, the cache a is a search result of the metadata “A, B, C, D”, and the metadata “A, B, C, D” and the metadata of the metadata definition table 121 of FIG. Correspondence information of a search result string “2” that is a file ID list of a file including “A, B, C, D” in the data is stored. Further, the cache b is a search result of the metadata “A, E”, and the file of the file including “A, E” in the metadata “A, E” and the metadata of the metadata definition table 121 of FIG. Correspondence information of a search result string “1, 3, 4” which is an ID list is stored. The cache c is a search result of the metadata “A, C”, and the file of the file including “A, C” in the metadata “A, C” and metadata in the metadata definition table 121 of FIG. Correspondence information of a search result string “1, 2” that is an ID list is stored.

  The search process in step S24 shown in FIG. 4 is performed as shown in FIG. Hereinafter, the processing content by the search unit 13 will be described by taking the case where the metadata definition table 121 is in the state shown in FIG. 6 and the cache of the search result cache mechanism 133 is in the state shown in FIG.

  The metadata search mechanism 131 checks whether the search result cache mechanism 133 has a cache content in which a part or all of the search metadata string matches the cache metadata (step S241).

  If there is a cache content in which all of the search metadata columns match the cache metadata, the metadata search mechanism 131 sets the search result sequence included in the cache as the search result (step S256). FIG. 8 is a diagram for explaining an example of search processing. In the example in which the search metadata string shown in FIG. 8 is “C, A”, the search metadata string matches the metadata of the cache c shown in FIG. Result.

  When there is a cache content in which only a part of the search metadata column matches the cache metadata, the metadata search mechanism 131 sets the search result column (file ID list) included in the cache as the current temporary search result column. To do. When multiple caches are applicable, the cache content with the smallest number of elements in the search result sequence is adopted. If there are a plurality of cache contents with the smallest number of elements in the search result sequence, the one searched first is adopted.

  The metadata search mechanism 131 uses the cache metadata as a temporary directory string. Further, the metadata search mechanism 131 removes a metadata element that matches the cache metadata (temporary directory string) from the search metadata string (step S242), and determines whether the search metadata string becomes empty or a temporary search result string. The process after the cache check described later is repeated until becomes empty (steps S244 to S254).

  For example, in the example in which the initial search metadata string shown in FIG. 8 is “C, A, E”, part of the search metadata string matches the cache b and the cache c shown in FIG. Of these two cache contents, the metadata search mechanism 131 uses the metadata “A, C” of the cache c having the smallest number of elements in the search result column as the temporary directory column and also the search result columns “1, 2” in the cache c. "Is the current temporary search result string. Next, “E” obtained by removing “A, C” from the search metadata column “C, A, E” is set as a new search metadata column (search metadata column after cache confirmation).

  If there is no cache content that matches the cache metadata in any part of the search metadata string, the metadata search mechanism 131 processes as a new request. The metadata search mechanism 131 generates a temporary search result column including an empty temporary directory column and a list of file IDs in the metadata definition table 121 (step S243), and determines whether the search metadata column is empty or not. The process after the cache check described later is repeated until the result string becomes empty (steps S244 to S254).

  For example, in the example in which the initial search metadata string shown in FIG. 8 is “C, A, B”, the cache contents including the cache metadata exist in the cache shown in FIG. 7 as part of the search metadata string. do not do. The metadata search mechanism 131 uses an empty temporary directory string and a list of file IDs “1, 2, 3, 4, 5” in the metadata definition table 121 shown in FIG. 6 as temporary search result strings.

  Next, the processing operation after the cache check (steps S244 to S254) will be described. First, the top of the search metadata string is set as a search metadata element (step S245), and the type of the search metadata element is determined (step S246). As described above, there are two metadata elements of the metadata definition table 121: “attribute / value pair” and “value”. On the other hand, there are three types of search metadata elements: “attribute”, “attribute / value pair”, and “value”. Here, “attribute / value pair” is described in the format of “attribute → value”.

  When the search metadata element is “attribute”, the file ID is included in the temporary search result column, and the “attribute” specified in the search metadata element in the metadata of the metadata definition table 121 corresponding to the file ID. The file ID including the metadata element using the same attribute as “” is extracted (step S247). For example, when the search metadata element is “creator →”, a file ID including metadata elements such as “creator → Taro Suzuki” and “creator → Jiro Sato” is extracted.

  When the search metadata element is “attribute / value pair”, the temporary search result column includes the file ID, and the metadata of the metadata definition table 121 corresponding to the file ID is specified by the search metadata element. The file ID including the same set of metadata elements as the attribute / value pair is extracted (step S248). For example, when the search metadata element is “creator → Taro Suzuki”, the file ID including the metadata element “creator → Taro Suzuki” is extracted.

  When the search metadata element is “value”, the file ID is included in the temporary search result column, and the “value” specified in the search metadata element in the metadata of the metadata definition table 121 corresponding to the file ID. The file ID including the metadata element using the same value as “” is extracted (step S249). For example, if the search metadata element is “Taro Suzuki”, in addition to “Taro Suzuki”, metadata elements with attributes such as “Creator → Taro Suzuki” and “Administrator → Taro Suzuki” were included. The file ID is also extracted.

  The list of file IDs obtained from the search results is replaced with a new temporary search result string (step S250). The search metadata element is added to the end of the temporary directory string and replaced with a new temporary directory string (step S251).

  A set of a new temporary directory string and a new temporary search result string is registered in the search result cache mechanism 133 (step S252). The list from which the first metadata element used in the above process is removed is replaced with a new search metadata string (step S253), and the metadata search mechanism 131 performs the process from steps S244 to S254 to the search metadata string. Repeat until the temporary search result sequence is empty. The temporary search result sequence at the time when the search metadata sequence becomes empty is set as the search result (step S255). If the temporary search result string is empty, the search result is empty.

[Get file]
In step S22 of FIG. 4, when the file operation request is “acquire file”, the metadata search mechanism 131 sends a file acquisition request for the file ID included in the file operation request to the disk management unit 11. The disk management unit 11 acquires a file from the disk device 111 using the disk access mechanism 112 (step S28), and returns it to the search unit 13. The search unit 13 returns the acquired file contents from the file operation request receiving mechanism 132 to the file operation request unit 22 of the user terminal 2 (step S29).

[Copy files]
In step S22 of FIG. 4, when the file operation request is “file copy”, the metadata search mechanism 131 divides the metadata representing the copy destination directory included in the file operation request into metadata element units from the beginning. (Step S30). Next, the metadata search mechanism 131 adds the divided copy destination metadata element and the file operation request to the metadata defined in the metadata definition table 121 of the file ID included in the file operation request. The copy destination file name included is added (step S31). Then, the search unit 13 deletes the cache contents of the search result cache mechanism 133 (step S32).

[Delete File]
In step S22 of FIG. 4, when the file operation request is “delete file”, the metadata search mechanism 131 divides the metadata representing the current directory included in the file operation request into metadata element units from the beginning. . Next, the metadata search mechanism 131 deletes the same metadata element as the divided metadata element from the metadata defined in the metadata definition table 121 of the file ID included in the file operation request ( Step S34).

  If there is no metadata element corresponding to the file ID, the process proceeds to step S35. If one or more metadata elements remain, the process proceeds to step S37 (step S34). If the metadata element corresponding to the file ID becomes 0, the search unit 13 sends a deletion request for the file identified by the file ID to the disk management unit 11 (step S35), and the disk management unit 11 The file is deleted from the disk device 111 using the access mechanism 112. The search unit 13 deletes the entry of the file ID from the metadata definition table 121 (step S36). Finally, the search unit 13 deletes the cache contents of the search result cache mechanism 133 (step S37).

[Move file]
In step S22 of FIG. 4, when the file operation request is “move file”, the metadata search mechanism 131 includes the metadata indicating the current directory included in the file operation request and the transfer destination included in the file operation request. The metadata representing the directory is divided into metadata elements from the beginning (step S38).

  Next, the metadata search mechanism 131 is the same as the metadata element obtained by dividing the metadata representing the current directory from the metadata defined in the metadata definition table 121 of the file ID included in the file operation request. Are deleted (step S39). The metadata search mechanism 131 also includes the same metadata element as the metadata element obtained by dividing the metadata representing the destination directory into the metadata defined in the metadata definition table 121, and a file. The destination file name included in the operation request is added (step S40). Thereafter, the cache contents of the search result cache mechanism 133 are deleted (step S41).

[Create new file]
In step S22 of FIG. 4, when the file operation request is “create new file”, the metadata search mechanism 131 divides the metadata representing the current directory included in the file operation request into units of metadata elements from the top. (Step S42). Next, the metadata search mechanism 131 requests the disk management unit 11 to create a file ID, and the registration unit 12 includes the file ID acquired from the disk management unit 11 and the metadata element included in the file operation request. A new file name is added and registration to the metadata definition table 121 is requested (steps S43 and S44). Thereafter, the cache contents of the search result cache mechanism 133 are deleted (step S45).

[Description of Configuration of Example of the Present Invention]
The file server 1 shown in FIG. 2 is a personal computer in which a Windows (registered trademark) OS is installed, and the user terminal 2 is a personal computer in which a Windows OS is installed. NTFS (NT File System) of Windows OS as the disk access mechanism 112, application software for realizing the present invention as the registration unit 12 and the search unit 13, and the file path name of NTFS as the file ID in the metadata definition table 121 And a set of file names.

  It is assumed that the external interface of the file operation request receiving mechanism 132 is compliant with WebDAV (RFC2518). In order to use WebDAV for the interface, in this embodiment, the path name passed to the search unit 13 by WebDAV is regarded as metadata representing a directory, and the file name is used as information for specifying the file ID. Assume that the memory of the file server 1 is used as the search result cache mechanism 133. Since the search result cache mechanism 133 has a finite capacity, it is assumed that the area is managed by the LRU (Last Recently Used) method.

  Explorer for Windows OS attached software as the file operation interface 21, Web folder software for WebDAV (Web Distributed Authoring and Versioning) client function attached to the Windows OS as the file operation request unit 22, and the communication path 300 is a communication network by IP (Internet Protocol) And

  When the user 200 uses the file operation interface 21 (Explorer) to perform operations such as opening a folder, double-clicking a file, copying a file, deleting a file, and moving a file. In the present invention, it is assumed that file operation requests, that is, directory contents acquisition, file acquisition, file copy, file deletion, and file move requests have occurred.

[Description of Operation of Embodiment of the Present Invention]
Here, an operation when the registrant 100 registers a file and an operation when the user 200 makes a file operation request from the file operation interface 21 (explorer) will be described.

  The registrant 100 passes the files “# 1” to “# 10” on the disk access mechanism 112 (NTFS) to the registration unit 12. The registration unit 12 registers these ten files in the metadata definition table 121. In this embodiment, the file ID is a set of a path name and a file name on the disk access mechanism 112. The registrant 100 defines the metadata for each file, for example, with the contents shown in FIG. Although the metadata definition table 121 in FIG. 9 shows an example having a maximum of four metadata elements (1 to 4), the number of metadata elements can be arbitrarily defined for each file. The order of metadata elements defined for each file has no hierarchical meaning and can be rearranged as needed.

  Further, in the metadata definition table 121 of FIG. 9, each metadata element is defined by “value” such as “photograph”, “travel”, “Lake Kawaguchi”,... It can also be defined by a set of attribute (travel destination) and value (Lake Kawaguchi).

  Metadata elements can also be automatically defined from the file format and other attributes. For example, if the file is an Exif (Exchangeable Image File Format; JEIDA-49) format image file, use the Exif tag. Implementation of adding metadata elements with a certain number of pixels, compression mode, camera model name, aperture value, shutter speed, shooting date and time as metadata “attributes”, and the values as metadata “values” Is possible. Similarly, if the file is an MP3 (MPEG Audio Layer-3) format music file, the ID3v2 (RFC3003) tag song name, album name, performer name, etc. are metadata attributes, and the value is the metadata. It is also possible to add metadata elements as “values”.

  When the user 200 opens a folder with the file operation interface 21 (Explorer), the WebDAV client transmits a GET command with the directory as an argument to the file operation request reception mechanism 132. The metadata search mechanism 131 of the search unit 13 performs the above-described processing using a directory that is an argument of the GET command as metadata included in the file operation request.

  The file operation request accepting mechanism 132 of the search unit 13 includes, for all file IDs included in the search result, a concatenation of each metadata element corresponding to the file ID with a “_” character, and a file corresponding to the file ID. The list is returned to the WebDAV client as a response to the GET command.

  For example, when a GET command is sent to the directory “/ lakeside / photo /” for the purpose of “looking for lakeside photos”, the search result of the search unit 13 is “# 1” and “# 5”. There are two file IDs, and the file names returned as a response to the GET command are “Travel_Lake Kawaguchi” and “Trip_Lake Towada”.

  When the user 200 double-clicks a file on the file operation interface 21, the WebDAV client transmits a GET command with the file name as an argument to the file operation request reception mechanism 132. The metadata search mechanism 131 of the search unit 13 performs the above-described processing using the file name that is an argument of the GET command as metadata included in the file operation request. At this time, if a “_” character is included in the file name, the “_” character is further divided into metadata elements as a delimiter.

  The file operation request reception mechanism 132 of the search unit 13 reads the contents of the file corresponding to the file ID of the search result from the disk access mechanism 112 and returns it to the WebDAV client as a response to the GET command. In addition, when there are a plurality of search result file IDs, the above-described processing is performed on the file ID having the smallest value.

  For example, if a GET command is sent for the file “/ Lakeside / Photo / Travel_Kawaguchiko” for the purpose of “I want to see the one that came out looking for a photo of the lakeside”, the search result of the search unit 13 is The file ID is “# 1”, and the contents of this file are returned as a response to the GET command.

  When the user 200 copies a file using the file operation interface 21, the WebDAV client transmits a COPY command with the copy source and the copy destination as arguments to the file operation request reception mechanism 132. The metadata search mechanism 131 of the search unit 13 performs the above-described processing using a copy destination that is an argument of the COPY command as a set of metadata indicating a copy destination directory and metadata indicating a copy destination file name.

  For example, the file “/ Kawaguchiko / Travel / My car / Photo” is called “/ Car / Drive” for the purpose of “I want to add the metadata of car and drive to my car photo when I went to Lake Kawaguchi”. When the COPY command to be copied is transmitted, the search result of the search unit 13 is the file ID of “# 3”, and “car”, “ A “drive” metadata element is added.

  When the user 200 deletes a file using the file operation interface 21, the WebDAV client transmits a DELETE command with the file name as an argument to the file operation request reception mechanism 132. The metadata search mechanism 131 of the search unit 13 performs the above-described processing using the file name that is an argument of the DELETE command as metadata included in the file operation request. When there is no metadata element for the file ID, the search unit 13 sends a deletion request for the file identified by the file ID to the disk access mechanism 112 and deletes the file from the disk device 111.

  For example, when a DELETE command that deletes the file “/ travel / Lake Kawaguchi / Lake Lake / Photo” is transmitted, the search result of the search unit 13 is a file ID “# 2”, and the above-described metadata definition table 121 shows From the entry indicated by the file ID, the metadata elements of “photograph”, “travel”, “Lake Kawaguchi”, and “Lake on the Lake” are deleted. At this time, the metadata element of the entry indicated by the aforementioned file ID disappears, and the corresponding file and the entry in the metadata definition table 121 are also deleted.

  When the user 200 moves a file using the file operation interface 21, the WebDAV client transmits a MOVE command with the move source and the move destination as arguments to the file operation request receiving mechanism 132. The metadata search mechanism 131 of the search unit 13 performs the above-described processing using the move destination that is an argument of the MOVE command as a set of metadata representing the move destination directory and metadata representing the move destination file name.

  For example, when a MOVE command for moving a file “/ photo / travel / Lake Kawaguchi / love car” to a file “/ photo / car / drive” is transmitted, the search result of the search unit 13 is a file ID “# 3”. Thus, the metadata elements “photograph”, “travel”, “Lake Kawaguchi”, and “love car” are deleted from the entry indicated by the file ID in the metadata definition table 121. Next, metadata elements of “photo”, “car”, and “drive” are added to the same entry.

  10 and 11 are diagrams showing examples of display screens of the file operation interface 21. FIG. When Explorer is activated on the user terminal 2 and a Web folder is opened, an icon indicating the predefined file server 1 as shown in FIG. 10A is displayed. “FS1000” is the host name of the file server 1. Here, when the user 200 double-clicks the “FS1000” icon with a mouse or the like, all metadata elements for each file are retrieved from the file server 1 based on the search result of the metadata definition table 121 shown in FIG. A list of file names concatenated with “_” is returned, and a file name list as shown in FIG. 10B is displayed on the display screen of the file operation interface 21.

  Here, for example, when the user 200 adds a character string specifying the directory “/ lakeside / photo” to the address field of the display screen of the explorer and makes a directory content acquisition request, FIG. As shown, a list of two file names “Travel_Lake Kawaguchi” and “Travel_Lake Towada” is displayed on the display screen.

  Similarly, when a character string designating a directory “/ Kawaguchiko” is added to the address field of the display screen shown in FIG. 10B and a directory content acquisition request is made, as shown in FIG. A list of four file names of “photo_travel_love”, “photo_travel_lake festival”, “photo_travel_lakeside”, and “photo_travel_mountain” is displayed on the display screen.

  The user 200 can acquire the file by selecting and double-clicking the file on these display screens. After selecting a file, you can execute a file copy operation, file delete operation, file move operation, etc. by clicking the "Copy" button, "Delete" button, "Move" button, etc. .

  In addition to the configuration as the network file system described in the embodiment of the present invention, the registration unit 12 and the search unit 13 are realized as a local file system of the UNIX (registered trademark) OS, and the file operation request unit 22 stores the UNIX OS file. It is also possible to use a UNIX OS shell as the system mount function and file operation interface 21, and the vnode of the local file system as the file ID in the metadata definition table 121.

  Depending on the embodiment, a configuration in which the function of the file operation request unit 22 is provided on the file server 1 side, a configuration in which the function of the search unit 13 is provided on the user terminal 2 side, and the functions of the file server 1 and the user terminal 2 are the same device. It is also possible to have a configuration prepared for. It is also possible to employ a configuration in which a search unit 13 of a plurality of file servers is used from one file operation request unit 22 and a configuration in which one search unit 13 receives a request from a plurality of file operation request units 22.

  The processing performed by the registration unit 12, the search unit 13 and the like can be realized by a computer and a software program, and the program can be provided by being recorded on a computer-readable recording medium. Is also possible.

It is a figure explaining the outline | summary of this invention. It is a figure which shows the system configuration example of this invention. It is a figure which shows an example of the processing flow of a registration part. It is a figure which shows an example of the processing flow of a search part. It is a figure which shows an example of the processing flow of a search part. It is a figure which shows an example of a metadata definition table. It is a figure which shows an example of a cache. It is a figure for demonstrating the example of a search process. It is a figure which shows the specific example of a metadata definition table. It is a figure which shows the example of the display screen of a file operation interface. It is a figure which shows the example of the display screen of a file operation interface.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 File server 2 User terminal 11 Disk management part 12 Registration part 13 Search part 21 File operation interface 22 File operation request part 100 Registrant 111 Disk apparatus 112 Disk access mechanism 121 Metadata definition table 122 Metadata registration reception mechanism 123 Metadata Generating mechanism 131 Metadata searching mechanism 132 File operation request receiving mechanism 133 Search result cache mechanism 200 User

Claims (8)

In a file management device having a file system for managing a set of data handled by a computer as a file,
Metadata definition information storage means for storing metadata comprising one or more metadata elements defined for each file together with information for identifying each file;
Registration means for registering metadata in the metadata definition information storage means, changing and deleting metadata registered in the metadata definition information storage means;
In response to a file operation request in which some of the metadata elements are specified as a directory, the metadata definition information storage unit is referred to, and a file corresponding to the metadata including the specified metadata element is specified in the specified directory. A search means for determining as a subordinate operation target file,
A file management device that dynamically configures the hierarchical structure of directories and files in a file system according to the usage status of users. The file management device according to claim 1,
In response to an operation request for a file in which some of the metadata elements are specified, a set of metadata elements excluding the specified metadata element from the metadata of the file including all the metadata elements is used as the file name. A file management apparatus comprising means for presenting to a user. The file management device according to claim 1 or 2,
The file management apparatus, wherein the metadata elements constituting the metadata registered in the metadata definition information storage means are a value or a set of an attribute and a value representing the meaning of the file. In the file management device according to claim 1, claim 2 or claim 3,
The retrieval means has a retrieval result cache mechanism for storing information of a set of metadata obtained by searching the metadata definition information storage means and a list of information for identifying files corresponding to the metadata. A file management apparatus characterized in that a file corresponding to the metadata is specified by the search result cache mechanism, and the metadata definition information storage means is searched when the file cannot be specified by the search result cache mechanism. A dynamic namespace generation method that dynamically configures a hierarchical structure of directories and files in a file system according to the usage situation of a user,
Accepts a file registration request and registers in the metadata definition information storage means a set of file identification information that uniquely identifies the file and metadata comprising one or more metadata elements defined for the file Steps to do,
A set of metadata elements designated by the user in the metadata for each file registered in the metadata definition information storage means is a directory, and the rest of the metadata excluding the metadata elements of the directory And presenting a set of metadata elements to the user as a file name, and performing processing for a file operation request based on the combination of the directory and file name that changes according to the usage status of the user. Dynamic namespace creation method. A dynamic namespace generation method that dynamically configures a hierarchical structure of directories and files in a file system according to the usage situation of a user,
Accepts a file registration request and registers in the metadata definition information storage means a set of file identification information that uniquely identifies the file and metadata comprising one or more metadata elements defined for the file Steps to do,
Performing a file operation according to the type of file operation request received from the file operation interface,
In the step of performing the file operation, when the type of the file operation request received from the file operation interface is acquisition of directory contents, the metadata included in the file operation request is divided into metadata elements, and the divided meta data is divided. File identification information corresponding to metadata including all data elements is retrieved from the metadata definition information storage means, and a list of retrieved file identification information, metadata corresponding to retrieved file identification information, or retrieved file identification Dynamic namespace generation characterized in that the remaining metadata, excluding the metadata elements in the metadata included in the file operation request from the metadata corresponding to the information, is returned to the requester of the file operation request Method. The dynamic namespace generation method according to claim 6,
As the file operation interface, an existing interface that handles a fixed directory and a fixed file name is used. When a file operation using the file operation interface is performed, the directory and the file name depend on the usage situation of the user. A method for generating a dynamic namespace, comprising the step of converting into a metadata operation that changes dynamically.   A dynamic namespace generation program for causing a computer to execute the dynamic namespace generation method according to any one of claims 5 to 7.

Images