JP2009211403A - File search program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a file search program that allows search even if it is not clear what keywords and the like a document file or the like to be searched contains. <P>SOLUTION: In a file search system that includes a file search server, a file server having a file to be searched for and an index file about the file to be searched for, and a client, the file search program causes the file search server to operate as an index file creation means for creating the index file out of the file to be searched for, and a search means for conducting a file search using at least hash values while referring to the index file. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a file search program that creates an index file in advance for a search target file and searches a specified file with reference to the index file.

  In recent years, digitization of information has been progressing rapidly. In the past, data such as bank accounts and municipal resident's cards, which are used for reference by computer systems such as corporations and government offices to execute mission-critical operations, are stored in a file or DB (Data Base). It was the center of

  On the other hand, various documents created in daily work in organizations such as companies are now stored as document files on each employee's client PC (Personal Computer) and sent to other client PCs as e-mail attachments. Alternatively, it is stored in the file server as shared information for the entire organization. The document file stored in the file server is referred to by various employees, and is sometimes copied and updated on the client PC.

  In this way, a large amount of digital information is distributed and stored in various computers, so that a large number of duplicate or similar digital information exists in the organization. In addition, the storage capacity of each digital information continues to increase.

  On the other hand, there are many cases in the organization where it is desired to refer to digital information whose storage location is unknown, for example, a document file created once by an already retired employee is required. In such a case, a method of specifying a keyword or file creator that should be included in a document file and searching for a document file including the specified keyword is widely performed.

  However, if digital information is to be retrieved from all computers in the organization, it is necessary to permit access from all employees to the client PC of each employee, which is not preferable in terms of security. For this reason, digital information to be shared by the entire organization is generally stored in a predetermined file server.

  However, even if a document file or the like is stored in some predetermined file servers, every time a document file is needed, if all the files stored in the file server are searched, a file IO (Input Output) A huge amount of time is required to perform the above.

  For this reason, as in Patent Document 1, for a document file or the like stored in a file server, a small amount of information (index information) for use in a search, such as a storage location or a keyword, is stored as an index file. It has been known. That is, by creating an index file, it is possible to acquire index information for a plurality of files with one file IO at the time of search, and the file IO for each document file can be made unnecessary. As a result, the response time when searching for a file can be shortened, and the load on the file server can be reduced.

JP 2003-162545 A

  However, although the processing time at the time of searching can be shortened depending on the technique disclosed in Patent Document 1, only a document file or the like specified by a keyword or the like is searched. For example, the file name is changed. If there is no keyword that you think you are using, the document file you are trying to search for cannot be found.

  The present invention provides a file search program that can be searched even when it is not clear what keywords are included in a document file to be searched.

  In order to solve the above problems, a file search program according to the present invention is a file search system comprising a file search server, a file server including a search target file and an index file for the search target file, and a client. The file search server is operated as index file creation means for creating an index file from a search target file and search means for performing file search using at least a hash value with reference to the index file.

  ADVANTAGE OF THE INVENTION According to this invention, the file search program which can be searched even when it is not clear what keyword etc. contain in the document file etc. to search is provided.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be noted that each embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention. In each drawing, the same reference numerals are assigned to common components.

<First Embodiment>
FIG. 1 is a system configuration diagram of a file search system according to the first embodiment of the present invention.

  The file search system is a system in which a client 3 and a file server 1 are connected to be communicable via a wired or wireless communication line such as a LAN (Local Area Network) 4. Here, one client 3 and one file server 1 are shown, but two or more each may exist.

  In FIG. 1, the client 3 and the file server 1 are communicably connected to each other via a LAN 4. However, the connection method is not limited to the LAN, and is connected by, for example, a WAN (Wide Area Network) or the Internet. Also good.

  With the configuration described above, the client 3 transmits a file search request (hereinafter abbreviated as “search request”) to the file server 1, and the file server 1 abbreviates the file search result (hereinafter “search result”) to the client 3. ) Can be sent.

  The client 3 is composed of a device such as a PC, and is connected to the input device 32, the display device 33, and the storage device 5 so as to be communicable. The input device 32 is a device such as a keyboard or a mouse, and the operator of the client 3 can instruct a process to be executed by the client 3 by operating the input device 32. That is, the input device 32 functions as input means for the client 3.

  The display device 33 is a device such as a liquid crystal display or a printer, and displays or prints out the result of processing executed by the client 3. That is, the display device 33 functions as a display unit and an output unit of the client 3. The storage device 5 is a device such as a magnetic disk, and is built in the client 3 or connected externally. The storage device 5 and the main storage device of the client 3 (not shown) function as storage means of the client 3.

  Although not illustrated, the client 3 includes a CPU (Central Processing Unit), a main storage device, and the like. For example, the CPU loads a program such as a search request program stored in the storage device 5 onto the main memory, and executes various kinds of processing by executing the instruction code. Since the technique related to program execution as described above is well known, in the following description and drawings, in order to avoid complicated description of program execution, the search request program is referred to as search request means. Is described as if the hardware is present, and as if each means executes a process. It should be noted that each means (for example, the search request means 31) can actually be configured by an electronic device or a combination of an electronic device and firmware.

  The search request means 31 is a search request program as described above, and searches for a file search condition and a file search instruction (for example, a file whose file name is “accounting file”) input by the operator of the client 3 using the input device 32. In response to this instruction, a search condition expression is created, and a search request including the search condition expression is transmitted to the file server 1. Further, the search result transmitted from the file server 1 to the client 3 is received and displayed on the display device 33.

  The file server 1 is composed of a device such as a PC and is connected to the storage device 2 so as to be communicable. The storage device 2 is a device such as a magnetic disk, and is built in the file server 1 or connected externally. The storage device 2 and the main storage device of the file server 1 (not shown) function as storage means of the file server 1.

  The storage device 2 stores an index file 21 and a search target file 22. The contents stored in the index file 21 and the search target file 22 will be described together with the function description of the file server 1 thereafter.

  The file server 1 includes index creation means 11 (index creation program) and search means 12 (search program).

  The index creation means 11 creates the index file 21 by referring to the search target file 22 at a predetermined timing such as the same time every day. Here, the search target file 22 is a file to be searched when the file server 1 receives a search request from the client 3, for example, all files stored in the storage device 2. Alternatively, some of the files stored in the storage device 2 such as all files in a specific folder may be used.

  In any case, whenever a search request is received and a search is made with reference to the search target file 22, a large number of files IO are generated. Therefore, in order to reduce the time required for the search and to prevent an increase in the load on the file server 1 due to the search, the file name, creator, etc. of the search target file 22 are likely to be used as search conditions and are relatively small. Information on capacity (hereinafter referred to as “index information”) is stored in the index file 21.

  For example, by storing a plurality of pieces of index information in one file, a plurality of pieces of index information can be referred to by one file IO. When the file server 1 receives a search request from the client 3, it can first determine whether there is a file that matches the search condition expression of the search request by referring to the index information.

  As described above, when searching by referring to the index information, when the search target file 22 is deleted or changed after the index information is created (for example, index information is created for a file whose file name is “accounting file”). If the file is deleted after the search, a search result different from the search of the search target file 22 is obtained (referring to the index information, it appears that an “accounting file” exists). Is not present in the search target file 22). Therefore, as described above, the index creating unit 11 can perform processing at a predetermined timing such as the same time every day. By doing so, it is possible to prevent the index file 21 from being regularly updated and greatly deviating from the search target file 22.

  Then, by shortening the timing interval at which the index creating unit 11 performs processing (for example, by performing processing every hour), the difference between the index file 21 and the search target file 22 is further reduced. be able to. However, shortening the interval at which the index creation means 11 performs processing means that the interval at which IO is generated for all files of the search target file 22 is also shortened, so that the performance of the file server 1 is taken into consideration. Thus, it is necessary to determine the timing interval at which the index creating means 11 performs processing.

  For example, in the file server 1, a program that constantly monitors the CPU usage rate, the IO frequency at a certain time, etc. is run, and the index is created when the CPU usage rate, the IO frequency at a certain time, etc. become below a predetermined value. For example, the means 11 is executed. Alternatively, a program that constantly monitors the IO in the search target file 22 may be run so that the index information about the file in the index file 21 is updated each time the search target file 22 is updated. .

  The search means 12 is activated when the file server 1 receives a search request from the client 3 and executes a file search. Specifically, referring to the index file 21 (index information), it is determined whether there is a file that matches the search condition expression of the search request. If there is, a search consisting of the file name of the matched file, etc. The result is transmitted to the client 3.

  However, for example, when a search condition expression is specified to search for a file containing a predetermined keyword (for example, “07 fiscal year” and “audit result”), the search condition expression only matches the search condition expression. It may not be possible to determine whether there is a file to be processed. This is because not all the contents of the search target file 22 are stored in the index information. As described above, when it is not possible to determine whether or not there is a file that matches the search condition expression simply by referring to the index information, the search unit 12 also refers to the search target file 22 and sets the search condition expression. It is determined whether or not they match.

  FIG. 2 is a data configuration diagram of the index file 21 in the first embodiment. The index file 21 includes index records 210 corresponding to the search target files 21. That is, each index record 210 has a one-to-one correspondence with the search target file 22 when the index file 21 is created.

  The index record 210 includes data items of a file name 211, a user ID 213, an access authority 214, an access time 215, a file storage location 216, and a hash value 217. The user ID 213 and the access authority 214 are collectively referred to as a user-specific access authority 212, and are set for the number of users having access authority for the corresponding search target file 22 (m). The hash value 217 is set to 1 or more (n) as will be described later.

  The file name 211 stores the file name of the corresponding search target file 22. Specifically, for example, if the title name given by the creator of the file when creating the file and stored as attribute information of the file (for example, a property of a Microsoft Office (Microsoft is a registered trademark) file) is stored. Good.

  In the access authority 212 for each user, one or more access authorities set for the corresponding search target file 22 are stored for each user. Specifically, although not shown, for example, an access authority (for example, user 1 has a reference and update authority) given by an access management program of the file server 1 and stored as file attribute information, user 2 Only have the reference authority, etc.).

  The user ID 213 stores an ID that identifies the user among the access authorities described above. The access authority 214 stores the authority that the user has.

  The access time 215 stores the last access time of the corresponding search target file 22. Specifically, it is stored as file attribute information, and although it is not shown, the file management program of the file server 1 may store the last access time that is updated each time a file access occurs.

  In addition to the above, other file attribute information such as a file creator can also be a data item of the index record 210.

  The file storage location 216 stores the storage location of the corresponding search target file 22. For example, “// common / finantial / 074q / file2” (file2 in the “074q” folder in the “finantial” folder in the “common” folder directly under the root) may be stored. Alternatively, a relative path based on a specific folder may be stored. In addition, any information that can specify the storage location of the file may be stored.

  The hash value 217 stores n hash values (n ≧ 1) created from the stored contents of the corresponding search target file 22. The technique itself for creating a hash value from the stored contents of the file 22 is well known.

  For example, one result value obtained by converting the entire stored contents of the file with a hash function may be stored. By storing the hash value 217 created in this way, the following search becomes possible. For example, the operator of the client 3 creates a file, stores it in the storage device 5, copies the same file to the storage device 2 for sharing with other clients 3, and then stores it in the storage device 2. When it becomes unclear, a storage location of the storage device 2 can be obtained as a search result by creating a hash value from the stored contents of the file stored in the storage device 5 and searching for a file that matches the hash value. Even in the case where the original file is deleted from the storage device 5 in the above example, a hash value of the file is created before deletion and stored in the storage device 5, so that the file is copied to the storage device 2. Can be searched. When the operator of the client 3 creates a confidential file and does not want to store it in the storage device 5 indefinitely, by doing so, while preventing information leakage from the client 3, Files can be searched easily.

  Further, as the hash value 217, for example, the storage contents of the file may be converted by a hash function every 100 bytes, and the result (each hash value) may be stored. For example, if the stored content is 400 bytes long, four hash values are stored 100 bytes from the beginning (n = 4 in FIG. 2). In this way, for example, by specifying the first hash value 217 as a search condition and searching for a file that matches the first hash value 217, the original file has been changed or a file ( (Hereinafter referred to as a “similar” file).

  When creating a document file or the like, it is unlikely that a unit of length (for example, the first 100 bytes) will coincide, so if any of the hash values 217 match, it is determined that it has been changed or diverted. Because it can be done. However, for example, when a part of a document file is changed, the position on the file after the changed part is shifted. Therefore, in the method of obtaining a hash value every 100 bytes from the beginning as described above, if the vicinity of the beginning is changed. All hash values will be different.

  Therefore, the method of creating the hash value may be changed depending on the file type by referring to the file extension and the stored contents. For example, if the contents are changed and deleted without changing the contents at the time of creation, if the file is a file to which change history information is added, as described above, a hash value for each fixed length from the beginning. Should be created.

  On the other hand, if the contents are changed / deleted, etc., if the document file replaces the stored contents with the changed / deleted contents, for example, a hash value may be created corresponding to each page of the document. For example, by determining page break data, a hash value corresponding to each page can be created. Alternatively, in the case of a spreadsheet file, a hash value may be created for each sheet.

  Alternatively, each page or sheet may be divided into three, for example, and a hash value may be created for each of the first 100 bytes and the last 100 bytes. By doing this, it is possible to search for a file that has changed the original file or a file that has been diverted unless a major change that changes the number of pages is made.

  Further, for example, in the case of an XML (Extensible Markup Language) file, the storage content for which a hash value is to be created may be specified by a tag. For example, a result value obtained by converting between <Hash> tag and </ Hash> tag by a hash function may be stored. By doing so, the creator of the file himself / herself can determine the creation target of the hash value. Therefore, the original file is changed by specifying the stored contents as a hash value creation target and storing the hash value in the storage device 5 because it is a part unique to the file and has the possibility of being changed. Files and files created by diversion can be searched more reliably. By specifying the <Hash> tag and </ Hash> tag for a plurality of stored contents and creating two or more hash values, it is possible to search more reliably.

  In the index record 210, data other than the hash value 217 may be created and stored from the stored contents of the file. For example, words that appear frequently in the data of the file may be stored. In this way, even in a search specifying a keyword, it is possible to search by referring to the index file 21 without referring to the search target file 22.

  The index record 210 stored as described above is referred to by the search means 12 as the index information described above.

  FIG. 3 is a flowchart showing the operation of the index creating means 11 in the first embodiment.

  As described above, the index creating means 11 deletes the index file 21 when activated at a predetermined timing (S301).

  Next, the index creating means 11 performs the index record 210 creation processing and the like (S302, S304) for all the search target files 22.

  For example, when all the files in a specific folder in the storage device 2 are search target files 22, the index creating means 11 sequentially refers to the files in the folder and creates an index record 210 for each file. That is, referring to the attribute information of the file, the file name 211, the user-specific access authority 212, and the access time 215 are set, and the storage location of the search target file 22 is set as the file storage location 216. Further, the hash value created from the stored contents of the search target file 22 is set as the hash value 217, and the index record 210 is stored in the storage device 2 (S302). The specific setting contents of each data item are as described with reference to FIG.

  When the index creation unit 11 creates the index record 210 (S302), the index access unit 11 restores the last access time of the search target file 22 (S304). This is because the last access time is updated by referring to the search target file 22 in order to create the index record 210, so that the time stored before the reference is restored. Specifically, the last access time of the search target file 22 may be updated with the access time 215. Note that if the file contents are referenced before referring to the file attribute information such as the last access time, the last access time is updated and cannot be restored. Then you need to refer to the contents of the file.

  When the index record 210 creation processing or the like (S302, S304) is performed for all the search target files 22, the index creation unit 11 ends the processing.

  As described above, in the first embodiment, each time the index creating unit 11 performs processing, the index file 21 is recreated in accordance with the search target file 22 at the time of processing.

  FIG. 4 is a flowchart showing the operation of the search request unit 31 in the first embodiment. The search request means 31 is activated by the operator of the client 3 using the input device 32.

  When activated, the search request unit 31 performs a login process (S401). Specifically, a login screen as shown in FIG. 7 is displayed on the display device 33, and the operator of the client 3 inputs the user ID and password using the input device 32 and presses the “execute” button. It is determined whether the entered user ID and password are appropriate. Since the login process itself is a well-known technique, further explanation is omitted.

  When it is determined that the input user ID and password are appropriate, the search request unit 31 displays a search request screen on the display device 33 (S402). FIG. 8 shows a display example of the search request screen. In FIG. 8, the search request screen includes a search condition part G81, a search result part G82, and “search” and “end” buttons.

  The operator of the client 3 uses the input device 32 to input each item in the search condition part G81. The item input to the search condition part G81 is a search condition. For example, when “USER3” is input as the user ID and “R” is input as the access authority, a file for which USER3 has the reference authority is searched. Here, the convenience of search can be improved by enabling various input methods for each item of the search condition part G81. For example, if it is possible to input a logical expression such as “not USER1”, “USER1 or USER2” for the user ID, or “R only” (only reference authority and no update authority) for the access authority, etc. Good. Note that the input items of the search condition part G81 need not be limited to the illustrated items, and may be determined together with the data items of the index file 21, such as a file name and a hash value. Further, even if the item is not included in the data item of the index file 21, any item may be used as long as it is an item that can be collated with the attribute information or stored content of the search target file 22.

  In the search result part G82, the search result is scroll-displayed. The display contents of the search result part G82 will be specifically described below.

  After the search request screen is displayed (S402), the search request means 31 waits for the search button or the end button to be pressed (S403, S405). When the search button is pressed, that is, when a search request is detected, search request processing (S406, S407, S409) is performed (S403). If the end button is pressed, that is, if an end request is detected, the process ends (S405).

  When detecting the search request, the search request unit 31 creates a search condition from the input content of the search condition part G81 and transmits it to the file server 1 (S406). For example, if “USER3” is entered for the user ID, “R” is entered for the access authority, and “2007” is entered for the keyword, “Search * (user ID = USER3) and (access authority = R) and (keyword = A search condition expression such as “2007” is created and transmitted to the IP address of the file server 1 together with the user ID entered on the login screen. Here, the search condition expression is an expression interpreted by the search means 12, and may be created according to a syntax rule or the like that can be interpreted by the search means 12. For example, for the access time, input such as “200707011200:” (after July 1, 2007 12:00) is permitted, and a search condition expression such as “Search * (access time> = 200707011200)” is created from this input. do it. For example, for the hash value, input such as “2:16 shiek0igatrelk7” (a value of 15 bytes from the second byte to the 16th byte of the hash value is “shiek0igatrelk7”) is permitted. A search condition expression such as “value (2:16) = shiek0igatrelk7)” may be created.

  If the user ID is not input, the search condition formula may be created assuming that the user ID input on the login screen is input. At this time, if the access authority is not input, the search condition expression may be created assuming that the file having the reference authority is supported.

  The search request unit 31 waits until the search result is received from the file server 1 after transmitting the search condition formula to the file server 1 (S407). When the search result is received, the search result is displayed on the search result part G82 of the search request screen (S409), and it waits for the search button or the end button to be pressed again (S403, S405).

  Here, for example, the contents shown in FIG. 9 are displayed in the search result part G82 (S409). In FIG. 9, “server1.somecompany.co.jp/finantial/074q/file2” (hereinafter referred to as “file A”) and “server1.somecompany.co.jp/mailbox/user3/file2” (hereinafter referred to as “file B”). And “server1.somecompany.co.jp/section1/user3/file1” (hereinafter referred to as “file C”). Files A and B are files that match the search condition formula. On the other hand, the file C does not match the search condition formula, but is a file similar to the file B. In order to notify the operator of the client 3 of this, the file C is displayed below the file B with the display start position shifted. A method for determining whether or not the files are similar will be described later in the processing description of the search means 12.

  In addition, when access authority is set for a plurality of users as in file A (in the example of FIG. 9, reference and update authority is set for USER1, and reference authority is set for USER3. As shown in FIG. 9, all the set access authorities may be displayed in multiple stages.

  In order to enable such display, the data items (file name 211, access authority by user 212, access time 215, file storage location 216) of the index record 210 are sent from the search means 12 to the client 3 as search results. In addition to the hash value 217), a data item indicating whether the file matches the search condition or a file that does not match but is similar may be transmitted. When the search request unit 31 displays the search result on the search result part G82, a file that matches any of the hash values 217 among similar but not matching files is displayed under the file that matches the search condition. do it.

  In addition to the one shown in FIG. 9, any data item included in the search result can be displayed as it is or after being edited on the search result portion G82.

  FIG. 5 is a flowchart showing the operation of the search means 12 in the first embodiment. The search unit 12 is activated by the file server 1 when the file server 1 receives a search request from the client 3.

  First, the search unit 12 analyzes the search condition formula included in the search request, refers to the index file 21 (index record 210), and selects a file (index record 210) that matches the search condition (S501). For example, when the search condition expression is “Search * (user ID = USER3) and (access authority = R) and (keyword = fiscal 2007)”, the user ID 213 is “USER3” and the access authority 214 is “ All index records 210 for which “can be referred to” are selected are selected.

  Next, the search means 12 determines whether or not a keyword specification is included in the search condition formula (S502), and if it is included (for example, a condition such as “keyword = 07 year” is specified as in the above search formula). In the case where all the files selected in S501 are searched, keyword search is executed (S503), and a file (index record 210) to be transmitted is determined as a search result. On the other hand, for example, when the search condition formula is “Search * (user ID = USER3) and (access authority = R)”, the keyword search is not included in the search condition formula, so the keyword search is not performed. All the files (index record 210) selected in S501 are targeted for transmission.

  After determining the file (index record 210) to be transmitted by the above processing, the search unit 12 refers to the index file 21 (index record 210) again and re-sends a file (index) similar to the file to be transmitted. The record 210) is selected (S504). Specifically, for each index record 210 that is a transmission target, the hash value 217 is compared with the hash value 217 of the index record 210 that is not a transmission target, and all index records 210 that match either one are selected. In this way, it is possible to search for similar files exhaustively. The selection may be made not on the condition that any one of the hash values 217 matches, but on the condition that, for example, more than half (three or more if five hash values 217 are stored) match. . In this way, only a more similar file (index record 210) can be selected.

  The search unit 12 uses the data items (file name 211, user-specific access authority 212, and the like for all of the index records 210 of the files to be transmitted in the processing of S501 to S503 and the similar file index records 210 selected in S504. The access time 215, the file storage location 216, and the hash value 217) are transmitted to the client 3 as a search result. At this time, for each index record 210, a data item indicating whether the file matches the search condition or a file that does not match but is similar is also transmitted (S505). The search means 12 ends the process after transmission.

  FIG. 6 is a flowchart of the keyword search process (S503) of the search means 12 in the first embodiment.

  The search unit 12 determines whether the operator of the client 3 has the reference authority for the file selected in the process of S501 (referred to as “selected file” in the following description of FIG. 6) (S601). If you do not have file reference authority, performing a keyword search for the selected file tells the operator that the keyword is included, and part of the stored contents of the file will be known. Does not meet the purpose not given. Therefore, the index record 210 is referred to determine whether or not the keyword search is possible. Specifically, the user ID included in the search request received from the client 3 is collated with the user ID 213 for the selected file, and it is determined whether or not “reference” is permitted as the access authority 214.

  When there is no reference authority (NO in S601), the search unit 12 refers to the hash value 217 of the index record 210, the same hash value 217 is set, and the operator of the client 3 has the reference authority. It is determined whether or not there is an index record 210 (referred to as “similar index record” in the following description of FIG. 6) (S602). This is because a file having the same content is duplicated as an attached document of e-mail, for example, and there may be a plurality of files having the same content but different access rights. In particular, for a file that is frequently referred to by a large number of clients 3, in other words, a file that is likely to be searched by an operator of the client 3, there is a high possibility that a plurality of files having the same contents but different access rights exist. . Accordingly, there is a high possibility that there is a file that does not match the search condition but has the same content and the operator of the client 3 who requested the search has the reference authority. Thus, referring to the hash value 217 makes the content Searching for the same file is an effective technique.

  At this time, when a plurality of hash values 217 are set in the index record 210 for the selected file, the operator of the client 3 gives the reference authority to the index record 210 in which only some of the hash values 217 are set. What is necessary is just to determine whether it has. For example, when three hash values A, hash values B, and hash values C are set as the hash value 217 in the index record 210 for the selected file, two hash values 217 of the hash value A and the hash value C are set. The index record 210 being processed is a determination target. For example, when a hash value is created for each page of a document file, such a phenomenon occurs when the second page of a document file originally composed of three pages is deleted.

  When the similar index record does not exist (NO in S602), the search unit 12 excludes the selected file from the transmission target (S603).

  On the other hand, when the operator of the client 3 has a reference authority for the selected file (YES in S601), the search unit 12 refers to the file by the file storage location 216, and the keyword condition of the search condition formula is It is determined whether they match (S604). If there is a similar index record (YES in S602), the files in the file storage location 216 are referred to for all the similar index records (referred to as “similar files” in the following description of FIG. 6). It is determined whether the keyword condition of the search condition formula is met (S604).

  The method of determining whether or not the keyword condition matches is a well-known technique and will not be described in detail. For example, when the search condition “keyword = 07 year” is specified, a file including the word “07 year” When the search condition “keyword not = 07” is specified, a file that does not include the word “07” may be determined as a matching file. In addition, keyword conditions can be combined with various logical expressions.

  If the keyword condition matches (YES in S604), the search unit 12 sets the selected file as a transmission target (S605). If the keyword condition does not match (NO in S604), the search unit 12 excludes the selected file (S606). ).

  In addition, the search unit 12 returns the last access time to the state before the reference for all the files referred to in the process of S604 (that is, the selected file and the similar file). Specifically, in the process of S604, the last access time is first acquired before the file reference, and the last access time acquired after the reference is set.

  In addition to the above processing, the search unit 12 may update each data item of the index record 210 when referring to the selected file and the similar file. By doing in this way, the data item of the index record 210 can be kept in the state close to the newest at every search, without performing extra file IO.

<Second Embodiment>
FIG. 10 is a data configuration diagram of the index file 21 in the second embodiment according to the present invention. Note that the system configuration of the file search system in the second embodiment is the same as that of the first embodiment and is as described in FIG.

  The data structure of the index file 21 in the second embodiment is also substantially the same as that of the first embodiment, except that a deletion time 218 is provided.

  Here, the deletion time 218 is a data item for indicating whether or not the search target file 22 corresponding to the index record 210 has been deleted. Whether or not the search target file 22 has been deleted depends on the index creation means 11. Judgment. That is, when creating the index record 210 for the search target file 22, the index creation unit 11 sets a value (for example, “0”) indicating that the index record 210 is not deleted at the deletion time 218, and corresponds to the index record 210. When it is determined that the search target file 22 to be deleted has been deleted, the date and time of determination is set.

  As described above, in the second embodiment, each index record 210 of the index file 21 is updated each time the index creating unit 11 performs processing, instead of re-creating the index file 21 at a predetermined timing. That is, in the second embodiment, since the index record 210 exists for the deleted search target file 22, for example, as will be described later, the update / replication of the same or similar file including the deleted file is performed. It is also possible to search the history.

  FIG. 11 is a flowchart showing the operation of the index creating means 11 in the second embodiment.

  The index creation unit 11 sequentially refers to all the files of the search target file 22 and performs index creation / update processing (processing of S301, S302, S303, and S304) for each file. Although this point is similar to the first embodiment, the index creation means 11 does not delete the index file 21 when activated (S301 in FIG. 3), but there is an undeleted index record 210 for each file. It is determined whether to do (S301). Specifically, there exists an index record 210 in which the file storage location of the file matches the file storage location 216 of the index record 210 and the deletion time 218 is not set (for example, “0” is set). It is determined whether or not.

  When it exists (in the case of YES in S301), each data item of the index record 210 is updated, and the updated index record 210 is stored in the storage device 2 (S302). If it does not exist (NO in S301), each data item of the index record 210 is set, and the index record 210 is stored in the storage device 2 (S303). The specific update contents (setting contents) of each data item are as described with reference to FIGS. In either case, the last access time of the search target file 22 is restored (S304). Details of the processing in S304 are as described in FIG.

  After completing the above-described index creation / update process, the index creation unit 11 deletes the index record 210 for which the corresponding search target file 22 does not exist (S305). Specifically, among all the index records 210 that have not been created or updated in the index creation / update process, the system date is set to the deletion time 218 of the index record 210 for which the deletion time 218 is not set. . That is, the fact that neither creation nor update was performed in the index creation / update process means that the file was deleted (or the file storage location was changed) after the index record 210 was created, and the file was deleted. The fact that the time 218 is not set means that the index creation means 11 has been deleted after the previous processing. Therefore, a deletion time 218 is set to indicate that it has been deleted, and since the actual deletion time is unknown, at least to indicate that it has been deleted at this time, the system year The date and time are set.

FIG. 12 is a diagram illustrating the display contents of the search result on the search request screen in the second embodiment. For example, on the search request screen, USER3 has reference authority and an input is made to search for a file containing “07th Q4” as a keyword.
"Server1.somecompany.co.jp/finantial/074q/file2" (hereinafter referred to as "File A") and "server1.somecompany.co.jp/mailbox/user3/file2" (hereinafter referred to as "File B") Fall under
Furthermore, “server1.somecompany.co.jp/section1/user3/file1” (hereinafter referred to as “file C”) and “server1.somecompany.co.jp/section1/user3/file7” (hereinafter referred to as “file D”) If the file does not meet the conditions but is similar to the file B, the search result is displayed as shown in FIG. Here, “[Delete]” is displayed for the file D because the deletion time 218 of the index record 210 of the file D is set. By displaying similar files including deleted files in this order, for example, in descending order of access time 215, the file update history of the searched file can be grasped more accurately.

<Third Embodiment>
FIG. 13 is a system configuration diagram of a file search system according to the third embodiment of the present invention. The third embodiment has a configuration in which a search history file 51 is added to the first embodiment or the second embodiment. FIG. 13 explicitly shows that there are a plurality of file servers 1.

  The search history file 51 stores a search history performed by the operator of the client 3 for each file server 1. Specifically, every time the search request unit 31 transmits a search request to each file server 1 and receives a search result from each file server 1, the time required for the search for each file server 1 in the search history file 51. Is memorized.

  FIG. 14 is a data configuration diagram of the search history file 51 in the third embodiment. The search history file 51 stores a search history record 510 for each file server 1.

  The search history record 510 includes a server name 511, a server address 512, and a search history 513. Among these, the server name 511 and the server address 512 are information for specifying the file server 1 to be searched by the client 3, and are set before the operator of the client 3 performs the search. In the server name 511, information for identifying the file server 1 by the operator of the client 3 such as “file server A” is set. The server address 512 is set with information for identifying the destination to which the search request means 31 should send the search request, such as the IP address of the file server 1.

  The search history 513 is not set when the search history record 510 is stored for the first time, and the history is stored every time a search is performed. That is, m (m ≧ 0) search histories 513 are stored in the search history record 510.

  Each search history 513 includes a search presence / absence 514, a hit file number 515, a target file number 516, and a response time 517, and each item is set by the search request means 31.

  The search presence / absence 514 indicates whether or not the file server 1 is a search target in each search (that is, whether or not a search request is transmitted). Is set to “None”. The number of hit files 515, the number of target files 516, and the response time 517 are set only when the search presence / absence 514 is “Yes”.

  The number of hit files 515 is set with the number of files (number of index information) received as a search result at the time of the search. In the target file number 516, the number of index records 210 stored in the file server 1 at the time of the search is set. The target file number 516 may be transmitted to the client 3 by the search unit 12 together with the search result. The response time 517 is set to the time from when the client 3 sends a search request to the file server 1 until the search result is received.

  FIG. 15 is a flowchart showing the operation of the search request unit 31 in the third embodiment. The following description will focus on the differences from the operation (FIG. 4) of the search request unit 31 in the first embodiment.

  If it is determined that the input user ID and password are appropriate after the login process (S401), the search request unit 31 displays a search request screen on the display device 33 (S402). FIG. 16 shows a display example of the search request screen. The difference from the search request screen (FIG. 8) in the first embodiment is that a “history” button is displayed in addition to the “search” and “end” buttons. As in the first embodiment, the operator of the client 3 uses the input device 32 to input each item in the search condition part G81.

  After the search request screen is displayed (S402), the search request unit 31 waits for a history button, a search button, or an end button to be pressed (S403, S404, S405). When the history button is pressed, that is, when a search history display request is detected, a history display / server selection process (S410) is performed (S403). When the search button is pressed, that is, when a search request is detected, search request processing (processing after S406) is performed (S403). If the end button is pressed, that is, if an end request is detected, the process ends (S405).

  When detecting the search history display request, the search request means 31 displays a search history display screen on the display device 33 and waits for the end button to be pressed (S410). FIG. 17 shows a display example of the search history display screen.

  The search history display screen includes a search history display portion G171 and an “end” button. The search request means 31 displays all the server names 511 stored in the search history file 51 and the search history for each server name 511 in the search history display part G171. As the search history, for example, the number of hit files 515 in which the search presence / absence 514 is “Yes”, the number of target files 516, and the response time 517 may be displayed as they are. For example, the first search history 513 (search presence / absence 514, hit file number 515, target file number 516, and response time 517) of the server A is “present”, “20”, “100”, “4.9”, respectively. The second search history 513 is “Yes”, “10”, “100”, “4.2”, and the first search presence / absence 514 of the server B is “None”. When the search histories 513 are “Yes”, “30”, “200”, and “3.8”, 20 files, 100 files, 4.9 seconds, 10 files, 100 files, 4 to the right of the server A .2 seconds are displayed, and 30 items, 200 files, and 3.8 seconds are displayed on the right side of the server B with a space for three items. Thus, by displaying the past search history for each file server 1 in association with each other, the operator of the client 3 is the file server 1 from which more search results are obtained under the same search condition. In addition, it is possible to know which file server 1 has a short response time under the same search condition.

  Here, in order to display the search history in an easy-to-understand manner, the number of hit files 515, the number of target files 516, and the response time 517 are not displayed as described above. By dividing, the hit rate may be calculated, and the hit rate may be displayed in place of the hit file number 515 and the target file number 516. For example, in the above example, 0.2, 4.9 seconds, 0.1, 4.2 seconds are displayed on the right side of the server A, and a space for two items is left on the right side of the server B. .15, 3.8 seconds may be displayed. By doing so, the operator of the client 3 can search for the file server 1 having a high hit rate for a short response time.

  Further, both the hit rate and response time may be displayed in a relative manner. That is, for the file server 1 displayed on the top row of the search history display section G171, both the hit rate and response time are all displayed as 1.0, and other file servers 1 are connected to the top file server 1. Display the comparison value. For example, in the above example, 1.0, 1.0, 1.0, and 1.0 are displayed to the right of server A, and a space for two items is left to the right of server B. 0.9 can be displayed. By displaying in this way, the comparison of the hit rate and response time for each file server 1 can be displayed more easily. FIG. 17 shows an example in which such a display is performed. The operator of the client 3 always has a higher hit rate and a shorter response time in the server B than in the server A (more efficient). Can be easily grasped).

  Furthermore, for example, when the server name displayed in the search history display part G171 is clicked with the input device 32, the hit rate and response time of the clicked file server 1 are all set to 1.0. A comparison value with the clicked file server 1 may be displayed. By doing so, the operator of the client 3 can easily identify the file server 1 having a larger hit rate than the specific file server 1 or the file server 1 having a shorter response time.

  In the search history display part G171, a check box is displayed to the left of the server name. The operator of the client 3 can select the file server 1 to be searched by referring to the displayed search history, for example, by checking the check box of the file server 1 that is searched most efficiently. it can.

  When the end button of the search request screen is pressed, the search request means 31 stores the server address 512 of the file server 1 whose check box is checked in the main storage device or the like of the client 3, and displays the search request screen again. , And waits for the history button, the search button, or the end button to be pressed (S403, S404, S405).

  When detecting the search request, the search request unit 31 creates a search condition from the input content of the search condition part G81 and transmits it to all the file servers 1 (S406). Specifically, the server address 512 is acquired for all the file servers 1 stored in the search history file 51, and a search request is transmitted to all the acquired server addresses 512.

  Here, when the file server 1 to be searched is selected on the search history display screen, only the selected file server 1 is set as the search target. Specifically, the server address 512 of the file server 1 to be searched is acquired from the main storage device of the client 3 and the search request is transmitted to all the acquired server addresses 512.

  After transmitting the search condition formula to the file server 1, the search request means 31 waits until the search results are received from all the transmitted file servers 1 (S407). When the search result is received, all the search history records 510 in the search history file 51 are updated (S408). Specifically, for the file server 1 that has not received the search result, a search history 513 in which “none” is set in the search presence / absence 514 is added, and for the file server 1 that has received the search result, the search presence / absence 514 is set. “Yes”, the number of hit files received as the hit file number 515, the number of index information received as the target file number 516, and the response time 517 after sending a search request to the file server 1, A search history 513 in which a time until receiving a search result from the server is set is added. The search history may be, for example, up to 10 and store only the latest 10 histories.

  Next, the search request unit 31 displays the search result on the search result part G82 of the search request screen (S409), and waits for the history button, the search button, or the end button to be pressed again (S403, S404, S405). ).

  Here, for example, the contents shown in FIG. 18 are displayed in the search result part G82. In the example of FIG. 18, search results are received from two file servers 1 of “server1.somecompany.co.jp” and “server3.somecompany.co.jp” and displayed.

<Fourth Embodiment>
FIG. 19 is a system configuration diagram of a file search system according to the fourth embodiment of the present invention.

  In the fourth embodiment, unlike the first, second, and third embodiments, the file server 1 does not include the index creation unit 11 and the search unit 12.

  Instead, a file search server 6, which is a device such as a PC, is connected to the client 3 and the file server 1 via the LAN 4, and the file search server 6 includes an index creating unit 11 and a search unit 12.

  Further, the search target file 22 is stored in the storage device 2 of the file server 1, but the index file 21 is not stored. The index file 21 is stored in the storage device 7 that is communicably connected to the file search server 6. The storage device 7 is a device such as a magnetic disk and is built in the file search server 6 or connected externally. The storage device 7 and the main storage device of the file search server 6 (not shown) function as storage means of the file search server 6.

  In the fourth embodiment, it is clearly indicated that the file server 1 includes file management means 13 (file management program). The file management unit 13 has a function of performing I / O to the file stored in the storage device 2 and exists in the first, second, and third embodiments. The form is specified for the following explanation.

  The data structures of the index file 21 and the search target file 22 are the same as those in the first, second, and third embodiments, and the operations of the index creation unit 11, the search unit 12, and the search request unit 31 are the same as those in the first and second embodiments. 2. Basically the same as the third embodiment. Hereinafter, the difference will be mainly described.

When the index creating means 11 is activated, it requests the file server 1 that is communicably connected via a communication line such as LAN 4 to transmit the index information (index record 210) of the search target file 22. Here, when there are a plurality of file servers 1, the IP address of the file server 1 to be requested for transmission may be stored in advance in the storage device 7 or the like.
Then, the index file 21 is created / updated with reference to the index information transmitted from the file server 1. In the file storage location 216, a storage location including the IP address and URL of the file server 1 is set.

  Further, when receiving the transmission request for the index information, the file management unit 13 of the file server 1 refers to all the search target files 22, creates index information, and transmits the index information to the requesting file search server 6. At this time, the point that the last access time of the search target file 22 is returned to the reference is the same as described above.

  The search request means 31 of the client 3 transmits a search request not to the file server 1 but to the file search server 6. Then, the search unit 12 refers to the index file 21 and the search target file 22 as necessary, and transmits the search result to the client 3. When the search unit 12 refers to the search target file 22, it requests the file server 1 indicated by the file storage location 216 to transmit the search target file, and the file management unit 13 of the file server 1 receives this request. The designated search target file 22 is acquired and transmitted to the file search server 6.

  As in the fourth embodiment, the file search server 6 and the file server 1 are separated so that the client 3 can add, change, and delete the file server 1 without changing the destination to which the client 3 sends a search request. Is possible.

  That is, in the first, second, and third embodiments, since the file server 1 also serves as the file search server 6 (the file server 1 and the file search server 6 are integrated), the search is performed. In order to widen the target range, the file server 1 including the search target file 22 is connected to the LAN 4 or the like, the file server 1 includes the index creating unit 11 and the search unit 12, and the search request transmission destination of each client 3 Must be added.

  On the other hand, in the fourth embodiment, the search request transmission destination of the file search server 6 needs to be added, but the addition of the search request transmission destination of each client 3 becomes unnecessary. In general, the number of clients 3 in the organization ranges from several tens to several hundred times more than the number of file search servers 6, so that it is not necessary to add a search request transmission destination of each client 3. The file server 1 can be easily added / changed / deleted.

  FIG. 20 is a system configuration diagram of a file search system according to the fifth embodiment of the present invention.

<Fifth Embodiment>
In the fifth embodiment, only the client 3, the file server 1, the file search server 6, and the LAN 4 are illustrated, but the display of each storage device, means, etc. is simply omitted. The file server 1 and each file search server 6 have the same configurations as those of the first, second, third, and fourth embodiments. As shown in FIG. 20, a plurality of file search servers 6 can be connected to one or more file servers 1 via a LAN 4 so that they can communicate with each other, and a search request can be transmitted from each client 3 to a plurality of file search servers 6. It is.

  In addition to what has been described so far by using the file search system described above, for example, investigation of file contents tampering by suspicious employees etc. by searching for files for which specific users have update authority It becomes possible to do. Alternatively, unnecessary files can be investigated by searching for files that have not been referenced for a long time using the access time (files whose last access time is before a predetermined year, month, day, time).

  In this way, by making it possible to search for a file based on access authority, access time, hash value, etc., various searches according to the purpose can be performed even when the keywords included in the file are not accurately known.

<Others>
The present invention can also be realized by a program code of software that realizes the functions of the embodiments. In this case, a storage medium in which the program code is recorded is provided to the system or apparatus, and the computer (or CPU or MPU) of the system or apparatus reads the program code stored in the storage medium. In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiment, and the program code itself and the storage medium storing the program code constitute the present invention. As a storage medium for supplying such program code, for example, floppy (registered trademark) disk, CD-ROM, DVD-ROM, hard disk, optical disk, magneto-optical disk, CD-R, magnetic tape, non-volatile A memory card, ROM, or the like is used.

  Also, based on the instruction of the program code, an OS (operating system) running on the computer performs part or all of the actual processing, and the functions of the above-described embodiments are realized by the processing. May be. Further, after the program code read from the storage medium is written in the memory on the computer, the computer CPU or the like performs part or all of the actual processing based on the instruction of the program code. Thus, the functions of the above-described embodiments may be realized.

  In addition, by distributing the program code of the software that realizes the functions of the embodiment via a network, it is stored in a storage means such as a hard disk or memory of a system or apparatus or a storage medium such as a CD-RW or CD-R. The program code stored in the storage means or the storage medium may be read out and executed by the computer (or CPU or MPU) of the system or apparatus during storage.

It is a system configuration figure of a file search system in a 1st embodiment concerning the present invention. It is a data block diagram of the index file in 1st Embodiment. It is a flowchart which shows operation | movement of the index preparation means in 1st Embodiment. It is a flowchart which shows operation | movement of the search request | requirement means in 1st Embodiment. It is a flowchart which shows operation | movement of the search means in 1st Embodiment. It is a flowchart of the keyword search process of a search means in 1st Embodiment. It is the figure which illustrated the login screen in 1st Embodiment. It is the figure which illustrated the search request screen in 1st Embodiment. It is the figure which illustrated the display contents of the search result in a search request screen in a 1st embodiment. It is a data block diagram of the index file in 2nd Embodiment which concerns on this invention. It is a flowchart which shows operation | movement of the index preparation means in 2nd Embodiment. It is the figure which illustrated the display contents of the search result in a search request screen in a 2nd embodiment. It is a system configuration figure of a file search system in a 3rd embodiment concerning the present invention. It is a data block diagram of the search history file in 3rd Embodiment. It is a flowchart which shows operation | movement of the search request | requirement means in 3rd Embodiment. It is the figure which illustrated the search request screen in 3rd Embodiment. It is the figure which illustrated the search history display screen in 3rd Embodiment. It is the figure which illustrated the display contents of the search result on a search request screen in a 3rd embodiment. It is a system configuration figure of a file search system in a 4th embodiment concerning the present invention. It is a system configuration figure of a file search system in a 5th embodiment concerning the present invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... File server, 11 ... Index preparation means, 12 ... Search means, 13 ... File management means, 2 ... Storage device, 21 ... Index file, 22 ... Search object file, 3 ... Client, 31 ... Search request means, 32 ... Input device 33 ... Display device 4 ... LAN 5 ... Storage device 51 ... Search history file 6 ... File search server 7 ... Storage device

Claims (1)

  In a file search system comprising a file search server, a file server having a search target file and an index file for the search target file, and a client, the file search server creates the index file from the search target file An index file creation unit and a file search program that operates as a search unit that performs a file search using at least a hash value by referring to the index file.

Images