JP2005292868A - File sharing control system, sharing control server, and sharing control program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To back up a file without complicated operation by a user and to share the file among a plurality of computers.
A control server refers to a file basic attribute information sent from a client PC and refers to a real file information table and a real file generation information table in a DB to determine download or upload conditions related to the file. The determination result is returned to the client PC 12. The local condition determination unit 32 of the client PC 12 requests the control server 10 to download or upload a file according to the determination result.
[Selection] Figure 1

Description

  The present invention relates to a system for controlling file backup and sharing, a sharing control server, and a program.

Due to the recent improvement in performance of computer equipment, personal computers are becoming smaller and personal computers used in offices are becoming smaller. In addition, due to restrictions on office space, the personal computer used is shifting from a desktop type to a notebook type. Furthermore, as a matter of course, various files (document files, data files of spreadsheet software, etc.) that are network-connected by a local area network (LAN) and that are work products are stored in a file server. It is becoming common.
JP 2003-296175 A

However, when notebook-type personal computers have come to be used, the following situations have frequently occurred.
(1) When working at a location in the office where LAN connection is not possible, a notebook personal computer (hereinafter also referred to as “notebook PC”) is moved away from the LAN to work.
(2) Not only stay in the office, but also take a notebook PC at the place of work.

  When using such a method of use, there are frequent cases where the following work method is used.

Type 1
Various files used for business are temporarily copied from the file server to the local disk of the notebook PC.
When finished, write back from local disk to file server

Type 2
A newly created file is created on the local disk and written to the file server after the work is completed.

However, in such a usage method, when the following trouble occurs, there is a possibility that a file required for business is lost forever.
(1) When the notebook PC being used fails (2) When a necessary file is deleted due to an erroneous operation (3) When the notebook PC is lost (stolen) The background described above mainly occurs as follows. It is said that there is such a cause.
(1) Copying to the file server depends on human manual work.
(2) There is no good backup method for local disk of notebook PC.

  Moreover, due to the problem of cost and the characteristics of notebook PCs that can be operated without selecting a place of use, there is a problem that it is practically impossible to attach a backup device to each notebook PC.

  As a result, once a failure has occurred in a notebook PC, the probability of a fatal situation in which a file cannot be recovered is increasing. And with the improvement of computer performance, larger local disks have come to be mounted as standard, and the degree of damage impact has become increasingly serious.

  Also, in system design and the like, it has become common to implement one project with multiple people. In this case, work on a personal computer for the part in charge, and store various files that are the result of the work on the server so that others can view it and, in some cases, update it. .

  For example, Patent Document 1 discloses a collaborative work support system in which process definition information represents a processing path based on a list of group names, and when a group finishes processing, the next group can start processing. ing. However, it is difficult to use the above-described system when the entire work is progressed by each worker proceeding freely. In addition, a procedure of creating process definition information in advance is also necessary.

  An object of the present invention is to provide a system capable of backing up files without complicated operations by a user and sharing files among a plurality of computers without complicated operations.

  An object of the present invention is to provide a directory path in which a file owned by itself is stored, an owned directory information table having a record including a directory name, and a local file management means for managing upload and download of the file via a network. A record including the node name of the file owner, the name of the directory storing the file of the client computer, and the update time, generated based on the record of the possessed directory information table sent via the network Owner path information table, file owner's node name, file name, real file information table having a record including the directory path where the file is stored, file name, File time stamp, real file generation information table having a record including information indicating the contents of the file, file name, directory path, file time stamp, and file name sent from the local management means via the network Based on the file basic attribute information including information indicating the contents, the download or upload condition regarding the file is determined with reference to the actual file information table and the actual file generation information table, and the determination result is transmitted to the client computer. In accordance with a request from the center condition determining means and the client computer, the uploaded file is stored in a predetermined directory path in the storage device, and the file stored in the predetermined directory path is stored. And a control server having a center file management means for downloading a file to the client computer, and the client computer requests the control server to download or upload the file according to the determination result. This is achieved by a file sharing control system characterized by having a judging means.

  According to the present invention, the center condition determining means transmits the determination result to the client computer based on the file time stamp or the match of the file contents, and the local condition determining means of the client computer downloads the file or Determine whether you want to upload. Accordingly, it is possible to realize backup of a file (uploading a file to the control server) and acquisition of a backed-up file (downloading of a file from the control server) without complicated operations by the user.

  In a preferred embodiment, the client computer further includes a usage directory information table having a record including a node name and a directory name of another client computer that owns a file to be used, and the local file management means includes a usage directory. Based on the information table, the file basic information including the file name, directory path, file time stamp of the file to be used, and information indicating the contents of the file is transmitted, and the center condition determining means of the control server performs local management. Based on the file basic attribute information including information indicating the file name, directory path, file time stamp, and file content sent from the means via the network, the actual file information table, and Refer to the file generation information table to determine download or upload conditions for the file, and send a determination result. The local condition determination means of the client computer downloads or uploads the file according to the determination result. , Request to the control server.

  According to the present embodiment, in the client computer, if the information of what is desired to be used in the files owned by other client computers is prepared as a record in the usage directory information table, the center condition determining means and the center condition determining means Thus, whether to download the file of the other client computer is determined. Thereby, users can share files owned by other client computers.

  In another embodiment, the client computer further includes a use directory information table having a record including a node name and a directory name of another client computer that owns the file to be used. Based on the directory information table, the file basic information including the file name of the file to be used, the directory path, the file time stamp, and the information indicating the contents of the file is transmitted. Based on the file basic attribute information including information indicating the file name, directory path, file time stamp, and file content sent from the management means via the network, the file can be downloaded or downloaded. Determine the conditions of the upload, and transmits the determination result, the local condition determination means of the client computer, in accordance with the determination result, the download or upload of the file, requests the client computer that owns the file.

  In a more preferred embodiment, the record of the possessed directory table includes a disclosure flag indicating whether or not the file can be disclosed, and disclosure type information indicating whether or not the file can be updated when the disclosure is possible, and the owner path information. The table includes the public flag and the public type information, and the center condition determining unit refers to the public flag and the public type information in the owner path information table to determine a download or upload condition regarding the file. .

  In a preferred embodiment, the information indicating the contents of the file is a hash value of the file, and the center condition determining means determines the match of the contents of the file by comparing the hash values.

  Another object of the present invention is to create a network that is generated by the client computer based on an owned directory information table having a record including a directory path and a directory name in which the client computer has a file owned by the client computer. The client computer name, the directory name that stores the file of the client computer, and the owner path information table that stores the record including the update time, the node name of the file owner, the file name, and the file A real file information table having a record including the directory path where the file is stored, a file name, a file time stamp, a real file generation information table having a record including information indicating the contents of the file, and a network. Based on the file basic attribute information including information indicating the file name, directory path, file time stamp, and file contents sent via the work, the real file information table and the real file generation information table are referred to. Determining a download or upload condition relating to the file, and a center condition determining means for transmitting the determination result to the client computer, and in accordance with a request from the client computer, the uploaded file is stored in the storage device, Center file management means for storing the file stored in the predetermined directory path and downloading the file stored in the predetermined directory path to the client computer is provided. In response to a request to download or upload of the file in accordance with, the center file management means also achieved by the file sharing control server, characterized by downloading or uploading the file.

  In a preferred embodiment, the center condition determining means has a client computer based on a directory information table having a record including a node name and a directory name of another client computer that owns a file to be used. The actual file information table based on the basic file information including information indicating the file name, directory path, file time stamp, and file content of the file to be used, generated and transmitted over the network. Then, referring to the real file generation information table, the download or upload condition regarding the file is determined, and the determination result is transmitted to the client computer.

  Another object of the present invention is to create a network that is generated by the client computer based on an owned directory information table having a record including a directory path and a directory name in which the client computer has a file owned by the client computer. The client computer name, the directory name that stores the file of the client computer, and the owner path information table that stores the record including the update time, and the node name and file name of the file owner A real file information table having a record including a directory path in which the file is stored, and a real file generation information table having a record including information indicating a file name, a file time stamp, and the contents of the file; A computer-readable program comprising the file basic attribute information including information indicating a file name, a directory path, a file time stamp, and a file content sent via the network. Based on the actual file information table and the actual file generation information table, the download condition or the upload condition relating to the file is determined, and the determination result is transmitted to the client computer, and the client computer In response to a request from the user, the uploaded file is stored in a predetermined directory path in the storage device, and the file stored in the predetermined directory path is downloaded to the client computer. Center file management means for downloading, in response to a request for downloading or uploading the file according to the determination result from a client computer, the center file management means for downloading or uploading the file, This is also achieved by a file sharing control program.

  In a preferred embodiment, when the computer is caused to function as a center condition determining means, the client computer has a record including a record including a node name and a directory name of another client computer that owns a file that the client computer wants to use. File basic information including information indicating the file name, directory path, file time stamp, and file content of the file to be used, generated by the client computer and transmitted via the network Based on the actual file information table and the actual file generation information table, the download or upload condition relating to the file is determined, and the determination result is transmitted to the client computer. So that, the operating the computer.

  ADVANTAGE OF THE INVENTION According to this invention, it becomes possible to provide the system which can back up a file without complicated operation by a user, and can share a file between several computers without complicated operation.

  Embodiments of the present invention will be described below with reference to the accompanying drawings. FIG. 1 is a block diagram showing a configuration of an entire system including a file backup / sharing control server (hereinafter referred to as “control server” or “center controller” in some cases) according to an embodiment of the present invention. As shown in FIG. 1, a file backup / sharing control server 10 and a plurality of client / personal computers (hereinafter referred to as “client PCs” or “nodes” in some cases) 12-1, 12-2,. 12-n can be connected via the network 14. The network 14 may be connected to a mail server 16 for notifying the client PC about file backup and file sharing processing in the control server 10. In this embodiment, TCP / IP is used as the network, but the present invention is not limited to this, and any wired or wireless network can be used.

  As shown in FIG. 2A, the control server 10 has a database 20 including an online node management table 200, an owner path information table 201, an actual file information table 202, and an actual file generation information table 203, which will be described later. Have. In addition, the control server 10 determines a condition for the file download or upload based on the content of the message transmitted from the client PC 12 and the content of the table (center condition determination unit). 22 and a file management unit (center file management unit) 24 for managing file read / write and transmission / reception. The functions of the condition determination unit 22 and the file management unit 24 are realized by an agent program (hereinafter simply referred to as “agent”) stored in a storage device such as a memory of the control server 10.

  As shown in FIG. 2B, the storage device 30 of each client PC 12 stores a node basic information table 211, an owned directory information table 212, and a usage directory information table 213. Each client PC 12 includes a condition determination unit (local condition determination unit) 32 that determines conditions regarding file download or upload, and a file management unit (local file management unit) 34 that uploads or downloads files. Yes. An agent (not shown) is stored in the storage device 32, and the functions of the condition determination unit 32 and the file management unit 34 are realized by the agent.

  FIG. 3 is a diagram illustrating a data configuration of the node basic information table 211. As shown in FIG. 3, the node basic information table 211 includes, as items, “own node name”, “node identification key”, “center controller IP address”, “center controller listen port number”, “E-Mail address”. And “Directory Sync Interval”.

  FIG. 4 is a diagram showing a data configuration of the owned directory information table 212. As shown in FIG. As shown in FIG. 4, the records of the owned directory information table 212 include, as items, “owned directory path”, “owned directory name”, “maximum number of saved generations”, “deleted file retention period”, “public” “Flag”, “public password”, “public type”, “notification mail receipt flag”, “previous synchronization time (node side)” and “previous synchronization time (center side)”. The record of the owned directory information table is information for specifying a group of files owned by the client PC (for example, the client PC 12-1). For example, a file group belonging to a directory specified by “owned directory Path” and “owned directory name” can be specified. When the “public flag” is “ON”, the file group can be shared with other client PCs (for example, the client PC 12-2).

  FIG. 5 is a diagram illustrating a data configuration of the usage directory information table 213. As shown in FIG. 5, the records of the usage directory information table 213 include items such as “directory owner node name”, “directory name”, “public password”, “file storage destination reference directory Path”, “ "Notification mail receipt flag", "change result reflection flag", "previous synchronization time (node side)" and "previous synchronization time (center side)". The “directory owner node name” and “directory name” specify a file group of another client PC (for example, client PC 12-2) that the client PC (for example, client PC 12-1) desires to share the file. The Sharing of the file group is permitted by the “public password”. Also, the client when the client PC (for example, client PC 12-1) downloads a file group desired to be shared from another client PC (for example, client PC 12-2) by the “file storage destination reference directory path”. A storage location in the PC (for example, the client PC 12-1) is specified.

  FIG. 6A is a diagram illustrating a data configuration of the online node management table 200. As shown in FIG. 6A, the record of the online node management table 200 includes items such as “node name”, “node identification code”, “node IP address”, “node port number”, “node state”, Includes "Online start date and time", "Offline (offline) date and time", and "Node administrator address". Based on the value of the item included in this record, the control server 10 can specify the client PC 12 connected via the network 14.

  FIG. 6B is a diagram illustrating a data configuration of the owner path information table 201. As shown in FIG. 6B, the record of the owner path information table includes, as items, “node name”, “owned directory name”, “maximum number of saved generations”, “deleted file retention period”, “public flag”. ”,“ Public password ”,“ Public type ”,“ Notification mail receipt flag ”,“ Sync flag in path ”,“ Updater node name ”,“ Last upload (upload) time ”, and“ Delete flag ”.

  This record is newly created when a record in the owned directory information table of the client PC 12 is registered in the control server 10. Therefore, the “node name” corresponds to the node name of the client PC, and “owned directory name”, “maximum number of preservation generations”, “deleted file retention period”, “public” in the owner path information table record. The values of “flag”, “public password”, “public type”, and “notification mail receipt flag” are stored as values of corresponding items in the record of owned directory information.

  FIG. 7A shows the data structure of the real file information table 202. As shown in FIG. 7A, the records of the real file information table 202 include items such as “node name”, “owned directory name”, “relative path (path)”, “real file name”, “server file”. “Name” and “delete flag”. “Node name” corresponds to the node name of the client PC 12, and “owned directory name” corresponds to “owned directory name” in the record of the owned directory information table. “Relative Path” indicates a relative path from the owning directory when the file is stored in a subdirectory in the owning directory in the client PC 12. The “server file name” is a file name when the control server 10 stores the file. A file in the client PC 12 can be specified by the record of the actual file information table 202.

  FIG. 7B shows the data structure of the real file generation information table 203. As shown in FIG. 7B, the record of the real file generation information table 203 includes items such as “server file name”, “registration date / time”, “registration directory”, “registration node name”, and “storage file size”. , “File size”, “hash value”, “compressed hash value”, and “time stamp”. “Registration date and time” corresponds to the date and time when the file was stored in the storage device of the control server 10. The “registration directory” corresponds to a path for storing a file in the control server 10. The control server 10 stores a storage file information table (not shown) in the storage device. The record of the stored file information table includes a “file backup reference path (path)” corresponding to a directory path in the storage device in which the file uploaded from the client PC 12 is saved by the control server 10. The registration directory matches the value of any record in the stored file information table.

  First, a procedure for uploading a file owned by the client PC 12-1 or downloading a file from the control server 10 from the client PC (considering the client PC 12-1 as an example) will be described. In the present embodiment, by uploading the file of the client PC 12-1 itself to the control server 10, it can be backed up to the control server 10. When the client PC 12-1 downloads the backed up file, the backed up file can be acquired.

  When sharing the file of the client PC 12-1, the client PC 12-1 uploads the file to the control server 10, and another client PC that uses the file (consider the client PC 12-2 as an example) A file is downloaded from the control server 10. Also, certain work is performed in the other client PC 12-2, and the updated file is uploaded to the control server 10, and then the file is downloaded so that the update is reflected in the client PC 12-1. In some cases.

  FIG. 8 is a table showing a mode of a result of comparing files between the client PC (node) and the control server (center controller). Hereinafter, with reference to FIG. 8, the process according to the mode of the comparison result will be outlined.

  The owner refers to a person who initially uploads his / her file to the control server 10, and the user refers to a person who initially downloads and uses a file uploaded by another person.

Processing follows the basic principles described below.
(1) If a node that may update a file in the directory has a newer file than the center controller, upload the file to the center controller.
(2) If a node that may update a file in the directory has a file older than the center controller, download the file from the center controller and overwrite it. However, it is checked whether the file in the node exists as a history in the center center controller. If it is in the history, the file is downloaded from the center controller and overwritten. On the other hand, if it is not in the history, the file name of the node is changed (name with an additional extension “.dif” added to the original file name).

[Case 1: Owner, private, file match]
The owning directory is not disclosed. That is, the “public flag” is “OFF” in the record of owned directory information regarding the file. Also, the node file and the center controller file match.
In this case, no action occurs.

[Case 2: Owner, private, node file is old version]
The owned directory is not disclosed, and the node file and the center controller file are old in the node. In this case, the center controller file is downloaded to the node.

  Although this normal case does not occur, the change is reflected in the center controller when the file is manually replaced with an old file on the node, or when the owning directory is switched from public / updateable to private. This may occur, for example, when a modified file has been previously uploaded on the directory user's client PC.

[Case 3: Owner, private, node file is new version]
If the owned directory is not disclosed and the node file is new, the node PC file is uploaded to the center controller. The uploaded center controller stores the uploaded file as a new generation file.

[Case 4: Owner, private, no file on node]
If the owning directory is not disclosed and there is no file in the node, the center controller will notify the owner controller of the owner path information when the file synchronization (Sync) processing end notification is received from the node. Set the “delete flag” to “ON” in the record corresponding to the file in the table.

[Case 5: Owner, private, no file in center controller]
If the owned directory is not disclosed and there is no file in the center controller, the file is uploaded from the node to the center controller. The received center controller stores the file as a new file in the storage device.

[Case 6: Owner, release, non-updatable, file match]
The owning directory is public. On the other hand, updating by the user is not possible, that is, in the owner path information table, “public type” is “not updatable” in the record for the file. Also, the node file and the center controller file match. In such a case, no action occurs.

[Case 7: Owner, release, non-updatable, node file is old version]
The owned directory is open to the public and cannot be updated by the user. The node file and the center controller file are old in the node. In this case, it is confirmed whether the file updater of the center controller is the same as the node owner. Here, the updater of the file of the center controller is specified by the “node name” in the message transmitted from the node to the center controller. If both are the same, the node downloads the file of the center controller and overwrites it. If both are different, the file name of the node is changed and then the file is downloaded from the center controller.

[Case 8: Owner, release, update not possible, node file is new version]
The owned directory is open to the public and cannot be updated by the user. The node file and the center controller file are new to the node. In this case, the node file is uploaded to the center controller. The center controller to which the file is uploaded stores the uploaded file as a new generation file.

[Case 9: Owner, release, non-updatable, no file on node]
The owning directory is open to the public and cannot be updated by the user. Also, no file exists on the node. In this case, at the timing when the file synchronization (Sync) processing end notification comes from the node to the center controller, the center controller sets the “delete flag” in the record corresponding to the file in the owner path information table. "ON".

[Case 10: Owner, release, non-updatable, no file in center controller]
The owning directory is open to the public and cannot be updated by the user. Further, with the center controller, no file exists in the center controller. In this case, the file is uploaded from the node to the center controller. The received center controller stores the file as a new file in the storage device.

[Case 11: Owner, release, update possible, file match]
The owned directory is made public and can be updated by the user. That is, in the owner path information table, the “public type” is “public” in the record for the file. Also, the node file and the center controller file match. In such a case, no action occurs.

[Case 12: Owner, release, update possible, node file is old version]
The owning directory is open to the public and can be updated by the user. The node file and the center controller file are old in the node. In this case, it is confirmed whether the file updater of the center controller is the same as the node owner. If both are the same, the node downloads the file of the center controller and overwrites it. If both are different, the file name of the node is changed and then the file is downloaded from the center controller.

[Case 13: Owner, release, update possible, node file is new version]
The owning directory is open to the public and can be updated by the user. Also, the node file and the center controller file are new to the node. In this case, the node file is uploaded to the center controller. The center controller to which the file is uploaded stores the uploaded file as a new generation file.

[Case 14: Owner, public, updateable, no file on node]
The owning directory is open to the public and can be updated by the user. Also, no file exists on the node. In this case, at the timing when the file synchronization (Sync) processing end notification comes from the node to the center controller, the center controller sets the “delete flag” in the record corresponding to the file in the owner path information table. "ON".

[Case 15: Owner, release, update possible, no file in center controller]
The owning directory is open to the public and can be updated by the user. The file does not exist in the center controller. In this case, the file is uploaded from the node to the center controller. The received center controller stores the file as a new file in the storage device.

[Case 16: User, undisclosed]
The owning directory is not disclosed. Therefore, access is denied from the center controller at the start of file synchronization processing from the user.

[Case 17: User, release, non-updatable, file match]
The owning directory is open to the public and cannot be updated by the user. Further, the file of the user node (hereinafter referred to as “user node”) and the file of the center controller match. In this case, no action occurs.

[Case 18: User, release, update not possible, user node file is old version]
The owning directory is open to the public and cannot be updated by the user. The user node file and the center controller file are old in the user node. Here, when the file of the user node exists in the history of the center controller, the user node downloads the file from the center controller and overwrites it. On the other hand, if the user node file does not exist in the history of the center controller, the user node changes the file name and then downloads the file from the center controller. Note that a file exists in the history of the center controller means that a record relating to the file exists in the actual file generation information table.

[Case 19: User, release, non-updatable, user node file is new version]
The owning directory is open to the public and cannot be updated by the user. Also, the user node file and the center controller file are new to the user node. In this case, no update occurs because the file cannot be updated.

[Case 20: User, public, non-updatable, no file on user node]
The owning directory is open to the public and cannot be updated by the user. In addition, no file exists in the user node. In this case, the user node downloads a file from the center controller.

[Case 21: User, public, non-updatable, no file in center controller]
The owning directory is open to the public and cannot be updated by the user. The file does not exist in the center controller. In this case as well, no action occurs because the file cannot be updated.

[Case 22: User, release, update possible, file match]
The owning directory is open to the public and can be updated by the user. Also, the user node file and the center controller file match. In this case, no action occurs.

[Case 23: User, release, update possible, user node file is old version]
The owning directory is open to the public and can be updated by the user. The user node file and the center controller file are old in the user node. In this case, if the user node file exists in the history of the center controller, the user node downloads the file from the center controller and overwrites it. On the other hand, if the user node file does not exist in the history of the center controller, the user node changes the file name and then downloads the file from the center controller.

[Case 24: User, release, update possible, user node file is new version]
The owning directory is open to the public and can be updated by the user. Also, the user node file and the center controller file are new in the user node file. In this case, the user node file is uploaded to the center controller. The center controller to which the file is uploaded stores the uploaded file as a new generation file. The center controller instructs the mail server 16 to notify the owner node of the file update by the user node by mail.

[Case 25: User, public, updateable, no file on user node]
The owning directory is open to the public and can be updated by the user. Also, the file does not exist on the user node. In this case, the user node downloads a file from the center controller.

[Case 26: User, release, update possible, no file in center controller]
The owning directory is open to the public and cannot be updated by the user. The file does not exist in the center controller.

  In this case, the user node uploads a file to the center controller. The center controller that has received the file registers the file as a new file. Alternatively, assuming that the file deleted by the owner is restored, the center controller may register the file.

  Next, actual information exchange between the file owner's client PC (node) and the control server (center controller) and processing in each will be described in more detail. Initially, the file management unit 34 of the client PC 12 transmits its own information (node name, node identification code) and the like to the control server 10. The control server 10 generates a record of the online node management table based on the received information and stores it in the DB 20.

  Prior to file transfer, the file management unit 34 of the client PC 12 prepares information on files to be backed up or shared as records in the owned directory information table 212. When the value of this record is transmitted to the control server 10 via the network 14, the file management unit 24 of the control server 10 creates a record of the owner path information table 201 based on the value of this record. And stored in the owner path information table 201.

  Further, in the client PC 12 of the person who wants to use the file owner's file (user), the file management unit 34 prepares a record of the usage directory information table 213. For example, the client PC 12 accesses the control server 10, refers to the owner path information table, specifies a file to be used, receives the record information, and creates a record of the usage directory information table 213. be able to.

  Next, with reference to FIG. 9, a synchronization (Sync) process related to file download and upload in the client owner's client PC 12 will be described.

After establishing communication with the control server 10 (step 901), the file management unit 34 of the client PC 12 transmits basic attribute information of the file to the control server 10 for each file in the owned directory (step 902). ). The file basic attribute information includes the values of the following items.
-File name-Relative path relative to the owning directory from the absolute path of the file
-Time stamp of the file-MD5 (Message Digest 5) hash value of the file-File size (number of bytes)

The file management unit 24 of the control server 10 includes the contents of the file basic information transmitted from the client PC 12-1 and the records in the tables (for example, the owner path information table and the actual file generation information table) stored in the DB 20. The value is compared to determine which case corresponds to the above (step 903). Here, the following modes can be considered for file matching, file updater matching, and the like.
(1) File matching (the updater of the client PC and the updater recorded in the control server also match).
(2) File match (however, the updater does not match).
(3) The file version of the client PC (node) is old (the updater of the client PC matches the updater recorded in the control server).
(4) The file version of the client PC is old (the updater does not match).
(5) The file version of the client PC is new (the updater of the client PC matches the updater recorded in the control server).
(6) The file version of the client PC is new (the updater does not match).
(7) The file does not exist on the control server.

  Regarding the updater match, when communication is established between the client PC 12 and the control server 10, the node name in the message sent from the client PC 12 to the control server 10 and the node name in the owner path information table Can be determined by comparing the two.

  In addition, the file (contents) match is determined as follows.

  Relative path, file name (real file information table: see FIG. 7A), time stamp of the file, and MD5 hash value of both files (real file generation information table: FIG. 7B) Are compared).

  Assume that the determination criteria indicating the same file are files having the same relative path and the same hash value. That is, if the hash value is the same even if the file name and the time stamp are different, both file contents are identified as the same. If the hash values are different, the time stamps of both files are compared to determine which is newer.

  The condition determination unit 32 of the control server 10 returns to the client PC 12 which of the above-described (1) to (7) the determination result is (step 904).

The condition determination unit 32 of the client PC 12 receives the determination result, and when the file should be uploaded based on the determination result (Yes in step 905), the file management unit 34 transmits the file to the control server 10. (Step 906). On the other hand, when the file is to be downloaded (Yes in Step 907), the file management unit 34 requests the control server 10 to download the file (Step 908). A file is downloaded from the control server 10 in response to the download request (step 909).
The file upload process (step 906) will be described in more detail. The file management unit 34 of the client PC 12 processes the file stored in its own storage device 30 in the following procedure, and uploads it to the DB 20 of the control server 10. As shown in FIG. 10A, the client PC 12 collects file basic attribute information again (step 1001). For this, what is previously transmitted to the control server 10 in step 901 may be used. Next, attribute information after compression of the file is collected (step 1002). More specifically, the file is compressed using a compression tool (step 1003), the size (number of bytes) of the compressed file is calculated (step 1004), and the MD5 hash value of the compressed file is calculated. Calculate (step 1005). Thereafter, the file basic attribute information, the compressed attribute information, and the compressed file are transmitted to the control server 10 (step 1005).

  As shown in FIG. 10B, when the control server 10 receives a file or the like (step 1011), the control server 10 stores the file at a position according to the relative path in the file basic attribute information in the DB 20 (step 1012). Then, the value of the corresponding record in the real file generation information table 203 is updated according to the file basic attribute information and the compressed attribute information (step 1013). Thereafter, the control server 10 transmits a telegram for notifying file upload to the client PC 12 (step 1014).

  When the client PC 12 downloads a file from the control server 10, in addition to its own “node name”, “node identification number”, etc., “relative path”, Include "file name", "time stamp" and "hash value" of the file to be downloaded. Thereby, the file management unit 24 of the control server 10 can specify a file to be downloaded.

  Next, a synchronization (Sync) process related to file download and upload in the file user's client PC 12 will be described. This process is also basically similar to the synchronization process in the client PC of the file owner described with reference to FIG.

After establishing communication with the control server 10, the file management unit 34 of the file user client PC 12 transmits basic attribute information of the file to the control server 10 for each file in the usage directory.
The file basic attribute information includes the values of the following items.
-File name-Relative path relative to the owning directory from the absolute path of the file
-Time stamp of the file-MD5 (Message Digest 5) hash value of the file-File size (number of bytes)

The file management unit 24 of the control server 10 compares the content of the file basic information transmitted from the client PC 12-1 with the content of the record in the table stored in the DB 20, and corresponds to any of the cases described above. (Step 903). Here, the following modes are considered for file matching and the like.
(1) File match (2) The file version of the client PC (node) is old (a record relating to the file exists in the real file generation information table).
(3) The file version of the client PC (node) is old (the record for the file does not exist in the actual file generation information table).
(4) The file version of the client PC (node) is new (in the owner path information table, the file can be updated in the record related to the file).
(5) The file version of the client PC (node) is new (file update is disabled).
(6) The file does not exist on the control server.

  The condition determination unit 32 of the control server 10 returns to the client PC 12 which of the above-described (1) to (6) the determination result is. The condition determination unit 32 of the client PC 12 receives the determination result, and when the file is to be uploaded based on the determination result, the file management unit 34 uploads the file to the control server 10. On the other hand, when the file is to be downloaded, the file management unit 34 requests the control server 10 to download the file. A file is downloaded from the control server 10 in response to the download request.

  In the above example, the client PC of the user is configured to download a file from the control server 10, but the present invention is not limited to this. For example, before requesting the download to the control server 10, the user's client PC transmits a download request message to the owner's client PC, and if possible, the file is sent from the owner's client PC. May be downloaded. Here, the message of the download request transmitted from the user client PC to the owner client PC includes a time stamp and a hash value in order to identify the file. If the owner's client PC is different from the requested file, the owner's client PC may reject the download request from the user client PC. In this case, the user client PC requests the control server 10 to download a file.

Next, application examples of the present embodiment will be described. First, the case where the control server 10 is used as a file backup device of the client PC 12 will be described. As shown in FIG. 11, it is considered that a certain file (a file in which the client PC 12 is the file owner) has been updated in the client PC 12 (step 1101). The file management unit 34 of the client PC 12 transmits the file basic attribute information of the updated file to the control server 12 (step 1102). The condition determination unit 22 of the control server 10 compares the contents of the file basic information with the values of the records in the table stored in the DB 20, and takes any one of the modes (1) to (7) described above. Judgment is made as to whether or not (step 1103). In this example,
(5) The file version of the client PC is new (the updater of the client PC matches the updater recorded in the control server).
It is judged to fall under. The determination result is transmitted to the client PC 12 (step 11004). The condition determination unit 32 of the client PC 12 determines that the file should be uploaded, and the file management unit 34 uploads the file to the control server 10 (step 1105). The file management unit 24 of the control server 10 stores the uploaded file at a predetermined position in the DB 20 and updates the record of the actual file generation information table (step 1106).

  Next, the case of working as a team will be described. It is assumed that one client PC (for example, client PC 12-1) functions as a librarian and other client PCs (for example, client PCs 12-2, 12-3,...) Function as team members.

  When working on a project with multiple people, such as system design, it is important to keep track of who created and changed which files and who knows when to create and change them. In such a case, a file sharing operation can be realized by combining the mail server 16 having the mailing list function of E-Mail as an auxiliary means of this mechanism.

  First, a person (librarian) in charge of managing the entire document defines an owned directory, and the client PC 12-1 of the librarian registers a record of the owned directory information table in the control server 10. Thereby, a record of a necessary owner path information table is generated in the control server 10. Here, a mailing list is set through which mail can be notified to client PCs of project members via the mail server 16.

  For example, by registering a project member with a mailing list for immediate notification or once-a-day batch sending, project members who are engaged in actual work automatically create and modify files created by other members. It can be stored in the local disk of its own client PC, and a change notification mail can be received at every change.

  Also, those who are not involved in the actual work but need to know the overall trends (for example, project leaders / subleaders) are notified by email of the changes made the previous day, and the various files that are the deliverables. However, it is possible to create a situation where it is already stored in the local disk of its own client PC.

  In addition, when a project is separated (for example, when the work for the first release of the product is completed), the librarian changes the attribute of the owned directory from public / updateable to public / non-updateable, so that the document Freezing can be done easily.

  In addition, in order to fix and store the file at the time of release, the librarian defines the usage directory, downloads the fixed file to the local disk, and then registers the directory on the local disk first. By defining it as an own directory (public / unupdateable) different from the own directory, it is possible to store a file at a specific point in time. Then, by changing the attribute of the original owned directory to be public / updatable, the change work for the next release can be continued.

  For example, as shown in FIG. 12, the librarian's client PC 12-1 transmits a record of the ownership directory information table of the file to be shared to the control server 10 (step 1201). Here, in the record, “public flag” is set to “ON”, and “public type” is set to “updateable”. The transmitted record is registered as a record of the owner path information table in the control server 10 (step 1202). Further, the client PC 12-1 registers the mail address of each member for the mailing list in the mail server 16 (step 1203).

  On the other hand, the client PCs 12-2, 12-3,... Of the project members refer to the record of the owner path information table of the control server 10 and store the usage directory information in the storage device of the client PC. Create a record.

  As shown in FIG. 13, for example, the client PC 12-2 of the project member creates and updates a file in the directory specified by the record in the usage directory information table (step 1301). When the file is created and updated, the file management unit 34 of the client PC 12-2 transmits the basic attribute information of the file to the control server 10 (step 1302).

  The condition determination unit 22 of the control server 10 compares the basic attribute information of the file with the information of the corresponding record of the actual file generation information of the file (step 1303), and the determination result is sent to each client PC 12-1, 12-3,... (Step 1304). The control server 10 requests the mail server 16 to send a mail using the mailing list (step 1305). Based on the determination result, the client PC 12-1 uploads a file related to creation and update to the control server 10. Thereby, the control server 10 updates the corresponding record in the real file generation information table with respect to the file.

  The condition determination unit 22 of each of the PCs 12-1, 12-3,... Determines that the file should be downloaded, and requests the control server 10 to download the file. Thereby, the file which the member created and changed using client PC12-2 can be acquired.

  Next, the file freezing operation and the operation start of the next phase will be described with reference to FIG. First, the librarian's client PC 12-1 requests the mail server 16 to send a notification of change work suspension using the mailing list (step 1401). Next, the client PC 12-1 changes the “public type” from “updatable” to “not updatable” in the record of the corresponding file in the owned directory information table (step 1402).

  Thereafter, the client PC 12-1 newly creates a directory for storing frozen files in the storage device 30, and registers the directory as a usage directory (step 1403). That is, a record of the usage directory information table is created. As a result of transmitting this basic attribute information to the control server 10, all the latest versions of each file are downloaded from the control server 10 to the client PC 12-1 (step 1404).

  After the download is completed, the client PC 12-1 deletes the record in the user directory information table and defines the local directory as the owning directory again (step 1405). That is, the information of the local directory is stored as a record of the owned directory information tag. Here, the “public type” is set to “unupdateable”. As a result, the files in this local directory are separately managed by the control server 10.

  Thereafter, the user can update the file by changing the “public type” of the original directory from “not updatable” to “updatable” (step 1406). The client PC 12-1 requests the mail server 16 to send a notification of resuming the change work using the mailing list (step 1407).

  The processing of the client PC 12-1 can be automatically executed according to the sequence.

  As a result of the above-described processing of the client PC 12-1, the DB 20 of the control server 10 is fixed in accordance with the ownership directory (the directory that was originally used for work) for each member to continue working and with the release. There will be two non-changeable owned directories where files are stored.

  The present invention is not limited to the above embodiments, and various modifications can be made within the scope of the invention described in the claims, and these are also included in the scope of the present invention. Needless to say.

FIG. 1 is a block diagram showing a configuration of the entire system including a file backup / sharing control server according to an embodiment of the present invention. FIG. 2A is a block diagram showing the configuration of the control server, and FIG. 2B is a block diagram showing the configuration of the client PC. FIG. 3 is a diagram showing a data configuration of the node basic information table according to the present embodiment. FIG. 4 is a diagram showing a data configuration of the owned directory information table according to the present embodiment. FIG. 5 is a diagram showing a data configuration of the usage directory information table according to the present embodiment. FIG. 6A is a diagram illustrating a data configuration of the online node management table according to the present embodiment, and FIG. 6B is a diagram illustrating a data configuration of the owner path information table. FIG. 7A is a diagram showing a data configuration of the real file information table according to the present embodiment, and FIG. 7B is a diagram showing a data configuration of the real file generation information table. FIG. 8 is a table showing a result of comparing files between the client PC and the control server. FIG. 9 is a flowchart showing a synchronization (Sync) process related to file download and upload in the client PC of the file owner. FIGS. 10A and 10B are bath charts showing file upload processing, respectively. FIG. 11 is a diagram for explaining processing when the control server is used as a file backup device of a client PC. FIG. 12 is a diagram for explaining processing executed by the client PC and the control server when working as a team. FIG. 13 is a diagram for explaining processing executed by the client PC and the control server when working as a team. FIG. 14 is a flowchart showing file freezing work on the client PC and starting work of the next phase when working as a team.

Explanation of symbols

10 Control server 12 Client PC
14 Network 16 Mail server 20 DB
22 Condition Judgment Unit (Center Condition Judgment Unit)
24 File Management Department (Center File Management Department)
30 Storage Device 32 Condition Judgment Unit (Local Condition Judgment Unit)
34 File Manager (Local File Manager)

Claims (9)

A directory path in which a file owned by itself is stored, an owned directory information table having a record including a directory name, and
A client computer having local file management means for managing uploading and downloading of the file via a network;
The owner that stores the record including the node name of the file owner, the directory name that stores the file of the client computer, and the update time generated based on the record of the owned directory information table sent via the network Path information table,
An actual file information table having a record including a node name of the file owner, a file name, and a directory path in which the file is stored;
Real file generation information table having a record including file name, file time stamp, information indicating the contents of the file,
Based on file basic attribute information including information indicating the file name, directory path, file time stamp, and file contents sent from the local management unit via the network, the real file information table and the real file generation Referring to the information table, determining a download or upload condition relating to the file, and sending a determination result to the client computer;
Center file management means for storing the uploaded file in a predetermined directory path in the storage device and downloading the file stored in the predetermined directory path to the client computer in accordance with a request from the client computer And a control server having
A file sharing control system, wherein the client computer has local condition determination means for requesting the control server to download or upload the file according to the determination result. Furthermore, the client computer has a usage directory information table having a record including the node name and directory name of another client computer that owns the file to be used,
The local file management means transmits file basic information including information indicating the file name, directory path, file time stamp, and file content of the file to be used based on the usage directory information table,
Based on the file basic attribute information including information indicating the file name, directory path, file time stamp, and file content sent from the local management means via the network by the center condition determining means of the control server. Refer to the real file information table and the real file generation information table, determine the download or upload conditions for the file, and send the determination result,
2. The file sharing control system according to claim 1, wherein local condition determination means of the client computer requests the control server to download or upload the file according to the determination result. Furthermore, the client computer has a usage directory information table having a record including the node name and directory name of another client computer that owns the file to be used,
The local file management means transmits file basic information including information indicating the file name, directory path, file time stamp, and file content of the file to be used based on the usage directory information table,
Based on the file basic attribute information including information indicating the file name, directory path, file time stamp, and file content sent from the local management means via the network by the center condition determining means of the control server. Determine the download or upload conditions for the file, send the determination results,
2. The file sharing control according to claim 1, wherein local condition determination means of the client computer requests the client computer that owns the file to download or upload the file according to the determination result. system. The record of the owned directory table includes a disclosure flag indicating whether or not the file can be disclosed, and disclosure type information indicating whether or not the file can be updated when the disclosure is possible.
The owner path information table includes the disclosure flag and disclosure type information;
The said center condition judgment means judges the conditions of the download or upload regarding the said file with reference to the publication flag and publication type information of the said owner path information table. File sharing control system. 5. The information indicating the contents of the file is a hash value of the file, and the center condition determining means determines a match of the contents of the file by comparing the hash values. The file sharing control system according to any one of the above. Client generated by the client computer and transmitted via the network on the basis of the owning directory information table having a record including a directory path and directory name in which the client computer has a file owned by the client computer. An owner path information table for storing a record including a computer name, a directory name for storing a file of the client computer, and an update time;
An actual file information table having a record including a node name of the file owner, a file name, and a directory path in which the file is stored;
Real file generation information table having a record including file name, file time stamp, information indicating the contents of the file,
Based on the file basic attribute information including information indicating the file name, directory path, file time stamp, and file content sent via the network, the real file information table and the real file generation information table are referred to. Center condition determining means for determining a download or upload condition relating to the file, and transmitting the determination result to the client computer, and
Center file management means for storing the uploaded file in a predetermined directory path in the storage device and downloading the file stored in the predetermined directory path to the client computer in accordance with a request from the client computer With
The file sharing control server, wherein the center file management means downloads or uploads the file in response to a request for downloading or uploading the file according to the determination result from the client computer. The center condition determining means is generated by the client computer based on a use directory information table having a record including a node name and a directory name of another client computer that owns the file that the client computer has, and The real file information table and the real file generation information table based on file basic information including information indicating the file name, directory path, file time stamp, and file contents of the file to be used, transmitted via the network. The file sharing control server according to claim 7, wherein the file sharing control server is configured to determine a download or upload condition related to the file and transmit the determination result to the client computer. Client generated by the client computer and transmitted via the network on the basis of the owning directory information table having a record including a directory path and directory name in which the client computer has a file owned by the client computer. The owner name information table that stores the record including the computer name, the file name of the client computer, and the update time, the node name of the file owner, the file name, and the directory path where the file is stored A computer having a real file information table having a record including a file name, a file time stamp, and a real file generation information table having a record including information indicating the contents of the file. Ri a readable program, said computer,
Based on the file basic attribute information including information indicating the file name, directory path, file time stamp, and file content sent via the network, the real file information table and the real file generation information table are referred to. Center condition determining means for determining a download or upload condition relating to the file, and transmitting the determination result to the client computer, and
Center file management means for storing the uploaded file in a predetermined directory path in the storage device and downloading the file stored in the predetermined directory path to the client computer in accordance with a request from the client computer A file sharing control program that functions as center file management means for downloading or uploading the file in response to a request for downloading or uploading the file according to the determination result from a client computer. When the computer functions as center condition determining means, the client computer has a client computer based on a use directory information table having a record including a node name and a directory name of another client computer that owns a file to be used. The actual file information based on the file basic information including information indicating the file name, directory path, file time stamp, and file content of the file to be used, which is generated by and transmitted via the network The computer and the real file generation information table are referred to, the download or upload condition relating to the file is determined, and the determination result is transmitted to the client computer. File sharing control program according to claim 8, characterized in that to operate.

Images