JP2009230583A - File sharing method and system, server device, client device, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently use the storage capacity of a server device in a system in which a plurality of client devices share files held by a client device. <P>SOLUTION: A server device is prevented from having a shared file in the case other than that there is need to have a shared file. In order to achieve this, client devices are made to have a file entity, and a server device manages a link to the file entity. When the client device stops or eliminates the shared file, the server device fetches the shared file from the client device and provides the other client devices with the shared file. Meanwhile, when referring to the shared file, the other client devices create a file link for surely accessing the shared file via the server device in their own devices to manage the shared file. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

 The present invention relates to a file sharing method and system, a server device, a client device, and a program. For example, the present invention relates to a configuration for publishing a file held by a client device as a shared file.

  When sharing a file held by a client device as a shared file, there is a file sharing method using a file server having a duplicate file elimination function for file sharing that efficiently uses the storage capacity of the server device. In this method, when a user of a client device wants to publish a local file owned by the client device as a shared file, the user requests uploading to the file server. If the upload is successful, it is stored as a shared file on the server, and a success message is notified to the client device. When the server receives an upload request for the same file as the file already held, the server notifies the client device of a failure message to eliminate duplication of the file. For example, Non-Patent Document 1 shows an example of such a deduplication function.

Data protection Veritas NetBackup PureDisk 6.2 (http://eval.symantec.com/mktginfo/en/us/enterprise/fact_sheets/nbu_pd62_ds_dpro.pdf) JP 2004-5491 A

  The method according to Non-Patent Document 1 described above has an advantage that useless storage due to duplication of the same file can be avoided by not transferring the same file to the server.

  However, in order to store files without duplication, the server also needs a certain amount of storage. In addition, duplication of files between the server and the client remains, and an inefficient portion remains from the viewpoint of storage capacity usage. In this case, the file entity (data of the file itself) must be constantly stored in the server, and the server resources cannot be used efficiently. In order to efficiently use server resources, it is important to install file entities on the server as much as possible, unless it is unavoidable.

  The present invention has been made in view of such a situation, and provides the maximum efficient utilization of server and client resources for file sharing.

  In order to solve the above-described problem, in the present invention, the server device is configured not to have a shared file except when necessary. In order to realize this, the client device holds the file entity, and the server device manages the link to it. When the client device is stopped or the shared file is deleted, the server device sucks the shared file from the client device and provides the shared file to other client devices. On the other hand, when referring to the shared file, other client devices should create and manage a file link in the device to ensure that the shared file is accessed via the server device. To do.

  More specifically, the present invention relates to a system including a plurality of client devices and a server device, and capable of sharing files between the client devices, and a shared file management method for managing shared files in the system. Is. In this method, one client device among a plurality of client devices designates a held file as a shared file shared with other client devices, and manages the entity of the shared file. When a shared file is designated from one client device, the server device manages an entity file link indicating a location where the shared file entity is stored, and the one client device manages the shared file entity. Managed as a file entity registration client to save. When there is a request for access to the shared file from another client device based on the entity file link, the server device refers to the entity file link and requests another client to access the shared file acquired from one client device. Provide to the device.

  In addition, when one client device among a plurality of client devices designates a file held as a shared file and the same file has already been registered as a shared file in another client device, it is registered in the server device. Create and manage a reference file link that is a link to the file link of the shared file that is being shared, and delete the entity of the same file as the shared file. The server device manages the client device that manages the reference file link as a file reference registration client. In this case, the server device generates an auxiliary file link that becomes a link to the entity file link, the reference file link directly links to the auxiliary file link, and the file reference client cannot directly access the file entity registration client to acquire the shared file. Manage the file reference registration client (so as not to be peer to peer access).

 Further, when the file entity registration client deletes the entity of the shared file or when the file entity registration client stops, the server device acquires the entity of the shared file from the file entity registration client when the file reference registration client exists. The entity file link is changed to the storage location in the server device. When the file entity registration client deletes the shared file entity, when the file reference registration client accesses the shared file acquired by the server device, the server device transmits the shared file entity to the file reference registration client. At the same time, the file reference registration client is changed to a file entity registration client for management. Further, when the file entity registration client is stopped, when the file reference registration client accesses the shared file acquired by the server device, the server device transmits the entity of the shared file to the file reference registration client, and the file reference Manage the client as a file reference registration client without changing the registration client to a file entity registration client. On the other hand, when the file entity registration client is activated from the stopped state, the server device deletes the acquired shared file entity from the server device and returns the entity file link to the storage location in the file entity registration client.

  The present invention provides a server device that manages information of the plurality of client devices and the shared file so that the files can be shared among the plurality of client devices. The server device includes server data management means for managing information of a file entity registration client, which is a client device that stores the entity of a shared file, and an entity file link that indicates a storage location of the entity of the shared file.

  The server data management means further includes information on a file reference registration client that is a client device other than the file entity registration client and that can access the shared file, and a reference file that is a link to the entity file link. Manage links. Further, the server data management means registers the entity of the shared file when the file entity registration client deletes the entity of the shared file, or when the file entity registration client stops, and when the file reference registration client exists. Obtain from the client and change the entity file link to the storage location in the server device.

  The present invention provides a client device constituting a part of a system in which a server device and a plurality of client devices are connected via a network and a file can be shared among the plurality of client devices. In accordance with the instruction, the client device moves the shared file from the local folder to the shared folder and designates the file stored in the local folder as a shared file. Client data management means for managing within the shared folder, and data transmission means for notifying the server apparatus of registration of the shared file and transmitting information identifying the shared file to the server apparatus. Information specifying the shared file is managed in the server device.

  The client data management means inquires of the server apparatus whether the same file as the specified shared file is already registered as a shared file in another client apparatus, and if it is already registered, the same file as the shared file Is deleted from the local folder, and a reference file link for referring to the shared file stored in another client device is created and managed in the shared folder. The data transmission means deletes the shared file stored in the shared folder, and when there is another client device that refers to the shared file to be deleted, the shared file to be deleted is stored in the server device. Send. When the client device has write access to the shared file stored in the shared folder, the client data management means creates a copy of the shared file in the local folder and accesses it.

  Further features of the present invention will become apparent from the best mode for carrying out the present invention and the accompanying drawings.

  According to the present invention, it becomes possible to utilize the resources of the server and client for file sharing to the maximum efficiency.

  The embodiment according to the present invention efficiently uses the storage capacity of a server device for publishing a file held by a client device as a shared file, and communicates securely so that viruses are not spread by file sharing. Is realized.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be noted that this 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.

(1) First Embodiment <System Configuration>
FIG. 1 is a diagram showing a schematic configuration of a system (file sharing system) according to the present invention. As shown in FIG. 1, the file sharing system includes a server device 1 and a plurality of clients 2, 3... (Assuming that there are only two client devices in FIG. 1 but there are an arbitrary number). Are connected via the network 4.

  The server device 1 includes a CPU 11A, a terminal device 11 including a memory 11B, an external storage device 12, and a communication port 13. The external storage device 12 includes a file (data) transfer unit 12A responsible for file communication, and a server that manages files in the server (including files that have been downloaded from the client as shown in FIGS. 6 and 12). A file management unit 12B, a file check unit 12C for confirming whether the file acquired (temporarily) from the client is a safe file, a shared file management table 12D for registering information on the shared file, and a file link And a shared folder 12E used for temporarily storing the shared file.

  The client device 2 includes a terminal device 21 including a CPU 21A and a memory 21B, an external storage device 22, and a communication port 23. The external storage device 22 acquires file (data) transfer means 22A responsible for communication of files and data, file management means 22B for managing files in the client, and information (for example, hash values) regarding the files. A means 22C, a local folder 12D for storing local files, and a shared folder 22E for storing shared files.

  Note that the client device 3 and other client devices also have the same configuration as the client device 2.

<File registration operation sequence>
FIG. 2 is a diagram illustrating a flow of instructions and data when a shared file that is not registered in the server device 1 is registered from a client device (for example, the client device 2).

  First, when the client apparatus 2 receives a shared file registration request from the user (step S201), the file management means 22B sends the registration request to the server apparatus 1 (step S202).

  The server device 1 accepts the registration request (S202) and executes, for example, user authentication and approves the shared file registration of the client device (step S203).

  Next, the file information acquisition unit 22C of the client device 2 acquires file name / hash information about a file (local file) to be registered as a shared file (step S204). Then, the client device 2 sends the hash of the file to the server device 1 in order to inquire that the file to be registered is not yet registered in the server device 1 (step S205). If the same file as that requested for registration already exists in the server device 1 (if it is registered as a shared file), a hash having the same value exists in the shared file management table 12D (see FIG. 9). The server apparatus 1 compares the sent hash with the shared file management table 12D to check whether the same file exists. When the file is not registered, the server apparatus 1 may register the hash of the file in the shared file management table 12D at this point.

  When an answer to the inquiry is returned and it is confirmed that the file is not registered in the server device 1 (step S206), the client device 2 moves the file from the local folder 22D to the shared folder 22E (step S207). Then, the file transfer means 22A of the client device 2 sends the file name, hash, and client identifier (for example, IP address) of the client device 2 to the server device 1 via the communication port 23 (step S208). .

  On the other hand, the server device 1 registers the file name, hash, and client identifier in the shared file management table 12D (step S209). Next, the server device 1 creates a file link (for example, composed of the IP address of the client device + the file path in the client device) to the file entity of the client device 2, and registers it in the shared file management table 12D. (Step S210). When the registration operation is completed, the file management unit 12B of the server device 1 notifies the completion to the client device 2 via the file transfer unit 12A and the communication port 13 (step S211).

  In the following description of a file, a client device (here, client device 2) that has completed file registration and has a file entity in a shared folder is referred to as a file entity registration client.

<Registration of registered shared files>
FIG. 3A shows a processing operation (command and data) when a file to be registered in the server apparatus 1 as a shared file by a client apparatus (for example, the client apparatus 3) is already registered by another client apparatus (client apparatus 2). FIG.

  First, when the client apparatus 3 receives a registration request for a shared file from a user (step S301), the client apparatus 3 sends the registration request to the server apparatus 1 using the file transfer unit 32A and the communication port 33 (step S302). . The server device 1 executes, for example, user authentication and approves the registration request (S302) (step S303).

  Next, the file information acquisition unit 32C acquires file name / hash information for the requested local file (step S304). Then, the client device 3 (file transfer unit 32A) sends the hash of the file to the server device 1 and inquires whether the file is registered in the server device 1 (step S305). When the response to the inquiry is returned and it can be confirmed that it is already registered in the server device 1 (step S306), the client device 3 uses the same file (other client as the file to be registered) created in the server device 1. A file link (file link to the file link: see the file link 34 in FIG. 3B) is created in the shared folder 32E for the file link to the file (existing in the shared folder of the apparatus) (step S307).

  Then, the file transfer unit 32A of the client device 3 sends the client identifier (for example, IP address) of the own device to the server device 1 (step S308). The server apparatus 1 registers the file identifier (see 904 in FIG. 9) of the file in the shared file management table 12D with the client identifier acquired in step S308, and also creates a file link (file link 15 in FIG. 3B). Are similarly registered in the table (step S309). When there are a plurality of client devices that refer to the same file, a plurality of file reference registration client identifiers 904 exist.

  When the registration of the file link is completed, the file transfer unit 12A of the server device 1 sends a completion notification to the client device 3. When the client device 3 receives the completion notification (step S310), the client device 3 deletes the file entity from the local disk (step S311). As a result, duplication of file entities in the client device can be avoided, and resource efficiency of the client device (even when considered from the whole system) can be improved. In the following description of the file, the client device such as the client device 3 in this case is referred to as a file reference registration client.

  FIG. 3B is a diagram illustrating a file link relationship in the server device 1, the file entity registration client (client device 2), and the file reference registration client (client device 3). When there is no file reference registration client for a certain file, as described above, for example, the file link 14 composed of the IP address of the file entity registration client + the file path is registered in the server device 1 (shared file management table). It is just a state. In this case, the server device 1 manages the file entity using only the file link 14. On the other hand, when the file reference registration client exists, the file link 15 that should be a shortcut for the file link 14 is registered in the shared file management table 12D. This file link 15 is a file link registered in the shared file management table 12D in the process of FIG. 3A. Further, a file link 34 as a shortcut to the file link 15 is registered in the shared folder (32E) of the file reference registration client. That is, if a direct shortcut to the file link 14 is created in the shared folder of the file reference registration client, the file reference registration client can directly access the file entity of the file entity registration client, which is preferable for security. Absent. Therefore, such a file link configuration is adopted so that the server device 1 can always access and manage the file entity 24. Note that when a client device tries to access a file or file link on the server device 1, the user of the client device specifies access to read access or write access.

<Access to shared file by file entity registration client>
FIG. 4 is a flowchart for explaining processing when a file entity registration client (for example, client apparatus 2) accesses a shared file.

  The file management unit 22B determines whether the access by the user is a read access to the shared file (step S401). If it is determined that the access is a read access to the shared file, the file management unit 22B opens the file in the read mode (step S402) and ends the process.

  On the other hand, when it is determined that the access by the user is a write access to the shared file (step S403), the file management unit 22B creates a copy of the shared file in the local folder 22D (step S404), and the copied file. Is opened in the writing mode (step S405), and the process ends. As described above, by enabling writing (editing) processing only for replication, it is possible to prevent modification of the shared file even though it is a file entity registration client. It is also possible to register a file changed by editing as a shared file again. In this case, however, it is registered in the server apparatus 1 as a shared file different from the original shared file that is the basis of editing. To be managed.

<Access to file link in server by file reference registration client>
FIG. 5 is a flowchart for explaining a process at the time of accessing a file link managed by the server device 1 by a file reference registration client (for example, the client device 3).

  When the client device 3 accesses the file link in the server device 1, the server file management unit 12B determines whether the access is a read access (step S501). If it is read access, the process proceeds to step S502. If it is not read access, the process proceeds to step S510.

  If the access is a read access, the server file management unit 12B determines whether the storage location of the file entity to be accessed is in any client device (file entity registration client) or the shared folder 12E of the server device 1 (step S502). ). The case where the file entity exists in the server apparatus 1 is a case where the file entity is moved to the server apparatus 1 in the process of FIG. If the file entity is in any of the client devices, the process proceeds to step S503. If the file entity is in the server device, the process proceeds to step S507.

  If the file to be read exists in the file entity registration client, the server apparatus 1 acquires the target file from the file entity registration client (step S503). Then, the server file management unit 12B of the server device 1 confirms the safety of the acquired file (for example, whether it is infected with a virus) (step S504), and if it can be confirmed, the file transfer unit 12A and the communication port 13 Then, the entity of the target file is transferred to the requested file reference registration client. Then, the file reference registration client (client device 3) opens the file in the read mode (step S506). If the safety of the file cannot be confirmed, the server file management unit 12B stops the process (step S505).

  On the other hand, when the storage location of the file entity is in the server device 1 (step S502), the server file management unit 12B uses the file transfer unit 12A and the communication port 13 to identify the target file entity as a file reference registration client (client). The file management means 32B of the client device 3 stores the received file in the shared folder 32E (step S507). Then, the client device 3 transmits the file name, hash, and client identifier to the server device 1. Then, the server file management unit 12B of the server device 1 changes the client device 3 from the file reference registration client to the file entity registration client, and registers the file link in the shared file management table 12D (step S508). The file link as the file reference registration client registered so far is deleted from the shared file management table 12D. Further, the client device 3 opens the acquired file in the read mode and uses it for the user (step S509).

  If it is determined in step S501 that the current access is not a read access, the process proceeds to step S510. Here, it is determined whether or not the access is a write access (step S510). If it is a write access, the process proceeds to step S511. If it is not a write access (for example, in the case of a delete instruction), the process ends.

  When the access is a write access, the server file management unit 12B determines whether the storage location of the file entity is any client, that is, whether in the shared folder in the file entity registration client or in the shared folder 12E of the server device 1 ( Step S511).

  When the storage location of the file entity is in the server device 1 (step S511), the server file management unit 12B uses the file transfer unit 12A and the communication port 13 to store the target file entity as a file reference registration client (client device 3). The file management unit 32B of the client device 3 stores the received file in the shared folder 32E (step S512). Then, the client device 3 transmits the file name, hash, and client identifier to the server device 1. Then, the server file management unit 12B of the server device 1 changes the client device 3 from the file reference registration client to the file entity registration client, and registers the file link in the shared file management table 12D (step S513). The file link as the file reference registration client registered so far is deleted from the shared file management table 12D.

  On the other hand, when the file to be read is in the file entity registration client, the server apparatus 1 acquires the target file from the file entity registration client (step S514). Then, the server file management unit 12B of the server device 1 confirms the safety of the acquired file (step S515), and if it is confirmed, the requested file reference registration client via the file transfer unit 12A and the communication port 13 Transfer the target file to. The file management unit 32B of the client device 3 stores the file in the shared folder 32E. If the safety of the file cannot be confirmed, the server file management unit 12B stops the process (step S505) as in the case of the read access.

  After the processing in step S513 or S515, the file management unit 32B of the client device 3 stores a copy of the file entity in the shared folder 32E in the local folder 32D (step S516). Then, the client device 3 opens the obtained copy of the file entity in the write mode and uses it for the user (step S517).

  In the case of read access to a file link in the server from a file non-registered client, in the flowchart of FIG. 5, when there is no step S507 to S509 and the file entity is in the server device 1 (step S502), The processing moves to step S506. On the other hand, in the case of write access, in the flowchart of FIG. 5, if steps S512 and S513 are not present and the file entity is in the server apparatus 1 (step S511), the process proceeds to step S516. As described above, in the case of a file non-registered client, only the access to the target file is permitted, and the change process to the file entity registered client is not executed.

  Incidentally, there is a method of sharing files directly between clients via a shared folder in each client terminal (see Patent Document 1). This method is realized by a plurality of client devices and a management server connected to the network. When a user of the client device wants to register a local file owned by the client device as a shared file, the user registers the local file in a shared folder for storing the shared file on the client device, and registers it with the management server. Send notifications. The management server returns a response to the response to the client device. According to this method, since the file is stored in the client, there is an advantage that only a small amount of storage is required on the server side.

  However, since the client PCs are directly connected without determining whether or not the connection destination is a safe PC that is not infected with a virus, there is a possibility that a virus-infected file is acquired from the connection destination PC. Moreover, since client PCs are directly connected, the anonymity of the client terminal cannot be ensured.

  Therefore, as described with reference to FIG. 5, the provision of the shared file to the client device (file reference registration client) is always executed through the server device, and the safety of the shared file is confirmed by the server device. The drawbacks in Patent Document 1 can be improved.

<Process when file entity registration client deletes file>
FIG. 6 is a diagram showing a flow of instructions and data in the file deletion process by the file entity registration client (for example, the client device 2).

  First, when the client apparatus 2 receives a request for deleting a shared file (file entity) from the user (step S601), the file management unit 22B refers to the file via the file transfer unit 22A and the communication port 23. The server apparatus 1 is inquired whether there is a registered client (step S602).

  When the server device 1 checks the shared file management table 12D and the file management unit 22B of the client device 2 obtains a reply that the file reference registration client already exists from the server device 1 (step S603), the file transfer unit 22A The file (file entity) is transferred to the server device 1 (file transfer means 12A) (step S604). If the file reference registration client does not exist in the shared file to be deleted, the entity of the file may be deleted without performing subsequent processing.

  Then, the server file management unit 12B stores the file that has been stored as a shared file in the client device 2 in the shared folder 12E, sets the file entity registration client identifier 903 to NULL (step S605), and sets the file link Is changed from the IP address + file path of the client apparatus 2 to the file path in the server apparatus 1 (step S606). You may make it confirm the safety | security of the file acquired at this time.

  Further, the file transfer unit 12A of the server device 1 sends a completion notification to the client device 2 (step S607). When the completion notification is received, the client device 2 deletes the entity of the shared file (step S607). By doing so, it is possible to avoid a situation where the file entity registration client deletes the shared file without permission.

<Deleting file links from unregistered clients>
FIG. 7 is a diagram showing a file link deletion command and data flow registered in the server device 1 by a file non-registered client.

  First, when the client apparatus receives a request to delete a file link of a shared file from a user (step S701), the client apparatus transmits the file (file link) deletion request to the server apparatus 1 using the file transfer unit and the communication port. (Step S702). The server file management unit 12B of the server device 1 confirms that the client device that issued the deletion request is a file non-registered client (step S703), and sends a stop command to the client device that issued the deletion request (step S703). S704). Upon receiving the cancel command, the client device notifies the user of the cancel (notifies by screen display or voice) and ends the process (step S705).

<File link deletion processing by file reference registration client>
FIG. 8 is a diagram showing a command and data flow for deleting a file link in the server device 1 by a file reference registration client (for example, the client device 3).

  First, when the client apparatus 3 receives a file link deletion request for a shared file from a user (step S801), the client apparatus 3 sends the file link deletion request to the server apparatus 1 using the file transfer unit 32A and the communication port 33. (Step S802).

  The server file management unit 12B of the server device 1 confirms that the client device 3 is a file reference registration client (step S803). When the confirmation is obtained, the server file management unit 12B removes the client identifier from the file reference registration client identifier 904 in the shared file management table 12D (step S804). If the file link for the file reference registration client in the server device 1 is only linked to the client device 3, the file link may be deleted or for a new file reference registration client. You can leave it.

  In addition, the server file management unit 12B sends a deletion completion notification to the client device 3 via the file transfer unit 12A and the communication port (step S805). The client device 3 that has received the completion notification deletes the file link in the shared folder 32E using the file management unit 32B, and ends the process (step S806).

<Shared file management table>
FIG. 9 shows an example of the shared file management table 12D. The shared file management table 12D identifies a file name 901, a hash value 902 for storing a fixed-length pseudo-random number calculated from a hash function shared by the file entity and the client device, and a file entity registration client. File entity registration client identifier 903, a client identifier 904 for identifying a file reference registration client, and a file link 905.

  As shown in FIG. 9, the file entity registration client identifier and the file reference registration client identifier store values that uniquely identify the client device, such as an IP address. A plurality of client identifiers may be registered in the file reference registration client identifier. Only one file link is registered even when a plurality of file reference registration clients are registered.

(2) Second Embodiment Hereinafter, differences of the second embodiment of the present invention from the first embodiment will be described in detail with reference to the drawings. In the first embodiment, it is assumed that all client devices are activated. However, in the second embodiment, a case where a certain client device shifts from an activated state to a stopped state (power OFF). This is an assumed process.

  1 (system configuration), FIG. 2 (command and data flow when registering a shared file not registered in the server apparatus 1 from the client apparatus 2), and FIG. 3 (shared file registered in the server apparatus 1). Instruction and data flow when registering from the client device 3), FIG. 4 (flow chart showing the flow of processing when the file entity registration client accesses the shared file), FIG. 6 (file deletion by the file entity registration client) Command and data flow), FIG. 7 (command and data flow for deleting file links in the server by a file non-registered client), FIG. 8 (command and data flow for deleting file links in the server by a file reference registration client), and FIG. 9 (configuration of the shared file management table 12D) is the same as that of the first embodiment. It is.

<File entity registration client stop processing>
FIG. 10 is a flowchart showing the flow of the client apparatus stop process. More specifically, this is processing when the file entity registration client stops due to power-off or the like. When a client having a shared file entity turns off the power, other clients referring to the file cannot refer to the file thereafter. FIG. 10 shows a process for avoiding such a situation.

  In FIG. 10, first, when there is a stop command in the file entity registration client (for example, client device 2) (step S1001), the file transfer means 22A transfers a copy of the file entity held to the server device 1 (step S1002). ). Then, the server file management unit 12B of the server device 1 changes the link destination of the file link of the file entity to the copy stored in the server device 1 (step S1003), and then the client device 2 stops. It becomes possible (step S1004).

<Access to file link in server by file reference registration client>
FIG. 11 is a flowchart showing a processing flow when a file reference registration client (for example, the client device 3) accesses a file link.

  When the client device 3 accesses the file link in the server device 1, the server file management unit 12B determines whether the access is a read access (step S1101). In the case of read access, the process proceeds to step S1102, and in the case of not read access, the process proceeds to step S1111.

  If the access is a read access, the server file management unit 12B determines whether the storage location of the file entity to be accessed is in any client device (file entity registration client) or in the shared folder 12E of the server device 1 (step S1102). ). The case where the file entity exists in the server device 1 is when the file entity is deleted by the file entity registration client (FIG. 6) or when the file entity registration client is stopped due to power OFF or the like (FIG. 10). This is a case where the file entity is moved to the server device 1. If the file entity is in any client device, the process proceeds to step S1103. If the file entity is in the server device, the process proceeds to step S1106.

  When the file to be read is in the file entity registration client, the server apparatus 1 acquires the target file from the file entity registration client (step S1103). Then, the server file management unit 12B of the server device 1 confirms the safety of the acquired file (for example, whether it is infected with a virus, etc.) (step S1104), and if it can be confirmed, the file transfer unit 12A and the communication port 13 Then, the target file is transferred to the requested file reference registration client. Then, the file reference registration client (client device 3) opens the file in the read mode (step S1107). If the safety of the file cannot be confirmed, the server file management unit 12B stops the process (step S1105).

  On the other hand, if the storage location of the file entity is in the server device 1 (step S1102), the server file management unit 12B checks the shared file management table 12D, and the file entity registration client identifier 903 corresponding to the file entity is NULL. Whether or not (step S1106). That is, whether the target file entity is in the shared folder 12E of the server device 1 is whether the file entity is deleted and stored in the server device 1 by the file entity registration client, or the file entity registration client stops and the server It is checked whether it is stored in the device 1. If the file entity exists in the server apparatus 1 because the file entity registration client has stopped, the process proceeds to step S1107. In this case, the file reference registration client (client device 3) is not changed to the file entity registration client. This is because the same file still exists in the stopped file entity registration client.

  If the file entity exists in the server apparatus 1 because the file entity is deleted by the file entity registration client in step S1106, the server file management unit 12B uses the file transfer unit 12A and the communication port 13 to execute the target file. The entity is transmitted to the file reference registration client (client device 3), and the file management means 32B of the client device 3 stores the received file in the shared folder 32E (step S1108). Then, the client device 3 transmits the file name, hash, and client identifier to the server device 1. Then, the server file management unit 12B of the server device 1 changes the client device 3 from the file reference registration client to the file entity registration client, and registers the file link in the shared file management table 12D (step S1109). The file link as the file reference registration client registered so far is deleted from the shared file management table 12D. Further, the client device 3 opens the acquired file in the read mode and uses it for the user (step S1110).

  If it is determined in step S1101 that the current access is not a read access, the process proceeds to step S1111. Here, it is determined whether or not the access is a write access (step S1111). If it is a write access, the process proceeds to step S1112. If it is not a write access (for example, a delete instruction), the process ends.

  When the access is a write access, the server file management unit 12B determines whether the storage location of the file entity is any client, that is, the shared folder in the file entity registration client or the shared folder 12E of the server device 1 (step) S1112).

  When the storage location of the file entity is in the server device 1 (step S1113), the server file management unit 12B checks the shared file management table 12D and determines whether the file entity registration client identifier 903 corresponding to the file entity is NULL. Is determined (step S1113). That is, whether the target file entity is in the shared folder 12E of the server device 1 is whether the file entity is deleted and stored in the server device 1 by the file entity registration client, or the file entity registration client stops and the server It is checked whether it is stored in the device 1. If the file entity is in the server apparatus 1 because the file entity registration client has stopped, the process moves to step S1118. In this case, the file reference registration client (client device 3) is not changed to the file entity registration client. This is because the same file still exists in the stopped file entity registration client.

  If it is determined in step S1113 that the file entity is in the server apparatus 1 because the file entity has been deleted by the file entity registration client, the server file management unit 12B uses the file transfer unit 12A and the communication port 13. Then, the target file entity is transmitted to the file reference registration client (client device 3), and the file management means 32B of the client device 3 stores the received file in the shared folder 32E (step S1114). Then, the client device 3 transmits the file name, hash, and client identifier to the server device 1. Then, the server file management unit 12B of the server device 1 changes the client device 3 from the file reference registration client to the file entity registration client, and registers the file link in the shared file management table 12D (step S1115). The file link as the file reference registration client registered so far is deleted from the shared file management table 12D.

  On the other hand, when the file to be read is in the file entity registration client, the server apparatus 1 acquires the target file from the file entity registration client (step S1116). Then, the server file management unit 12B of the server device 1 confirms the safety of the acquired file (step S1117), and if it is confirmed, the requested file reference registration client via the file transfer unit 12A and the communication port 13 Transfer the target file to. The file management unit 32B of the client device 3 stores the file in the shared folder 32E. If the safety of the file cannot be confirmed, the server file management unit 12B stops the process (step S1105) as in the case of read access.

  After the processing in step S1115 or S1117, the file management unit 32B of the client device 3 stores a copy of the file entity in the shared folder 32E in the local folder 32D (step S1118). Then, the client device 3 opens the obtained copy of the file entity in the write mode and uses it for the user (step S1119).

  In the case of read access from the file non-registered client to the file link in the server, the same processing as in the first embodiment is performed. In other words, as described in the first embodiment, in the flowchart of FIG. 5, when steps S507 to S509 are not present and the file entity is in the server apparatus 1 (step S502), the process proceeds to step S506. . On the other hand, in the case of write access, in the flowchart of FIG. 5, when steps S5512 and S513 are not present and the file entity is in the server apparatus 1 (step S511), the process proceeds to step S516. As described above, in the case of a file non-registered client, only the access to the target file is permitted, and the change process to the file entity registered client is not executed.

<Client startup processing>
FIG. 12 is a flowchart for explaining processing in the system when a client device registered as a file entity registration client is activated.

  When a certain client device is activated (step S1201), the client device is notified of the activation (step S1202).

  Then, the server file management unit 12B in the server device 1 checks whether or not a file having a matching file entity registration client identifier is stored in the shared folder 12E (step S1203). If the file exists, the process proceeds to step S1204. If the file does not exist, the process ends.

  If the file exists, the server file management unit 12B changes the link destination of the file to a file entity in the client device (step S1204), deletes the file entity from the shared folder 12E (step S1205), and performs processing Finish.

  By doing so, it is not necessary for the server apparatus 1 to constantly store and manage the file entity, and it is only necessary to manage the file entity, so that the resources in the server apparatus can be efficiently used. It becomes like this.

(3) Third Embodiment Hereinafter, the third embodiment of the present invention will be described in detail with reference to the drawings with respect to differences from the first embodiment. In the third embodiment, the process of FIG. 13 is executed instead of the process of FIG. Other drawings (FIGS. 1, 3 to 9 (first embodiment), and FIGS. 10 to 12 (second embodiment)) are also applied to the third embodiment.

<File registration process>
FIG. 13 is a diagram illustrating a flow of instructions and data when a client device 2 registers a file that is not registered in the server device 1 as a file to be shared.

  When the client apparatus 2 receives a shared file registration request from the user (step S1301), the file management unit 22B sends the registration request to the server apparatus 1 using the file transfer unit 22A and the communication port 13 (step S1302). ). The server device 1 approves the registration request using, for example, user authentication (step S1303).

  Next, the file information acquisition unit 22C of the client device 2 acquires file name / hash information about the local file to be registered (step S1304). The file transfer means 22A transmits this hash to the server apparatus 1 and inquires whether or not the file has already been registered in the server apparatus 1 (step S1305).

  When the response to the inquiry is returned and it can be confirmed that the file is not registered in the server device 1 (step S1306), the file management means 22B of the client device 2 moves the file from the local folder 22D to the shared folder 22E ( Step S1307). Further, the file transfer unit 22A sends the file name relating to the file and the client identifier of the client device 2 (for example, the IP address of the client device) to the server device 1 (step S1308).

  The server device 1 registers the file name, hash, and client identifier of the file in the shared file management table 12D (step S1309). Then, the server file management unit 12B of the server device 1 creates a file link for the file (step S1310). When the registration is completed, the file transfer unit 12A notifies the registration completion to the client device 2 (step S1311).

  In the client device 2, the file management unit 22B deletes a file having the same hash value as the registered file (stored in the shared folder 22E) from the local folder 22D if it exists in the local folder 22D (step S21). S1312). By doing in this way, the efficiency of the resource in a client apparatus can also be achieved.

  In order to realize this, the hash value of each file is calculated and stored in the storage device (hard disk) 22 of the client device 2 at the time of file generation for the file stored in the local disk. May be.

(4) Summary In this embodiment, when a local file is published as a shared file by a client device, file name / hash information is acquired for the local file, and it is determined that the file has not been registered in the server device. Inquire by sending a hash. If the inquiry result is unregistered, the client device moves the file to a shared folder in the client device, sends the file name related to the file and the client identifier of the client device to the server device, and receives them. The server apparatus registers the file name, hash, and client identifier in the shared file management table, and creates a file link to the file entity in the server. In addition, when accessing a file link stored in a server from a certain client device, the server permits the access after confirming the safety of the entity. As a result, the storage usage rate of the server device for file sharing can be lowered, and unnecessary storage occupation due to duplication of files in the storage of the server device and the client device can be prevented. In addition, since the file is shared by checking the safety of the file, each client device can be protected from attacks such as viruses. Furthermore, registration, deletion, read access, and write access of the shared file can be executed by an operation method that is almost the same as the file sharing operation by the client and server.

  If the shared file is already registered in another client device, the client device creates a file link in the shared folder of the client device for the file link to the same file created in the server. At the same time, the client identifier of the client device is sent to the server device, registered in the file reference registration client identifier of the file in the shared file management table, and the file entity of the client device is deleted from the local disk. Thereby, since the number of client devices having the same file is reduced, the risk of leakage of confidential files can be reduced.

  Also, immediately before the client device stops, the copy of the shared file of the client device is transferred to the server device, and the link destination of the file link is changed to the copy stored in the server device. Then, immediately after starting the client device, it is checked whether there is a file with the same file entity registration client identifier. If there is, the link destination of the file is changed to the file entity in the client device, and the file entity is deleted from the server. To do. This eliminates the need for each client device to be always in an activated state, is economical, and ensures the anonymity of each client device.

  The present invention can also be realized by a program code of software that realizes the functions of the above-described 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 embodiments, 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, a flexible disk, CD-ROM, DVD-ROM, hard disk, optical disk, magneto-optical disk, CD-R, magnetic tape, nonvolatile memory card, ROM Etc. are 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.

  Also, by distributing the program code of the software that realizes the functions of the embodiment via a network, the program code 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 And the computer of the system or apparatus (or CPU or MPU) may read and execute the program code stored in the storage means or the storage medium when used.

It is a figure which shows the system schematic structure by this invention. FIG. 4 is a diagram illustrating a flow of instructions and data when registering a shared file not registered in the server device 1 from the client device 2. FIG. 5 is a diagram illustrating a flow of commands and data when registering a shared file already registered in the server device 1 from the client device 3. It is a figure which shows the relationship of a file link. It is a flowchart for demonstrating the process at the time of access to the said shared file by a file entity registration client. It is a flowchart for demonstrating the process at the time of access to the file link by the file reference registration client by the 1st Embodiment of this invention. It is a figure which shows the command of file deletion by a file entity registration client, and the flow of data. It is a figure which shows the command and data flow of the file link deletion in a server by a file non-registration client. It is a figure which shows the command and data flow of the file link deletion in a server by a file reference registration client. It is a figure which shows the structural example of a shared file management table. It is a flowchart which shows the flow of a client apparatus stop process. It is a flowchart for demonstrating the process at the time of access to the file link by the file reference registration client by the 2nd Embodiment of this invention. It is a flowchart for demonstrating the process at the time of client apparatus starting. It is a figure which shows the flow of an instruction | indication and data in the case of registering the unregistered shared file with the server apparatus 1 from the client apparatus 2 by the 3rd Embodiment of this invention.

Explanation of symbols

11A, 21A, 31A ... CPU
11B, 21B, 31B ... Memory 13, 23, 33 ... Communication ports 11, 21, 31 ... Terminal devices 12, 22, 32 ... External storage device 4 ... Network 12A, 22A, 32A ... File transfer means 12B ... Server file management means 12C ... File check means 12D ... Shared file management tables 12E, 22E, 32E ... Shared folders 22B, 32B ... File management means 22C, 32C ... File information acquisition means 22D, 32D ... Local folders

Claims (20)

A shared file management method for managing a shared file in a system that includes a plurality of client devices and a server device and enables sharing of files between the client devices,
One client device of the plurality of client devices designates a file held as a shared file shared with other client devices, manages the entity of the shared file,
When the shared file is specified, the server device manages an entity file link indicating a location where the shared file entity is stored, and the one client device stores the shared file entity. A shared file management method characterized by managing as an entity registration client.   When the server apparatus requests access to the shared file based on the entity file link from the other client apparatus, the server apparatus refers to the entity file link and acquires the shared file acquired from the one client apparatus The shared file management method according to claim 1, wherein the access request is provided to the other client device that has requested access. When one client device among the plurality of client devices designates a file held as the shared file and the same file has already been registered as a shared file in another client device, it is registered in the server device. Create and manage a reference file link that is a link to the file link of the shared file, delete the entity of the same file as the shared file,
The shared file management method according to claim 1, wherein the server device manages a client device that manages the reference file link as a file reference registration client.   The server device generates an auxiliary file link that becomes a link to the entity file link, the reference file link directly links to the auxiliary file link, and the file reference client directly accesses the file entity registration client to share the file. 4. The shared file management method according to claim 3, wherein the file reference registration client is managed so that the file cannot be acquired.   3. The shared file management method according to claim 2, wherein the server device confirms the safety of the shared file when acquiring the entity of the shared file from the plurality of client devices for a predetermined reason. .   When the file entity registration client deletes the entity of the shared file or when the file entity registration client stops, the server device changes the entity of the shared file to the file when the file reference registration client exists. The shared file management method according to claim 3, wherein the shared file management method is obtained from an entity registration client and changes the entity file link to a storage location in the server device.   When the file entity registration client deletes the entity of the shared file, when the file reference registration client accesses the shared file acquired by the server device, the server device transmits the sharing to the file reference registration client. The shared file management method according to claim 6, wherein the file entity is transmitted, and the file reference registration client is changed to a file entity registration client for management.   When the file entity registration client is stopped, when the file reference registration client accesses the shared file acquired by the server device, the server device transmits the entity of the shared file to the file reference registration client. 7. The shared file management method according to claim 6, wherein the file reference registration client is managed as the file reference registration client without changing to the file entity registration client.   When the file entity registration client is started from a stopped state, the server device deletes the acquired shared file entity from the server device, and returns the entity file link to the storage location in the file entity registration client. The shared file management method according to claim 6, wherein: A shared file management system that includes a plurality of client devices and a server device, and enables sharing of files between the client devices,
One client device of the plurality of client devices designates a file held as a shared file shared with other client devices, manages the entity of the shared file,
When the shared file is specified, the server device manages an entity file link indicating a location where the shared file entity is stored, and the one client device stores the shared file entity. A shared file management system characterized by being managed as an entity registration client. A server device that manages information of the plurality of client devices and the shared file so as to enable sharing of files among the plurality of client devices,
Server data management means for managing information on a file entity registration client, which is a client device that stores the entity of the shared file, and an entity file link that indicates a storage location of the entity of the shared file apparatus.   The server data management means further includes information on a file reference registration client that is a client device other than the file entity registration client and is accessible to the shared file, and a link to the entity file link The server apparatus according to claim 11, wherein the reference file link is managed.   When the file entity registration client deletes the entity of the shared file, or when the file entity registration client is stopped, or when the file reference registration client exists, the server data management means determines the entity of the shared file. The server apparatus according to claim 12, wherein the server apparatus is obtained from the file entity registration client and changes the entity file link to a storage location in the server apparatus. A client device that forms part of a system in which a server device and a plurality of client devices are connected via a network and a file can be shared among the plurality of client devices,
According to the instruction, a designation means for designating a file stored in the local folder as a shared file,
Client data management means for moving the shared file from the local folder to the shared folder and managing the shared file in the shared folder so that the plurality of client devices can access the shared file;
Notifying the server device of registration of the shared file, and data transmission means for transmitting information identifying the shared file to the server device,
A client device characterized in that information specifying the shared file is managed in a server device.   The client data management means inquires of the server device whether the same file as the specified shared file is already registered as a shared file in another client device, and if the file is already registered, the shared file The same file is deleted from the local folder, and a reference file link for referring to the shared file stored in the other client device is created and managed in the shared folder. 14. The client device according to 14.   The data transmission means deletes the shared file stored in the shared folder, and when there is another client device that refers to the shared file to be deleted, the shared file to be deleted The client device according to claim 14, wherein the client device is transmitted to the server device.   15. The write data access to the shared file stored in the shared folder, the client data management means creates a copy of the shared file in the local folder and accesses the file. The client device described.   A program for causing a plurality of computers to execute the shared file management method according to claim 1 and causing each computer to function as the server device and the flyant device.   The program for functioning a computer as a server apparatus of Claim 11. The program for functioning a computer as a client apparatus of Claim 14.

Images