Patent Publication Number: US-2005131902-A1

Title: File system and file transfer method between file sharing devices

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
      This application relates to and claims priority from Japanese Patent Application No. 2003-312273 filed on Sep. 4, 2003, the entire disclosure of which is incorporated herein by reference.  
     BACKGROUND OF THE INVENTION  
      1. Field of the Invention  
      The present invention relates to a file system that employs a file server, NAS (Network Attached Storage), and so forth, for example, and to a method for transferring files between file sharing devices.  
      2. Description of the Related Art  
      In order to share data between a plurality of computer terminals distributed on a network, a file server has conventionally been used. As an early stage file server, a file server that implements a file sharing protocol such as CIFS (Common Internet File System), NFS (Network File System; NFS is a registered trademark or trademark of U.S. Sun Microsystems, Inc.) in a general purpose OS (Operating System), for example, is known. NAS, which employs a dedicated OS that is specialized for file sharing services and supports a plurality of file sharing protocols (CIFS, NFS, DAFS (Direct Access File System), and so forth), is known as an enhanced file server.  
      These file servers are capable of managing access rights by setting permission information. When NFS is used, for example, settings to allow three types of users such as ‘owner’, ‘group’ and ‘other’ to perform the reading of files, writing to file and file execution can be made. Alternatively, when CIFS is used, for example, access control that differs from user to user can be performed for the same file by using access control information known as ‘ACL’ (Access Control List). As a result, only those users for whom access rights have been set beforehand are able to access the files.  
      Further, there is a year-on-year increase in the number of clients using files for sharing and shared files. For this reason, new file servers are added to existing file sharing systems in order to cater to the increase in the number of files and the new demand. When a new file server is added, all or some of the files stored on an existing file server are sometimes moved to the new file server. Further, there are also cases where files are moved between directories and volumes in accordance with system reorganization and so forth, for example.  
      A variety of methods for transferring files from a transfer source file server to a transfer destination file server are known. For example, there exist methods that make a backup of files stored in the transfer source file server by using a backup device such as a tape device, and then restore the backup data in the transfer destination file server, for example. In this case, the directory structure of the transfer source is backed up together with attribute information that includes access control information, and this directory structure and attribute information are restored in their entirety in the transfer destination device. Alternatively, there also exist methods that individually transfer predetermined directories or predetermined files of the transfer source file server to the transfer destination file server by using a dump command, tar command, cp command, xcopy commands and so forth, for example.  
      Further, in order to convert a data file used by a COBOL program into a database format, for example, a technology that automates the data conversion between data files of different types by providing common record format information that is a combination of data definition information and attribute information, is also known (Japanese Patent Application Laid-Open No. 2000-347907).  
      When the transfer source file server and transfer destination file server are supplied with the same file server functions so as to be NFS servers or CIFS servers, or the like, for example, the storage structure can also be transferred in its entirety by making a complete backup of the files of the transfer source file server, metadata, and the directory structure, and then restoring same in the transfer destination file server.  
      On the one hand, when the respective file server functions of the transfer source file server and the transfer destination file server are different, as in the case of an NFS and CIFS server, or the like, for example, it is difficult to transfer the metadata. This is because, when the OS is different in each case, there is a difference between the directory structure of the transfer source file server and the directory structure of the transfer destination file server.  
      For example, suppose that, in the case of the transfer source file server, a ‘/folder’ directory exists below a directory ‘/share’ (‘/share/folder’). When this ‘/folder’ is transferred to a transfer destination file server with a different type of OS, the ‘/folder’ is sometimes automatically placed below a ‘/current’ directory under ‘/share’ at the, request of the file management system. The difference in the actual directory structure is not recognized by the client. A different. OS resource sharing program installed on the transfer destination file server serves to display the ‘/folder’ on the client by concealing the actual difference in directory structure. ‘Samba’ is a known example of a program that permits resource sharing (file exchange) between these different types of OS.  
      Although, when files are transferred between different OS, there is no change in the appearance of the directory structure following the transfer, sometimes metadata (attribute information) such as access control information is lost and not correctly reflected in the transfer destination file server. More particularly, when desired files, directories, and so forth, are individually selected and transferred by way of a so-called ‘drag &amp; drop’ operation via a GUI (Graphical User Interface) screen, there is the possibility that, even though the file body is transferred, metadata such as access control information will be lost. In such a case, the administrator of the file server must reset the access control by manually examining the files one by one while referencing pre-transfer access control information. However, because the actual directory structure is different, the work involved in specifying the files is arduous. Further, when a plurality of files of the same type and with the same name are discovered, the administrator then ponders over the judgment of whether access control should be set for any of these files.  
      A data file automatic conversion device, such as that appearing in the Japanese Patent Application Laid-Open No. 2000-347907, merely changes a predefined data file from one format to another. The directory structure and metadata, and so forth are not considered. Further, the rules for converting the data files must be predefined and the constitution is complex. In addition, in the case of a file server, a multiplicity of files in various formats exists in a variety of locations within a complex hierarchical storage structure and each have different metadata, and it is therefore difficult to transfer these files [and metadata] accurately.  
     SUMMARY OF THE INVENTION  
      The present invention was conceived in view of the above problems, and one embodiment of the present invention provides a file sharing system that makes it possible to specify the files that are transferred. Another embodiment of the present invention provides a file sharing system and method for transferring files between file sharing devices that are capable of automatically specifying transferred files and resetting attribute information. Further, other embodiment of the present invention provides a file sharing system that makes it possible to specify files even when a plurality of files of the same type and with the same name exists at the transfer destination. Further objects of the present invention will become evident from the description of the embodiment described subsequently.  
      More specifically, in order to solve the above problem, the file sharing system according to an embodiment of the present invention comprises: a transfer source file sharing device; a transfer destination file sharing device that is communicably connected to the transfer source file sharing device; selecting means for selecting at least one or more files kept in the transfer source file sharing device; characteristic information acquiring means for acquiring characteristic information on the selected file(s); file transferring means for transferring the selected file(s) to the transfer destination file sharing device; and file specifying means for specifying the file(s) transferred to the transfer destination file sharing device on the basis of the acquired characteristic information.  
      The transfer source file sharing device and transfer destination file sharing device can be constituted as file servers (including NAS). The transfer source file sharing device and transfer destination file sharing device have their storage resources managed, store a multiplicity of files, and are capable of providing file sharing services to a multiplicity of clients. The transfer source file sharing device and transfer destination file sharing device are connected so that bidirectional data communications via a LAN (Local Area Network), for example, are possible. Further, the a file sharing device may be connected to a storage device via a SAN (Storage Area Network).  
      The user (administrator, or the like, for example) selects, via the selecting means, at least one or more files (including directories) that are kept on the transfer source file sharing device. The characteristic information acquiring means acquire characteristic information for the selected file(s) Here, characteristic information is information indicating the characteristics of the selected file(s), and is used in order to search for the selected file(s). Examples of characteristic information can include the file name, file path information, the file size, the file update date and time, and so forth, for example. Further, a message digest can also be used as described below. Files selected by the selecting means are shifted to the transfer destination file sharing device by the file transfer means. The file specifying means specify files by seeking out transferred files from within a file group kept in the transfer destination file sharing device based on characteristic information generated beforehand. Therefore, even when files are transferred between different OS, transferred files can be specified on the basis of characteristic information.  
      Further, according to an embodiment of the present invention, the characteristic information acquiring means comprise attribute resetting means that acquire characteristic information including predetermined attribute information relating to the selected file(s) and associate the predetermined attribute information included in the characteristic information with the file(s) specified by the file specifying means.  
      Examples of predetermined attribute information include ACL or other access control information. When a transferred file is specified, the attribute resetting means reset predetermined attribute information for the specified file.  
      The characteristic information acquiring means are also capable of acquiring characteristic information including other attribute information relating to the selected file(s)  
      Examples of other attribute information can include the file name, file size, update date and time, file path information, and so forth.  
      According to an embodiment of the present invention, the characteristic information acquiring means also acquire the characteristic information that includes identity information indicating a file identity that is obtained by processing data of the selected file(s) by means of a predetermined function.  
      Examples of identity information indicating a file identity can include a message digest rendered by using a hash function. A hash function generates a pseudo random number of a fixed length from the supplied original data. A value generated by a hash function is known as a ‘hash value’ or ‘message digest’. If original data are different, the respective hash values are a so different, and hence the file content identity can be certified according to the hash values. A file can be specified more accurately by including identity information such as a hash value in the characteristic information of the file.  
      According to an embodiment of the present invention, when unable to specify the file by means of the other attribute information included in the characteristic information, the file specifying means specify the file by using the predetermined function to generate the identity information, and then comparing the generated identity information with the identity information included in the characteristic information.  
      In other words, the file specifying means attempt file specification by means of other attribute information such as the file name, file size, update date and time, for example. However, when, supposedly, a plurality of files with the same name, same size, and with an equal update date and time is present, the file cannot be specified by means of the other attribute information alone. In this case, the file specifying means specify the file by calculating identity information (a hash value) for a plurality of retrieved candidate files and, comparing this information with identity information included in the characteristic information.  
      According to an embodiment of the present invention, when unable to specify the file by means of the identity information, the file specifying means determine the similarity between file path information of the transfer source file sharing device and file path information of the transfer destination file sharing device, and specify the file on the basis of this similarity.  
      A case where a plurality of files with common identity information indicating a file content identity is present has also been considered. In this case, the file specifying means specify a file by focusing on file path information. That is, the file specifying means specify the file by determining the similarities between file path information prior to the transfer and file path information following the transfer. Stated in more detail of the file path information, the path information located at the top of the directory structure possesses properties that are dependent on the system (OS), and path information located at the bottom of the directory structure possesses properties dependent on the user. The user suitably sets a directory with a name that is easy for him/her to understand in a storage region that he or she is able to use in order to perform proprietary file management. Therefore, the file can be specified by analyzing the similarity with an emphasis on the lower order information of the file path information, for example.  
      The method for transferring files between file sharing devices according to a further embodiment of the present invention comprises the steps of: selecting at least one or more files to be transferred in a transfer source file sharing device; acquiring characteristic information including predetermined attribute information relating to the selected file(s); transferring the selected file(s) to the transfer destination file sharing device; specifying the file(s) transferred to the transfer destination file sharing device on the basis of the acquired characteristic information; and associating the predetermined attribute information included in the characteristic information with the specified file (s).  
      A computer program according to another embodiment of the present invention allows a computer to execute the steps of: acquiring a transfer target range selected in the transfer source file sharing device; acquiring, for all files included in the transfer target range, at least attribute information for each file, access control information, and identity information obtained by means of a predetermined function; and outputting characteristic information on the basis of each item of information acquired for each of the files.  
      The computer program is run on the transfer source file sharing device. This computer program makes file transfer arrangements in order to implement a file transfer according to metadata between different OS, for example. This computer program acquires and outputs characteristic information for files for which a transfer is scheduled. A file can be specified in the transfer destination file sharing device by referencing the characteristic information thus output.  
      A computer program according to yet another embodiment of the present invention allows a computer to execute the steps of acquiring characteristic information including attribute information, access control information, and identity information obtained by means of a predetermined function, for at least one or more transferred files; setting a predetermined search range; specifying the transferred file(s) on the basis of the characteristic information in the set search range; and resetting the access control information for the specified file(s).  
      This computer program is run on the transfer destination file sharing device. This computer program pre-filters a predetermined region as the search range in the storage region managed by the transfer destination file sharing device. For example, the search range can be pre-filtered by considering the name of the directory to which the transferred file belongs, or the name of the shared directory set beforehand by the transfer destination file sharing device, for example. This computer program performs a search within the set search range based on the characteristic information and thus specifies a file. This computer then resets access control information for the specified file. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       FIG. 1  is a block diagram showing an overall outline of the file sharing system according to an embodiment of the present invention;  
       FIG. 2  is an explanatory view of an example of access control information;  
       FIG. 3  is an explanatory view of an example of an examination result file;  
       FIG. 4  is a schematic view of a file management image in a case where a file is transferred, in which  FIG. 4 ( a ) is a file management image for the transfer source,  FIG. 4 ( b ) is a file management image of the transfer destination, and  FIG. 4 ( c ) shows a view from the client side;  
       FIG. 5  is a flowchart showing an outline of the overall operation in a case where a file is transferred;  
       FIG. 6  is a flowchart showing examination result file generation processing that is executed by the transfer source file server;  
       FIG. 7  is a flowchart showing ACL information resetting processing that is executed by the transfer destination file server;  
       FIG. 8  is a flowchart showing the details of S 34  in  FIG. 7 ;  
       FIG. 9  is a schematic view of an aspect in which a plurality of files with the same content is present;  
       FIG. 10  is a flowchart of ACL information resetting processing according to a second embodiment of the present invention;  
       FIG. 11  is a flowchart of duplicate file deletion processing according to a third embodiment of the present invention; and  
       FIG. 12  is a flowchart showing examination result file transfer processing. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
      Embodiments of the present invention will be described below on the basis of FIGS.  1  to  12 .  
      As described in detail hereinbelow, the present invention specifies transferred files and automatically sets access control information by means of co-operation between a computer program (file examination agent) that is executed by the transfer source file server and a computer program (file specification and attribute setting agent) that is executed by a transfer destination file server.  
     First Embodiment  
       FIG. 1  is a block diagram showing an overall outline of the file sharing system according to this embodiment. As will be described subsequently, the file sharing system is constituted comprising a transfer source file server  10  that comprises a file system  20 , and a transfer destination file server  40  that comprises a file system  50 . The file servers  10  and  40  may be devices that implement a file sharing protocol in a general purpose OS, or may be devices (NAS) having an OS, specialized for file sharing services.  
      The transfer source file server  10  controls the file system  20  and comprises an OS and file system program (hereinafter ‘OS or similar’)  11 , and a file examination function  12 . The OS or similar  11  provides a base for file sharing services, such as one that accepts file access requests (read/write) and so forth from administrator of the transfer source file server  10 , file system  20 , and so forth, or from users other than the administrator and provides services in accordance with the file access requests and so forth, for example. The OS or similar is compatible with one or more file sharing protocols.  
      The file examination function  12  examines characteristic information (described subsequently) with respect to transfer target files, and outputs an examination result file  30 . The examination result file  30  is used by the transfer destination file server  40 . The file examination function  12  can be constituted by an ACL information acquisition function  121 , a hash value computation function  122 , a meta-information acquisition function  123 , and an examination result file generation function  124 , for example. The file examination function  12  can be wholly constituted by a computer program but is not limited to a computer program. At least some of these functions can also be constituted by a hardware circuit. Further, the file examination function  12  can also be mounted in a communication control unit such as an NIC (Network Interface Card), for example.  
      The ACL information acquisition function  121  acquires ACL information that is access control information set in a file constituting a transfer target. In other words, the ACL information acquisition function  121  acquires information indicating in what manner (reading, writing and execution) and by which users a transfer target file can be accessed. Further, access control information is not limited to ACL information. The hash value computation function  122  generates, with respect to a file constituting a transfer target, a pseudo random number of fixed length that is dependent on the file content by passing the data of this file through a predetermined hash function. Further, as long as the file content identity is verifiable information, file content identity is not limited to a hash value. The meta-information acquisition function  123  acquires metadata associated with the transfer target file. Examples of metadata can include the file name, file size, file path information (information indicating the storage position of the file system  20 ), the update date and time (year/month/day/hour/minutes/seconds), and so forth. The examination result file generation function  124  generates and outputs the examination result file  30 , which defines the characteristics of the transfer target file by means of the acquired ACL information, hash value, and metadata. The constitution of the examination result file  30  will be described in more detail later.  
      The file system  20  is connected to the transfer source file server  10  and stores a multiplicity of files  21 . The file system  20  is constructed by using storage devices such as a hard disk drive, semiconductor memory, optical disk, or the like, for example, and the storage devices constituting the file system  20  can be interconnected by a SAN or similar, for example. The transfer source file server  10  and file&#39;system  20  may be constituted as separate devices or may be incorporated in one device.  
      The transfer destination file server  40  controls the file system  50  and comprises an OS or similar  41  and an ACL information setting function  42 . The transfer destination file server  40  is connected to the transfer source file server  10  so that bidirectional data communications via a communication network CN such as a LAN, for example are possible. Further, the transfer destination file server  40  is connected to one or more (normally a multiplicity of) client terminals (not shown) via a communication network such as a LAN or the Internet. In addition, the communication network used for file sharing services and the communication network used for file transfers may be a common network or may be separate networks. The OS or similar  41  provides a base for file sharing services, such as one that accepts file access requests (read/write) and so forth from the administrator of the transfer destination file server  40 , file system  50 , and so forth, or from users other than the administrator and provides services in accordance with the file access requests and so forth, for example. The OS or similar  41  is compatible with at least one or more file sharing protocols. Stated in more detail, the OS or similar  41  is compatible with a file sharing protocol that the transfer destination file server  40  comprises and another file sharing protocol that differs from this file sharing protocol.  
      The ACL information setting function  42  specifies a file  51  that is transferred from the file system  20  of the transfer source file server  10  to the file system  50  of the transfer destination file server  40  on the basis of the examination result file  30 , and resets the ACL information. The ACL information setting function  42  can be constituted comprising a search range setting function  421 , an examination result file acquisition function  422 , a hash value computation function  423 , a file specification function  424 , and an ACL setting function  425 , for example. The ACL information setting function  42  can also be wholly constituted as a computer program and at least partially constituted as a hardware circuit.  
      The search range setting function  421  is for presetting the range within which the file system  50  is searched. For example, by setting the search range on the basis of a directory that is set for disclosure by the transfer destination file server  40  and a directory of transferred files, the search can be performed efficiently by filtering the search range. The examination result file acquisition function  422  acquires the examination result file  30  generated by the file examination function  12  of the transfer source file server  10 . Further, the examination result file  30  is transferred from the transfer source file server  10  to the transfer destination file server  40  manually or automatically as per an embodiment described later. The hash value computation function  423  calculates a hash value that is based on the file content as information for specifying the file. A hash value may be determined in the same way for a retrieved file or a hash value may be calculated only in cases where a file is specified. The file specification function  424  searches the search range set in the file system  50  on the basis of the examination result file  30  and specifies which file the file transferred from the file system  20  to the, file system  50  is. When a file is specified, the ACL setting function  425  resets the ACL that was set prior to the transfer to a post-transfer file on the basis of the examination result file  30 .  
      As per the file system  20 , the file system  50  is constituted by using storage devices such as a hard disk, semiconductor memory, optical disk, or the like, and is capable of storing a multiplicity of files.  
      Let us refer now to  FIG. 2 .  FIG. 2  is an explanatory view that schematically shows an example of ACL information. As shown in this figure, access control information (ACL information) can be set in each file. For example, rights enabling access by each account, such as a user, group, or the like, to each file can be defined for each account. Examples of access rights include the reading of files (reading), writing to file (writing), access denial (NG), and so forth.  
      Let us refer now to  FIG. 3 .  FIG. 3  is an explanatory view of an example of the examination result file  30  generated by the file examination function  12 . The examination result file  30  incorporates information distinguishing each file into one record for all the transfer target files. Examples of information distinguishing each file can include the file names the old storage position (storage position in the transfer source file system  20 ), the file size, ACL information, digest information (hash value), and so forth. Other characteristic information such as the update date and time and the creator may also be added. Further, although an examination result file  30  that compiles a plurality of files transferred in a single transfer operation is generated in this embodiment, the present invention is not limited to such an examination result file  30 . An examination result file may be generated for each of the files transferred.  
       FIG. 4  is a schematic view of a case where a file is transferred from the transfer source file server  10  to the transfer destination file server  40 , in which  FIG. 4 ( a ) shows an image of the file management of the transfer source file server  10 ,  FIG. 4 ( b )&#39;shows an image of the file management of the transfer destination file server  40 , and  FIG. 4 ( c ) shows an image of the directory structure as seen from the client side.  
      A transfer target directory ‘/folder_c’ is placed under ‘/share’ and has three text files ‘d3.txt’, ‘d4.txt’, and ‘d5.txt’. When the directory ‘/folder_c’ is transferred to the transfer destination file server  40 , this directory is stored in a directory ‘/current’ that is formed below ‘/share’, for example, as shown in  FIG. 4 ( b ). Because the respective OS of the transfer source file server  10  and the transfer destination file server  40  are different, the directory structure is different in each case. However, as shown in  FIG. 4 ( c ), there is no change before or after the transfer from the perspective of the client. This is because the transfer destination file server  40  supplies file sharing services to the client by concealing the difference in the actual directory structure. As shown in  FIG. 4 , even when there is no change before or after the transfer of the directory structure from the client side, the actual storage position (file path) changes. Accordingly, when ACL information is reset afterwards, a search must be performed by determining specified files within a directory structure that is different from that before the transfer. This embodiment provides one solution to this problem.  
       FIG. 5  is a flowchart showing an outline of the overall operation of the file sharing system. A user such as an administrator designates (S 1 ) transfer target files (including directories). The user is also able to select transfer targets in file units or select transfer targets in directory units. Alternatively, it is possible to select both files and directories.  
      When transfer target files are selected, the file examination function  12  of the transfer source file server  10  acquires characteristic information for all the selected files and generates the examination result file  30  (S 2 ). Next, when a selected file  21  is transferred to the transfer destination file server  40 , this file (or file group) is stored in the transfer destination file system  50  (S 3 ). Then, the examination result file  30  generated in S 2  is also transferred to the transfer destination file server  40  (S 5 ) and stored in the memory of the transfer destination file server  40 , for example (S 6 ). The ACL information setting function  42  of the transfer destination file server  40  specifies the transferred file from among files stored in the file system  50  by referencing the examination result file  30  and then resets the ACL information (S 7 ).  
      Further, in  FIG. 5 , for the sake of expediency in the description, the transfer target file and examination result file  30  are shown as being transferred separately but both these files may be transferred at the same time. Further, the selected file and examination result file  30  can be transferred by means of a manual drag &amp; drop operation by the user, for example. More specifically, the transfer target file is selected by using a selection device such as a mouse and then transferred to the network-mounted transfer destination file server  40  by means of a graphical operation. Because of this operation, the selected file is transferred from the transfer source file server  10  to the transfer destination file server  40  via the communication network CN. Similarly to the selected file, the examination result file  30  can also be transferred to the transfer destination file server,  40  by means of a drag &amp; drop operation. Otherwise, the selected file and examination result file  30  may be transferred by means of a command line interface by using a transfer command. Further, the selected transfer target file and the examination result file  30  describing the file characteristics can each be transferred to the transfer destination file server  40  by means of different methods.  
      Furthermore, the hash value of the examination result file itself is computed by using the hash value computation function  122  or another hash value computation function (not shown) of the transfer source file server  10  on the examination result file created by the transfer source file server  10 , and this hash value is managed and stored by the transfer source file server  10 . This hash value is then transferred in accordance with a request from the transfer destination file server  40 . When the transfer destination file server  40  compares the hash value retrieved from the transferred examination result file and the hash value transferred from the transfer source file server  10  by using the hash value computation function  423  or another hash value computation function (not shown), any deterioration of the examination result file itself is identifiable and an embodiment in which more consideration is directed toward security can be achieved. Naturally, as long as the identity of the examination result file is verifiable information a value other than a hash value can be used. In the cased of this embodiment, in addition to the hash value (or information making it possible to verify the file content identity) being used in order to specify the transfer target file, the hash value may be used in the judgment of whether the transfer of the examination result file itself is reliable.  
       FIG. 6  is a flowchart showing examination result file generation processing that is executed by the file examination function  12  of the transfer source file server  10 . Although  FIG. 6  illustrates a case where a certain single directory is transferred, in a case where a plurality of directories is transferred at the same time, the processing shown in  FIG. 6  may be repeated a number of times equal to the number of directories. In addition, in a case where only one or a plurality of files in the directory is transferred, the examination result file  30  may be generated for selected files alone.  
      First, the name of the transfer target directory selected by the user is acquired (S 11 ). Then, the following processing is repeatedly executed for each file contained in the selected directory. That is, file meta-information (file name, file size, and so forth) is acquired (S 12 ). Then ACL information for the file is acquired (S 13 ), and the hash function of this file is calculated (S 14 ). When characteristic information is thus obtained for one file, this characteristic information is output to the examination result file  30  as a single record (S 15 ). Until the examination is complete for all the files contained in the selected directory (S 16 ), the above-mentioned examination processing is repeated while moving the file pointer that designates the examination target (S 17 ). The processing is terminated when characteristic information has been acquired for all the files and examination is complete (S 16 : YES).  
      Further, as mentioned above, when the hash value of the examination result file is provided in accordance with the request from the transfer destination file server  40 , the hash value of the examination result file is managed by being associated with the examination result file  30 .  
      Next,  FIG. 7  shows ACL information resetting processing that is executed by the ACL information setting function  42  of the transfer destination file server  40 . First, the name of the transferred directory is acquired (S 21 ). The directory name can be acquired by way of a manual operation (drag &amp; copy). by the user, for example. Next, the examination result file  30  generated by the transfer source file server  10  is read (S 22 ) Here, if required, the hash value of the examination result file  30  thus read is calculated, the hash value corresponding with the examination result file  30  is obtained by accessing the transfer source file server  10 , and the hash value obtained through calculation and the hash value obtained from the transfer source file server  10  are compared. As a result, when the hash values do not match, the processing maybe interrupted, and when the hash values match, the processing may move on to step  23 .  
      Next, transfer destination directory information is acquired (S 23 ). For example, where Samba is concerned, directories disclosed by Samba are made explicit in an smb.conf file. Then, the search range is set on the basis of transfer target directory information and information on the disclosed transfer destination directories (S 24 ). In other words, rather than the whole of the transfer destination file system  50  being set as the search range, a search range is set within at least the disclosed directories of the file system  50 . A futile search can thus be prevented beforehand.  
      Next, one record&#39;s worth of data is acquired from the examination result file  30  (S 25 ), and, based on general characteristic information such as the file name, file size, and so forth, a search is performed for files within the set search range (S 26 ). When not even a single file is retrieved as a result of this first stage file search (S 27 : NO), this represents a case where the file selected as the transfer target was not transferred for whatever reason, and hence error processing is performed (S 28 ). Examples of error processing include outputting the name of the file, and so forth, for which the search failed to an error log file, for example. After the error processing, processing moves to the next file (S 36 ).  
      When one or more files are retrieved because of a first stage file search under the file name, file size, and so forth (S 27 : YES), it is judged whether a plurality of the retrieved file exists (S 29 ). When only one file has been retrieved (S 29 : NO), this unique retrieved file is judged as being an object file and the ACL information set in the source file is reset (S 30 ). That is, the same (or substantially the same) access right as the access control set prior to the transfer is set. Further, when the respective formats of the ACL information of the transfer source and the ACL information of the transfer destination are different, ACL information may be suitably altered in accordance with preset conversion rules, for example.  
      When a plurality of files with the same name and size have been retrieved (S 29 : YES), a hash value is calculated for each of the retrieved files (S 31 ). Further, it is judged whether only one file with the same hash value as the hash value of the transfer target source file is present (conversely, whether a plurality of files with the same hash value exists) (S 32 ). When only one file with the same hash value exists (S 32 : YES), the file with the same hash value is judged as being an object file and the ACL information set in the source file is set (S 33 ).  
      When a plurality of files with the same hash value have been retrieved (S 32 : NO), a single object file is specified (S 34 ) by comparing the source file path information indicated by the examination result file  30  and the file path information of the retrieved file. This file path-based file specification will be described subsequently.  
      The above processing is repeated (S 36 ) while transferring search target files until all the transfer target files have been specified and ACL information has been set (S 35 ). The processing is terminated when all the transfer target files have been specified and ACL information has been set (S 35 : YES) Further, when the processing ends after passing via step  35  (normal completion), management may be carried out by the transfer destination file server  40  by setting a transfer complete flag in an environment settings file (not shown) of the file system  50 . In the case of this embodiment, the operation of the transfer destination file server  40  can be afforded scope in the event of a file access request (read/write). For example, when services corresponding with the file access request (read/write) are provided by the OS or similar  41 , it is judged whether the file access request is from the administrator of the transfer destination file server  40 , file system  50 , and so forth, or from a user other than the administrator. When a transfer complete flag is not set in the environment settings file, only the administrator has file access permissions, users other than the administrator being denied file access (error return or the like). When a transfer complete flag is set, it is possible to further preserve the normal operation of the file system  50  by granting file access to the administrator and users other than the administrator.  
      Therefore, in this embodiment, files are specified by means of a three-stage search. The first stage search is conducted by using general characteristic information (file name, file size, and so forth) listed in the examination result file  30 . The first stage search does not require special processing and selection can be performed rapidly. When specification is not possible by means of the first stage search, a second stage search using a hash value is conducted. Although processing is required for the hash value computation, a file can be specified on the basis of the file content identity. In addition, when a file cannot be specified by means of a hash value, a file is specified in the third stage search by comparing the file path information before and after the transfer. Therefore, the constitution of this embodiment is such that search methods of a plurality of types can be used and the search method gradually becomes advanced.  
      Let us now turn to the flowchart in  FIG. 8 .  FIG. 8  shows the details of S 34  in  FIG. 7 . This processing specifies a file from the similarity between file path information. (hereinafter abbreviated to ‘file path’) before and after the transfer. First, a character string number C, which is a judgment value for judging that the file path is similar, is set (S 41 ). When two compared file paths match each other up to or beyond the character string number C, it is judged that the two files are the same. The character string number C used to judge this match can also be set manually by the user or a preset value can be used. Alternatively, the value of the character string number C may be suitably adjusted in accordance with the nature of the transfer target files (the total number of transferred files, the directory depth, and so forth, for example).  
      Next, the range (size) for comparing two file paths is set. The pre-transfer file path (old file path) length and the length of the post-transfer file path (new file path) are compared (S 42 ). When the old file path is longer than the new file path (S 42 : YES), the size of the examination path is matched to that of the size of the shorter new file path (S 43 ). Conversely, when the new file path is longer than the old file path (S 42 : NO), the size of the examination path is matched to the shorter old file path (S 44 ). The similarity judgment described below is performed one character at a time a number of times equivalent to the path size thus determined.  
      Character acquisition pointers for acquiring characters for a comparison are set at the end of each new and old file path respectively (S 45 ). Instead of performing the comparison by means of extraction one character at a time from the start of the file path, the comparison is performed by means of extraction one character at a time from the end of the file path. The upper structure of the file path possesses properties that are dependent on each system. On the one hand, the comparison is performed starting from the end of the file path based on the premise that the lower structure of the file path possesses properties that are dependent on the user creating or using the file. If, conversely, the user-dependent part is located in the upper structure of the file path and the system-dependent part is located in the lower structure of the file path, the comparison may be performed by acquiring one character at a time from the start of the file path. Further, although a case where file paths are compared one character at a time is illustrated in this embodiment, the embodiment is not limited to such comparison. File paths could also be compared in word units, for example.  
      After character acquisition pointers have been set at the end of the file paths, judgment counters for counting the number of times characters taken from the respective file paths match is reset (S 46 ). Then one character is taken from the end of the new file path (S 47 ), and one character is taken from the end of the old file path (S 48 ). Further, subsequently extracted characters from each file path are compared and a judgment of whether the two characters match is made (S 49 ). When the two characters match (S 49 : YES), the judgment counter is incremented (S 50 ). When the two characters do not match (S 49 : NO), S 50  is skipped without incrementing the judgment counter.  
      Next, a judgment of whether all the characters have been examined is made with respect to paths in proportion to the examination size set in S 43  or S 44  (S 50 ). When not all the characters have been compared (S 50 : NO), the character acquisition pointers are shifted to the next character (shifted from the end of the file paths by one character in the direction of the start of the path), and the processing of S 47  to S 50  is repeated (S 52 ). When examination of the character string of each file path has been completed in an amount proportional to the examination size (S 51 : YES), the count value of the judgment counter and the character string number C set in S 41  are compared (S 53 ). When the judgment counter count value is equal to or more than the matching judgment character string number C (S 53 : YES), it is judged that the examined files match each other and ACL information is then set in specified files in the transfer destination file system  50  (S 54 ). When the judgment counter count value is less than the character string number C (S 53 : NO), the two files are judged as being different, and the ACL information is not set. The file path similarity judgment processing above is executed for all the files with the same hash value (S 55 ). The processing is terminated when the judgment with respect to all the files with the same hash value is complete (S 55 : YES). Further, when a plurality of files for which there is a similarity at a level equal to or more than the character string number C exists, files with a larger judgment counter count value may be specified as being object files or may be entrusted to the administrator&#39;s judgment.  
       FIG. 9  is a schematic view of a case where a plurality of files with the same hash value exists in the transfer destination file system  50 . Here, the transfer target file is ‘d3.txt’ of ‘/folder_c’, as shown in  FIG. 4 ( a ). The old file path in the transfer source is then ‘/share/folder_c/d3.txt’. As, shown in  FIG. 9 , ‘d3.txt’ is present in two places in the transfer destination file system  50 . The two file&#39;s ‘d3.txt’. have the same content and the same hash value. Further, general attributes other than the hash value. (such as the file name, file size, and update date and time) are also the same.  
      One file path of this file is ‘/share/current/folder_x/d3.txt’. Another file path of this file is ‘/share/current/folder_c/d3.txt’. When these two file paths are compared one character at a time in a direction from the end toward the start of the path, there is clearly a large number of characters for which.  
      ‘/share/current/folder_c/d3.txt’ matches ‘/share/folder_c/d3.txt’. Therefore, the file ‘/share/current/folder_c/d3.txt’ is specified as the transferred file and ACL information with the same content (or substantially the same content) as the ACL information set in ‘/share/folder_c/d3.txt’ is set.  
      According to the embodiment with this constitution, information distinguishing the transfer target file is examined by the transfer source file server  10 , and the transfer destination file server  40  specifies the file on the basis of the examination result file  30  and resets the ACL information. Hence, even when files are transferred between different OS (different file sharing protocols), attribute information (ACL information) can be automatically set. Accordingly, files can be transferred smoothly and rapidly, irrespective of the procedure for specifying the files by means of a manual search.  
      In other words, according to this embodiment, data file body transfers and attribute information transfers (between file servers with different hierarchical storage structures) are separated and attribute information can be set after the transfer of the data file bodies.  
      Further, a search is first performed on the basis of general characteristic information (or simple characteristic information) such as the file name, file size, and so forth, and only in cases where files cannot be specified by this search is a hash value calculated and compared with the hash value of the source file. The load of the hash value computation can therefore be reduced and the processing speed of the file specification processing can be raised.  
      In addition, in cases where a file cannot be specified by means of a hash value comparison, a file is specified by comparing the file path similarities before and after the transfer Therefore, the file can be specified even when a plurality of files with the same content exists in the transfer destination file system  50 .  
      Moreover, in this embodiment, three types of search method are executed in stages, namely a first-stage file search based on file name, file size, and so forth, a second-stage file search based on hash values, and a third-stage file search based on file path similarity. Further, a search method involving advanced processing is executed after a search method involving simple processing. The load of the search processing can thus be reduced by efficiently using the computer resources of the transfer destination file server  40 .  
      In addition, when the file path similarity is judged, examination is performed starting from the end of the file path that readily depends on the user, and hence, in comparison with a case where examination is performed starting from the start of the file path, files can be specified sooner.  
     Second Embodiment  
      Next, the second embodiment of the present invention will be described with reference to  FIG. 10 . The special feature of this embodiment consists in the fact that a hash value is determined for all the files retrieved by means of the file name, file size, and so forth, and then a hash value-based judgment is performed. That is, the hash value is examined even in the event of only one retrieved file.  
      S 61  to S 68  in the flowchart shown in  FIG. 10  correspond to S 21  to S 28  in  FIG. 7  and hence a description of S 61  to S 68  will be omitted here. When one or more files retrieved by means of file name, file size, and so forth, are present (S 67 : YES), the hash value is calculated irrespective of whether there is a plurality of retrieved files (S 69 ). That is, the hash value is calculated even when there is only one of this file. Further, when there is only one file with the same hash value, this file is judged as being an object file and ACL information is set (S 70 , S 71 ). When there is a plurality of files with the same hash value, a file is specified based on file path similarity (S 72 ). Further, processing is repeated with respect to all the transfer target files (S 73 , S 74 ).  
      Therefore, because a hash value is determined for all the files extracted by means of the first-stage search according to file name, file size, and so forth, a hash value-based comparison is also undertaken even when there is only one file with a common file name and so forth. A file can therefore be specified accurately and hence the reliability of the file specification increases.  
     Third Embodiment  
      Next, the third embodiment of the present invention will be described based on  FIG. 11 . The special feature of this embodiment consists in the fact that, when a search for files with the same hash value is conducted, duplicate files are displayed for the user and these duplicate files are deleted.  
      The flowchart shown in  FIG. 11  shows the processing for deleting duplicate files. This processing is executed after a file transfer from the transfer source file server  10  to the transfer destination file server  40  has been completed, for example.  
      First of all, it is judged whether a plurality of files with the same hash value have been retrieved in the file transfer processing described in conjunction with  FIG. 7  (S 81 ). When a plurality of files with the same hash value have not been retrieved, the processing is terminated. When a plurality of files with the same hash value have been retrieved (S 81 : YES), this constitutes a case where a plurality of files with duplicate content is present in the transfer destination file system  50 . The file path of each retrieved file with the same content is displayed on the monitor screen (S 82 ), and it is confirmed by the user whether, of these displayed duplicate files, files other than the files specified as a result of file path similarity may be deleted (S 83 ). When the user consents (S 84 : YES) to the deletion of unnecessary files (files for which ACL information is not ultimately set) among the duplicate files via a keyboard switch, pointing device, or the like, for example, these unnecessary duplicate files are deleted to free up the storage region (S 85 ).  
      The embodiment with this constitution comprises means (deletion step) for deleting detected duplicate files, and therefore unnecessary files among the duplicate files detected in accordance with the file transfer operation can be deleted. Compression of the storage region of the transfer destination file system  50  by worthless files can therefore be prevented and the user usage amount (QUOTA) can be suitably managed.  
     Fourth Embodiment  
      Next, a fourth embodiment of the present invention will be described with reference to  FIG. 12 . The special feature of this embodiment consists in the fact that, when a transfer target file is selected, the examination result file  30  is generated in the background, and the examination result file  30  is transmitted to the transfer destination file server  40  at the same time as the transfer target file.  
       FIG. 12  is a flowchart showing examination result file transfer processing. First, it is judged by the user whether the transfer target file has been selected (S 91 ). When the transfer target file has been selected (S 91 : YES), an instruction to generate the examination result file  30  is issued (S 92 ). Accordingly, examination result file generation processing described in conjunction with  FIG. 6  is executed. Next, it is judged whether an instruction to transfer (copy) the selected files has been issued (S 93 ). When a file transfer instruction has been issued (S 93 : YES), it is judged whether or not the examination result file  30  has been generated (S 94 ). When the generation of the examination result file  30  is in progress (S 94 : NO), the fact that the generation of the examination result file  30  is in progress is communicated to the user (S 95 ) who is put on standby. Further, when the examination result file  30  has been generated (S 94 : YES), the examination result file  30  is transmitted to the transfer destination file server  40  together with the selected file (S 96 ).  
      In the embodiment with this constitution, transfer target files and the examination result file  30  can be transferred at the same time. Therefore, forgetting to transmit the examination result file  30  to the transfer destination file server  40  can be prevented.  
      Moreover, the present invention is not limited to or by the above embodiments. A person skilled in the art is able to make a variety of additions or modifications within the scope of the present invention.