JP2002123412A - File access control system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To access a file on the side of server from the side of client even without using the NFS of UNIX(R). SOLUTION: When the request of file access to a target file 23 is received from a client device 1, in a server device 2, a slave process 22 corresponding to this file request is prepared, the prepared slave process 22 accesses the target file 23 and the access result is transmitted to the client device 1 of an access source.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a file access control system for accessing a file on a server side without using NFS in a server / client system using UNIX.

[0002]

2. Description of the Related Art Conventionally, in a server / client system using UNIX as basic software, to access a file on a server from a client, a UNIX network file system (N
network File System, "NF
S ”).

[0003] In this file access by NFS,
By using the automount function, file access on the server side becomes possible as if accessing a file on the own machine.

[0004]

SUMMARY OF THE INVENTION However, UNI
In the conventional system in which the client accesses the server file using the NFS of X, if the server goes down while the client is accessing the file on the server, the client is locked, and the server is recovered and started until the server is restored. There was a problem that operation on the client side became impossible.

[0005] In view of the above circumstances, the present invention is based on UNIX NF.
It is an object of the present invention to provide a file access control system which can access a file on a server side from a client side without using S and can solve the conventional problem.

[0006]

In order to achieve the above object, according to the present invention, in a file access control system for accessing a file on a server from a client, a file access request is received on the server. At this time, it is provided that there are means for creating a child process corresponding to the file request, and means for accessing a target file in a unit of the created child process and transmitting an access result to a client of the access source. Features.

According to a second aspect of the present invention, in the file access control system according to the first aspect, the child process determines whether a target file is being accessed, and if so, waits for a predetermined time, It is characterized by executing an exclusive process for accessing again.

According to a third aspect of the present invention, in the file access control system according to the first aspect, if a predetermined process is not executed even after a predetermined time elapses during a file access process, the child process is notified. It has the function of transmitting to the client side.

With the above configuration, according to the present invention, when a server receives a file access request, the server creates a child process corresponding to the file request, accesses a target file in units of the created child process, and The access result is transmitted to the access source client. As a result, the client can access the server-side file without using UNIX NFS, and can also access the child process and perform exclusive processing.

Further, since the result of the file access is transmitted from the child process to the access source client,
On the client side, a locked state on the client side due to a server down during access can be avoided.

In addition, if a predetermined process is not executed even if a predetermined time elapses during the file access process, a function to transmit the fact to the client is provided, so that the client can process even if the server goes down. Thus, the occurrence of the locked state can be prevented beforehand.

[0012]

FIG. 1 is a block diagram showing a configuration of an embodiment of a file access control system according to the present invention.

In the file access control system shown in FIG. 1, a plurality of client apparatuses 1 and server apparatuses 2 are connected via a communication line 3.

The client device 1 includes a control device 4 having a process (file access process: FAP) for executing a file input / output process of the server device 2;
And a buffer memory 5. The control device 4 includes an API unit 41 and a communication M / W unit 42 in terms of its functions. The API unit 41 executes processing for analyzing information for accessing a target file. Communication M /
The W unit 42 has a function of performing communication between the client device 1 and the server device 2. The buffer memory 5 secures an area when accessing a file of the server device 2 and is used to store the accessed data.

On the other hand, the server device 2 has a file access process daemon (FA) which is a parent process due to its function.
PD) 21, a child process 22 generated by using the FAPD 21 as a parent process, and a target file 23 to be accessed. Communication M /
The W unit 24 has a communication M / W unit 25 in the child process 22. In the figure, reference numeral 26 denotes a lock file created at the time of file access.

Next, the processing procedure of the file access control system of the present embodiment will be systematically described with reference to the flowcharts of FIGS.

<Processing in FAPD (File Access Process Daemon)> FIG. 2 is a flowchart showing a processing procedure in the file access process daemon 21 which is a parent process of the server device 2.

As shown in FIG. 2, the FAPD 21 waits for a client connection request (step S).
1) When there is a normal connection request (step S2), the data (header) is received (step S3). If the header has been successfully received (step S4YES), a child process 22 is created (step S5). In this way, by generating a child process and passing the process to the child process 22, the parent process 21 can concentrate on the processing of the request from the client, so that the delay time for request waiting can be eliminated.

In the next process, it is determined whether the process is a parent or a child. If the process is a parent process (step S6 YES), it is next determined whether or not a child process has been created normally.
If the child process generation is not normal, an error message is output (steps S7 YES, S8), and the process returns to step S3. When the child process 22 is normally generated, the child process 22 executes a received message process as shown in FIG. 3 (step S6NO, step S9). In the received message processing, an IO process for the target file 23 is executed as described later. The result of the I / O is transmitted to the client device 1 (Step S10). If the transmission is normal, a normal end process (indicated by “exit (0)”) is executed (step S11YES). If the transmission has not been performed normally, abnormal termination processing (indicated by "exit (-1)") is executed (step S11NO).

If it is determined in step S2 that the connection request from the client device 1 is not normal, abnormal termination processing is executed. If the data reception from the client device 1 is abnormal (step S4N
O), release the connection and receive the data again (steps S12, ST3).

<Received Message Processing> FIG. 3 is a flowchart showing received message processing executed by the child process 22 of the server device 2.

In the received message processing, first, it is determined whether or not the designated target file is being accessed (step S21). That is, when accessing the target file, a lock file is created by the child process, and it is determined whether or not the target file is being accessed based on the presence or absence of the lock file. If the file is being accessed (step S21 YES), the file is accessed again after a preset time (for example, one second) (step S22). Thus, the other client device 1
If the same file is being accessed from now on, exclusive processing can be performed correctly by executing processing that waits for one second.

If the file is not being accessed, then
It is determined whether the request content of the client device 1 is a file deletion or a request other than the file deletion (step S2).
3). If it is a file deletion request, the file is deleted (step S24), and after the reply data is created,
The process returns to step S21 again (step S25).

On the other hand, if the request content of the client device 1 is other than file deletion (step S23 YES), it is next determined whether or not to read a file (step S2).
6).

If it is not a file read request, it is next determined whether or not it is a file write request (step S2).
7). In this case, if it is not a file write request (NO in step S27), a parameter error is set as a status, and the process returns to step S21 again (step S21).
28). If it is a file write request (step S2
(7YES) Then, it is determined whether or not the write open is normal (step S29). If abnormal, a file open error is set as a status, and the process returns to the file 21 (step S30). If the write open is normal but the writing was not performed normally (step S31), a write error is set as the status, and the process returns to step S21 (step S32).
If the writing has been performed normally, return data (status, sub-status, writeable size, etc.) is created, and the process returns to step S21 (step S3).
3).

On the other hand, in the process in step S26, if the request is a file read request, it is next determined whether or not the read open is normal (step S3).
4). If the read open is abnormal, a file open error is set as the status, and then the file 2
It returns to 1 (step S35). If the read open is normal but the read is not performed normally (NO in step S36), a read error is set as the status, and the process returns to step S21 (step S36).
32). If the reading has been performed normally, return data (status, substatus, readable size, total size of the file, etc.) is created, and the process returns to step S21 (step S33). Note that an error at the time of seeking is regarded as a read error. The status 1 in the figure is a status in which the file cannot be written originally, the status 3
Indicates that there is no file originally, and status 4 indicates that the file exists but cannot be read or written.

<Read Process in Client Device 1> FIG. 4 is a flowchart showing a read process in the control device 41 of the client device 1.

First, it is determined whether or not the logical server name of the server device performing the communication is another host. If the logical server name is the own host (step S41 NO), the received message processing is executed (step S42). Is determined as normal or not, and respective parameters are set as abnormal or normal (steps S43, S44 and S45).

If the server device for communication is another host (step S41 YES), a connection request to the server device is executed (step S46). If the connection is not made normally, error processing is executed (step S
48), and the process returns to step S41. If reception has been performed normally (step S47 YES), a transmission message header is created, a transmission message is created, and data is transmitted (steps S49 and S50).

Next, it is determined whether or not the transmission is normally performed. If the transmission is not normal, an error process is performed (steps S51 and S52), and the process returns to step S41. If the transmission is normally performed, a data reception process is executed (step S53). If the data reception is not normal, an error process is performed (steps S54 and S54).
55), and returns to step S41. If the data reception is normal, it is determined whether the received message status is normal,
If abnormal, an abnormal parameter is set. If normal, a normal parameter is set, and then the connection is released (steps S56 to S59).

<Writing Process in Client Device 1> FIG. 5 is a flowchart showing a writing process in the control device 41 of the client device 1.

First, it is determined whether or not the logical server name of the server device performing the communication is another host. If the host is the own host (NO in step S61), the received message processing is executed (step S62). Is determined as normal or not, and parameters are set as abnormal or normal (steps S63, S64 and S65).

If the server device that performs communication is another host (step S61 YES), a connection request to the server device is executed (step S66). If the connection is not made normally, error processing is executed (step S
68), and return to step S61. If reception has been normally performed (step S67YES), a transmission message header is created, a transmission message is created, and data is transmitted (steps S69 and S70).

Next, it is determined whether or not the transmission is normally performed. If the transmission is not normal, an error process is performed (steps S71 and S72), and the process returns to step S61. If the transmission is normally performed, a data reception process is executed (step S73). If the data reception is not normal, an error process is performed (steps S74 and S74).
75), and returns to step S61. If the data reception is normal, it is determined whether the received message status is normal,
If abnormal, an abnormal parameter is set. If normal, a normal parameter is set, and then the connection is released (steps S76 to S79).

<Unlinking Process in Client Device 1> FIG. 6 is a flowchart showing the unlinking process in the control device 41 of the client device 1.

First, it is determined whether or not the logical server name of the server device that performs communication is another host. If it is the host (NO at step S81), the received message processing is executed (step S82). Is determined as normal or not, and parameters are set as abnormal or normal (steps S83, S84 and S85).

If the server device that performs communication is another host (step S81 YES), a connection request to the server device is executed (step S86). If the connection is not made normally, error processing is executed (step S
88), and returns to step S81. If the reception has been performed normally (step S87 YES), a transmission message header is created, a transmission message is created, and the data is transmitted (steps S89 and S90).

Next, it is determined whether or not the transmission has been normally performed. If the transmission is not normal, an error process is performed (step S92), and the process returns to step S81. If the transmission is normally performed, a data reception process is executed (step S93). If the data reception is not normal, an error process is performed (steps S94 and S9).
5) Return to step S81. If the data reception is normal, it is determined whether the received message status is normal or not. If abnormal, an abnormal parameter is set. If normal, the normal parameter is set and the connection is released. (Steps S96 to S99).

As described above, according to the present embodiment, even when a plurality of client apparatuses 1 access the same file of the server apparatus 2, the exclusive processing can be appropriately performed.

Also, because of the communication function, even when the server device 2 goes down, a response is returned after a certain period of time. Therefore, even if the server device 2 goes down, the processing of the client device 1 becomes possible, and the locked state is obtained. Can be prevented from occurring. In addition, by having a communication function, it is possible to access a plurality of server devices.

Also, since it has a function of determining whether it is another server or its own host, I / O of files on its own host / other server becomes possible.

The file access process daemon 21 of the server device 2 performs a fork and leaves the process to the child process 22, so that the request from the client device 1 can be immediately received and the request waiting time can be reduced. be able to.

[0043]

As described above, according to the present invention, when a server receives a file access request, a child process corresponding to the file request is created, and a target file is created for each created child process. And sends the access result to the access source. This allows clients to access server-side files without using UNIX NFS,
Also, it is possible to access each child process and perform exclusive processing.

Further, since the result of the file access is transmitted from the child process to the access source client,
On the client side, a locked state on the client side due to a server down during access can be avoided.

Further, if a predetermined process is not executed even if a predetermined time elapses during the file access process, a function to transmit the fact to the client side is provided. Therefore, even if the server goes down, the client process can be performed. Thus, the occurrence of the locked state can be prevented beforehand.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an embodiment of a file access control system according to the present invention.

FIG. 2 is a flowchart showing a processing procedure in a file access process daemon which is a parent process of the server device.

FIG. 3 is a flowchart showing received message processing executed in a child process of the server device.

FIG. 4 is a flowchart illustrating a reading process in a control device of the client device.

FIG. 5 is a flowchart illustrating a writing process in a control device of the client device.

FIG. 6 is a flowchart illustrating an unlink process in the control device of the client device.

[Explanation of symbols]

Reference Signs List 1 client device 2 server device 3 communication line 4 control device 5 buffer memory 21 file access process daemon (parent process) 22 file access process (child process) 23 target file 24, 25, 42 communication M / W unit 26 lock file 41 API Department

Claims (3)

[Claims] In a file access control system for accessing a file on a server from a client, a means for creating a child process corresponding to the file request when the server receives a file access request, Means for accessing a target file on a child process basis and transmitting the access result to an access source client; and a file access control system. 2. The file access control system according to claim 1, wherein the child process determines whether the target file is being accessed, and if so, waits for a predetermined time and then accesses again. A file access control system. 3. The file access control system according to claim 1, wherein in the child process, if a predetermined process is not executed even after a predetermined time elapses during the file access process, the fact is transmitted to the client side. A file access control system having a function.