JP5295046B2 - User terminal device and method for controlling user terminal device - Google Patents

Description

  The present invention relates to a user terminal device and a control method for the user terminal device. For example, the user data is aggregated in a file server and used to form part of a thin client system that realizes prevention of loss or leakage of confidential information. The present invention relates to a user terminal device and a user terminal device control method.

  In recent years, a thin client system has been devised as a system for preventing important data stored in a file server from spreading from user terminals. The thin client system generally uses a terminal (diskless PC) that is not equipped with a non-volatile secondary storage device in the terminal, but a PC (personal computer) having a secondary storage device that controls writing. There are also systems that use as a thin client terminal.

  For example, in Patent Document 1, in a terminal having a secondary storage device, when writing from an application to the secondary storage device occurs, the secondary storage device is redirected to the main storage device (cache memory). The terminal that does not have pseudo-secondary memory is realized.

  Compared to the case of using a diskless PC, when a PC having a secondary storage device that is controlled for writing is used as a thin client terminal, there is a merit that the cost for infrastructure construction and the like can be reduced because the load on the server side is small. According to this system, in addition to preventing the important data stored in the file server from spreading, it is also possible to prevent an inappropriate OS setting change or application installation by the user.

  On the other hand, since the system of Patent Document 1 cannot store system update data such as OS patches in the secondary storage device, the system cannot be kept up-to-date. On the other hand, as a system that can store only system update data in the secondary storage device of the user terminal, a system such as Patent Document 2 has been proposed. In Patent Document 2, two writable filter devices and a write prohibition filter device are generated below the file system. Then, the file access control driver, which is a higher-level filter driver of the file system, detects write-inhibited file access and redirects it to the write-inhibited filter device. Writable files are physically reflected as writes to secondary storage as usual. This realizes storage control in units of files and folders with respect to writing to the secondary storage device.

JP 2007-172063 A JP 2008-59501 A

  However, the thin client terminal described in Patent Document 2 does not validate system update data for all applications on the OS in real time. In other words, it is possible to write update data in real time, but the update data can only be used in real time from an application that permits writing. A restart is required to enable system update data for all applications. This is because the write-protected application cannot refer to the file / folder written by the write-enabled application. Simply allocating read requests from write-protected applications to write-permitted files / folders and write requests to write-protected files / folders is difficult because of file integrity problems.

  The present invention has been made in view of such a situation. While writing system update data to the secondary storage device in real time, it is possible to transfer from all applications on the system to the secondary storage device in real time without restarting. A method for validating written update data is provided.

  In order to solve the above-described problem, the user terminal device according to the present invention determines an I / O request to the secondary storage device, and performs the I / O request when the I / O request is a write request. File access control means (file access control module) that determines whether or not data writing to the secondary storage device is permitted, and processes the read / write request and redirects the data requested to be written Write with a volume filter device to be stored in the cache memory and a shadow volume device having a function capable of newly instructing the volume filter device to read and cache data from the secondary storage device to the volume filter device Control means (write control module). The volume filter device and the shadow volume device are types of volume filters that refer to the same volume area.

  When the file access control means determines that writing to the secondary storage device is permitted for the application that has made the write request, the file access control means itself duplicates the I / O and sets the file system. To the volume filter device and the shadow volume device. The volume filter device stores the data requested for writing in the cache memory. The shadow volume device causes the volume filter device to read the area that the shadow volume device is scheduled to write in advance and store it in the cache memory. After the volume filter device has finished reading, the shadow volume device stores the write data as secondary storage. Write to the device.

  In addition, when the file access control means determines that writing to the secondary storage device is prohibited for the application that has made the write request, the file access control means itself sends the write data via the file system. The data is transferred to the volume filter device, and the volume filter device stores the data requested for writing in the cache memory.

  When the file access control means determines that the I / O request is a read request, the volume filter device reads the data requested to be read from the cache memory or the secondary storage device.

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

  According to the present invention, in the pseudo thin client terminal device that controls the writing to the secondary storage device, the system update data is reflected in the secondary storage device in real time, and the shutdown speed can be increased.

It is a figure which shows schematic structure of the thin client system by embodiment of this invention. It is a figure which shows the internal structure of the user terminal. 5 is a flowchart for explaining the operation of a file access control module 106. 10 is a flowchart for explaining an operation of a volume filter device 212 (when an application is requested). 12 is a flowchart for explaining the operation of a volume filter device 212 (when a shadow volume is requested). 10 is a flowchart for explaining the operation of a shadow volume device 213. It is a flowchart for demonstrating the operation | movement at the time of starting. 5 is a diagram illustrating a configuration example of an application control file 206. FIG.

  The present invention consolidates user data in a file server by writing control to a secondary storage device of a user terminal and writing control to an external storage medium, and realizes prevention of loss / leakage of confidential information The present invention relates to a user terminal device and a data control method that constitute a part of the system. The present invention also improves the prior application (Japanese Patent Application No. 2008-274099).

  According to the user terminal device and the data control method which constitute a part of the thin client system which is the prior application (Japanese Patent Application No. 2008-274099), the volume filter device and the shadow volume device are generated at the lower level of the file system. . Each of these two devices has a function of caching the write data transferred from the upper module in the memory. Then, the file access control module, which is a higher-level filter driver of the file system, determines the write processing for each process, and the data to be written to the secondary storage device is written to both the volume filter device and the shadow volume device. For data that is transferred and does not want to reflect the write, the write data is transferred only to the volume filter device. Then, the data cached by the shadow volume device at the time of shutdown is written to the secondary storage device. As a result, a device that performs storage control in units of files and folders with respect to writing to the secondary storage device is realized.

  However, in the above thin client terminal, data cached in the memory is collectively written to the secondary storage device at the time of shutdown, so that there is a problem that the time for system shutdown increases and usability is significantly reduced.

  In order to solve this problem, an embodiment of the present invention provides a data control method for speeding up shutdown in a pseudo thin client terminal device that controls writing to a secondary storage device.

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

<Configuration of information processing system>
FIG. 1 is a diagram showing a schematic configuration of an information processing system according to an embodiment of the present invention.
This information processing system includes a user terminal 101 and a file server 102, and each is connected via a network 103. The network 103 here can be realized using a network generally known as a local area network (LAN), a wide area network (WAN), a peer-to-peer network, or the like. The user terminal is a general PC including a CPU, a main storage device, a network device, an input / output device, and a secondary storage device, and there is no limitation on the form such as portability.

  An OS 104, an application 105 such as a document / form creation / browser, a file access control module 106, a device control module 107, a write control module 108, and a disk module 109 are installed on the user terminal 101, and a secondary storage device An application control file 110 is stored in 111. Further, although not shown in FIG. 1, the user terminal 101 includes a control unit (CPU), a memory, a network interface, an input / output device (keyboard, display, speaker, etc.) and the like.

  Although not shown in FIG. 1, the file server 102 includes a CPU, a main storage device, a network device, an input / output device, a secondary storage device, etc., and can transfer files by establishing a connection with the user terminal 101. This is a general file server that can store confidential data 112 created and edited by the application 105 on the user terminal 101.

  The user can access, use, and edit the confidential data 112 on the file server 102 by using the application 105 operating on the OS 104 of the user terminal 101.

  In the user terminal 101, the write control module 108 has a function of detecting an external storage medium such as a USB and controlling writing to the external storage medium. The external storage medium is detected by detecting the external device using the function of the OS and controlling the writing by means such as prohibiting access to the device or redirecting writing to the device onto the memory. With this function, confidential data on the file server is not stored outside from the user terminal, and data aggregation and information leakage can be prevented.

<Internal configuration of user terminal>
FIG. 2 is a diagram showing in detail the internal configuration including the OS component of the user terminal 101. The directed lines in FIG. 2 indicate programs such as applications and OS modules (hereinafter, in order to make the story easier to understand, not only application software for creating documents, but also programs for writing to the secondary storage device using OS modules, etc. This “application” includes an application for system update such as windows (registered trademark) update, for example.) I / O requested to the secondary storage device (Actually, other than Read / Write exist but are omitted).

  Also, solid lines 218 to 222 in FIG. 2 are mainly I / Os issued by an application, alternate long and short dash lines 223, 226, and 227 are I / Os issued by the file access control module 106, and dotted lines 224 and 225 are shadow volumes. This is related to I / O issued by the device 213.

  The disk module 109 is a module of the OS 104 that has a function of creating a volume device 215 that represents a volume on the secondary storage device 111.

  The file access control module 106 attaches to the file system 210 mounted on the volume device 215 and can filter the I / O to the secondary storage device 111 issued by the application 105. Has the ability to create. When the I / O to the secondary storage device 111 issued by the application 105 is a write request, the file access control module 106 determines whether the write request source application is a “write permission” application or a “write prohibition” application. Determine. Then, the file access control module 106 replicates and transmits data to both the volume filter device 212 and the shadow volume device 213 if writing is performed by the “write permission” application (solid line 219, one-dot chain line 223, FIG. 3 described later). S307, S308). On the other hand, if the application is a “write-inhibited” application, the file access control module 106 transmits data only to the volume filter device 212 (solid line 219, S306 in FIG. 3 described later).

  An example of the “write permission” application is an update program of the OS or application software. These programs are usually provided by OS or application vendors. As an example of the “write prohibition” program, there are an application program for creating / editing confidential data, and an application program for creating / editing documents / forms in general.

  As a method of distributing the write request source program, it is possible to install the application control file 206 (for example, FIG. 8 (Table 1)) in the user terminal 101.

  The application control file 206 is a list format file in which an application name 803 and a write prohibition / permission flag 804 are set. With a general OS, the execution process name and process ID can be acquired from the application name. Therefore, if this list is read, it is possible to acquire the process name and process ID of the application running on the user terminal.

  If the file access control module 106 is mounted as a file system filter driver, it is possible to acquire the request source process name and process ID when the file system filter device 205 acquires a write processing request. . By comparing the process name and process ID acquired by the above means, it is possible to determine whether the application of the write processing source is a write “permitted” application or a write “prohibited” application.

  The application control file 206 is created appropriately by the system administrator in accordance with the system policy of the user terminal and installed in advance. The application control file 206 is a file that can be updated simultaneously with the update. Further, if a general user can install an application, there is a possibility that a malicious application (for illegal purposes) may be installed. Therefore, the installation operation is preferably performed by an administrator.

  Here, the reason why the file access control module 106 writes the write from the write permission program to both the volume filter device 212 and the shadow volume device 213 will be described. That is, in this system, a Read request from an application (see solid lines 218 and 219) is transferred in the order of the file system filter device 205 → the file system 210 → the volume filter device 212. Then, finally, the data read from the secondary storage device 111 by the volume device 215 is returned to the application 105 (solid line 222 → 219 → 218), or the data cached in the memory 217 by the volume filter device 212 is returned to the application 105. (Solid line 220 → 219 → 218). Therefore, if data is written only to the shadow volume device 213, the read data becomes old data on the secondary storage device 111. Therefore, when data is written from the shadow volume 213 to the secondary storage device 111 via the volume device 215, the same data is further written to the cache memory via the volume filter device 212, and a read request from the application is sent. The latest data is returned (solid line 221 → 219 → 218). As a result, the risk of reading old data can be avoided, and the latest control data can be reflected in real time without restarting.

  Although the file access control module 106 can be realized by a file system filter, the file access control module 106 is only an example and does not limit the present invention. In addition to the method described here, a method of distributing the write I / O by changing the file path of the write destination in the write application process is also conceivable.

  The write control module 108 is attached to the volume device 215 (one-to-one correspondence), and a volume filter device 212 that can filter I / O from the application 105 to the secondary storage device 111, and a shadow volume device A function for creating two devices 213 is provided. Here, the write control module 108 proceeds as a kind of filter driver of the disk driver, but the implementation means may be other than the method described here.

  The volume filter device 212 has a function of attaching to the volume device 215 capable of writing data to the secondary storage device 111 and redirecting write data on the memory 217 to cache it. Also, it has a function of receiving a request from a shadow volume device 213 (described later) and reading and caching data in an arbitrary area on the secondary storage device (solid line 220). Here, when the application 105 performs I / O to the secondary storage device 111, “attach” is used as an example of means for acquiring the I / O. The method is not limited to attachment as long as an arbitrary program can acquire I / O data for a volume even if the method is not an attachment method.

  The shadow volume device 213 is a module that processes a write request from the file access control module 106. Note that the shadow volume device 213 recognizes the presence of the volume device 215 and can write data to the secondary storage device 111 via the volume device 215 (dashed lines 226, 227). There is no attachment to the volume device 215 of the storage device 111. By not attaching, any I / O issued by the application 105 does not reach the shadow volume device 213, and only write processing from the access control module 106 is transferred to the shadow volume 213. (Dashed line 223).

  When the shadow volume device 213 receives a write request from the access control module 106 via the file system 210 (one-dot chain line 223), the shadow volume device 213 sends a shadow volume filter to the volume filter device 212 before writing to the secondary storage device 111. The device 213 has a function of making a request to the volume filter device 212 so as to read data from the secondary storage device 111 and cache the data currently existing in the area on the secondary storage device 111 to which writing is performed (dotted line 225) (dotted line) 224). After the request is successful, the shadow volume device 213 transfers the write request to the volume device 215 (dashed line 226) and completes the writing to the secondary storage device 111 (dashed line 227). Thereafter, when a read / write request to the volume filter device 212 is made to this area, the cache data is used.

  Here, the reason why the shadow volume device 213 reads and caches data in advance from the volume filter device 212 before writing the data to the secondary storage device 111 will be described.

  In this system, the file system 210 recognizes the volume filter device 212 and the shadow volume device 213 as separate volumes. However, the volume filter device 212 and the shadow volume device 213 refer to the same volume (the volume device 215 representing the volume on the secondary storage device 111) (the solid line 222 and the alternate long and short dash line 226 in FIG. 2). This means that the access control module 106 duplicates the file I / O and reads the area through the volume filter device 212 and the secondary storage apparatus that writes through the shadow volume device 213. It means that the upper area is not isolated (the same area is managed). That is, the management area of each device is not managed as a dedicated area. The reason for managing the same area is, for example, in the system hierarchy of Windows (registered trademark), in order to access the secondary storage device 111, the same device as the volume device 215 corresponding to the C drive or the like must be used. Because it must.

  In NTFS, which is a file system adopted by Windows (registered trademark), an MFT (Master File Table) file is stored at the head of each volume. The MFT is a related database including file attributes and file records in the volume, in which information representing the file structure in the volume is stored. An MFT is a file that exists for each volume. When there is a file write or attribute change from the application, the file system updates (writes) the MFT. Since the volume filter device 212 and the shadow volume device 213 refer to the MFT area of the volume device 215 when the OS 104 is activated, the file / folder configuration is the same. However, since the file system 210 recognizes the volume filter device 212 and the shadow volume device 213 as separate volumes, different writes are generated from the file system 210 to the MFTs of the volume filter device 212 and the shadow volume device 213, respectively.

For example, assume that the MFT file is stored in the first sector to the fifth sector and the information of the file A is stored in the second sector to the third sector when the OS 104 is activated. Now, the “write permission” application newly creates and writes file B. At this time, the file information of the file B is created and written in the first sector to the second sector in the volume filter device 212, and the file information of the file B is created and written in the second sector to the third sector in the shadow volume device 213. Suppose. Here, it is assumed that the shadow volume device 213 writes data to the volume device 215 without causing the volume filter device 212 to cache the data of the second sector to the third sector. Thereafter, when the file A is read from the arbitrary application to the volume filter device 212, the file system 210 reads the MFT. However, since the volume filter device 212 has not yet written the second sector to the third sector, it is cached. However, data is read from the volume device 215. Then, the second sector to the third sector are inconsistent due to writing from the shadow volume device 213, so that the correct MFT cannot be read and the system crashes.
This is because the write contents in the MFT file are different between the volume filter device 212 and the shadow volume device 213.

  As another example, when the OS 104 is activated, the data of the file A is divided and stored in the MFT stored in the volume device 215 into the 10000th sector to the 10100th sector and the 10200th sector to the 10300th sector, and the data of the file B is 10400 Assume that there is file information that is stored in sector No. 10 to sector 10500 (the sectors 10100 to 10200 are empty sector areas). Since the volume filter device 212 and the shadow volume device 213 refer to the same MFT when the OS 104 is activated, the folder filter file configuration of the volume filter device 212 and the shadow volume device 213 is the same. Now, the shadow volume device 213 is defragmented by the file system 210, and in the shadow volume device 213, the file A is optimized to sectors 10000 to 10200, and the file B is optimized to sectors 10200 to 10300 ( Written). Here, it is assumed that the shadow volume device 213 writes data to the volume device 215 without causing the volume filter device 212 to cache data of sectors 10100 to 10300. Thereafter, when the file A is read into the volume filter device 212, the volume filter device 212 reads the 10000th sector to the 10100th sector and the 10200th sector to the 10300th sector (since this area is not yet written in the volume filter device 212). It is not cached and data is read from the volume device 215). Then, since the data of the file B is written by the shadow volume device 213 in the 10200th sector to the 10300th sector, the destroyed file A is read.

  Therefore, in order to guarantee the operation in the layer below the file system, the operation of reading data into the volume filter device in advance is essential.

  In addition, this system provides two access paths in the layer above the file system for one storage area, but finally there is only one write path that can be reflected in the secondary storage device. is there. In this system, data related to system update is written via the shadow volume device 213. Therefore, in order to write the write data via the shadow volume device 213 to the secondary storage device 111, the data in the secondary storage device 111 for the path of the volume filter device 212 is sucked in advance (dotted line 225 in FIG. 2), and the cache It is necessary to provide the volume filter device 212 as follows.

  In this way, subsequent reading and writing of the same data is performed on the cached memory 217 (S405 and S407 in FIG. 4 and S305 to S307 in FIG. 3), and the secondary storage device 111 via the volume filter device 212. The problem that the above data cannot be read is eliminated. Accordingly, an update program or the like can be newly written to the area of the secondary storage device 111 where the same data exists via the shadow volume device 213, and the writing time that has been collectively performed at the time of shutdown is not necessary.

<Operation of file access control module>
FIG. 3 is a flowchart for explaining the processing operation of the file access control module 106.
First, when the application 105 accesses the file system filter device 205, the file access control module 106 detects the access (step S301, FIG. 2 solid line 218). Then, the file access control module 106 first determines whether or not the request is a request related to writing (step S302). Note that a request related to writing refers to a request in which writing to a so-called secondary storage device occurs. For example, in addition to the write request, a request for changing the attribute of the file is also included in the write related request.

  If it is not a write-related request, the file access control module 106 transfers the request to the volume filter device 212 and ends the process (step S305, solid line 219 in FIG. 2). If the request is related to writing, the file access control module 106 reads the application control file 206 (step S303), inquires the process name of the writing process from the OS, obtains it, and compares it with the process name corresponding to the application name in the list. Then, the write flag of the matching entry is acquired, and write permission / prohibition is determined (step S304).

  When the write flag is “TRUE”, the write is “permitted”, and the file access control module 106 transfers the write-related request to the volume filter device 212 (step S307, solid line 219 in FIG. 2). Further, the file access control module 106 writes the same data to the shadow volume device 213 (step S308, FIG. 2, one-dot chain line 223), and then ends the process. Note that write processing may be performed in parallel to the volume filter device 212 and the shadow volume device 213.

  On the other hand, if the write flag is determined to be “FALSE” in step S304, the write is “prohibited” and the file access control module 106 transfers the write-related request to the volume filter device 212 (step S306, The solid line 219 in FIG. 2 ends the processing.

<Operation of write control module>
FIG. 4 is a flowchart for explaining the processing operation when the volume filter device 212 in the write control module 108 receives access from an application (solid line 219 in FIG. 2).

  When the application 105 accesses the volume filter device 212 via the file system filter device 205 (step S401, solid line 219 in FIG. 2), the volume filter device 212 determines whether the request is a request related to writing. (Step S402).

  In the case of write-related processing, the volume filter device 212 caches write data in an area secured on the memory 217 (step S405, solid line 221 in FIG. 2). In a normal PC that is not subjected to write control, this write request is transferred to the volume device and written to the secondary storage device.

  In cases other than the write-related processing (here, it is conceivable that the processing is limited to the reading processing, but other processing is also included), the volume filter device 212 is transferred from the secondary storage device 111 via the volume device 215. Data is read (step S403, solid line 222 in FIG. 2).

  Thereafter, the volume filter device 212 determines whether or not the data is cached in the memory 217 (step S404), and if there is no cache, returns the read data to the application as it is (step S406). If cache data exists, the volume filter device 212 overwrites the cache with the read data and returns it to the application (step S407).

FIG. 5 is an operation flow when the volume filter device 212 in the write control module 108 receives a cache command from the shadow volume device 213.
This flow occurs when the shadow volume device 213 receives a write request from the access control module and a write to the secondary storage device 111 occurs (dotted line 224 in FIG. 2, step S602 in FIG. 6 described later).

  First, the volume filter device 212 detects a cache command from the shadow volume device 213 (step S501). Note that the notification from the shadow volume is notified by a method different from the access from the application. When receiving the command, the volume filter device 212 transmits a read process to the volume device 215 and reads data in the secondary storage device 111 (step S502, solid line 222 in FIG. 2). Next, the volume filter device 212 checks whether the read data is already cached in the memory 217 (step S503). If not cached, the volume filter device 212 caches the read data (step S504, solid line 221 in FIG. 2). In the case of already cached data, the cached data is used as it is, and the read data is discarded.

FIG. 6 is a flowchart for explaining the processing operation of the shadow volume device 213 in the write control module 108.
When access to the shadow volume device 213 by the access control module 106 is detected (step S601, FIG. 2, one-dot chain line 223), the shadow volume filter device 213 acquires information on the write area on the secondary storage device 111 (step S602). ). Next, the volume filter device 212 reads and caches data currently stored in the area of the secondary storage device 111 to which the shadow volume device 213 writes (dotted line 225 in FIG. 2). (Step S603, FIG. 2 dotted line 224). Here, the data cached by the volume filter device 212 is handled in the same way as the data cached when a write request to the volume filter device is made. After the volume filter device 212 has been successfully cached, the shadow volume device 213 requests the volume device 215 to write to the secondary storage device 111 requested by the access control module 106 (step S604, FIG. 2 one-dot chain line 226). ). The volume device 215 completes the data writing to the secondary storage device 111 (step S605, FIG. 2, one-dot chain line 227).

<Operation at user terminal startup>
FIG. 7 is a flowchart for explaining the processing operation when the user terminal 101 is activated.
First, when the user activates the user terminal 101, the OS 104 is activated (step S701), and the OS 104 loads each module into the system (step S702).

  Next, the write control module 108 creates a volume filter device 212 and a shadow volume device 213 (step S703). At the time of creation, the volume filter device 212 and the shadow volume device 213 hold the volume device 215 representing the volume in the secondary storage device 111, so that the volume can be read / written. Further, the volume filter device 212 attaches (associates) with the volume device 215 (step S704). With this attachment, the volume filter device 212 can acquire processing when the application 105 accesses the secondary storage device 111.

  Subsequently, the OS 104 mounts the file system 210 such as NTFS or FAT on the volume device 215 (step S705).

  Finally, the file access control module 106 creates a file system filter device 205 and attaches it to the file system 210. As a result, the file system filter device 205 can acquire file processing for the volume, and file processing can be distributed.

<Summary>
In this embodiment, a volume filter device and a shadow volume device are introduced as a write control module, and the cache route between control data (system update data) that can be written to the secondary storage device and confidential data that is write-protected is changed. ing. As a result, only the system update data of the user terminal can be stored in the secondary storage device of the user terminal, and no confidential data remains in the user terminal after the user terminal is shut down. It becomes possible.

  Further, the data on the secondary storage device 111 written by the shadow volume device 213 is cached in the volume filter device 212 before writing, so that the latest update data can be stored in the secondary storage device without destroying the read data of the volume filter device. Can be written to.

  Further, by writing the write permission file to the memory 217 and the secondary storage device 111 in real time, writing via the shadow volume device 213 can be realized in real time, and system update data can be reflected in the system in real time. . That is, it is possible to reduce the write processing time to the secondary storage device 111 that takes time for system shutdown and improve usability.

  Further, the write-protected file is written to the memory 217 and is not written to the secondary storage device 111. Thereby, it is possible to prevent confidential data from being stored in the secondary storage device.

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

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

  Also, by distributing the program code of the software that realizes the functions of the embodiment via a network, the program code is stored in a storage means such as a hard disk or memory of a system or apparatus, or a storage medium such as a CD-RW or CD-R And the computer of the system or apparatus (or CPU or MPU) may read and execute the program code stored in the storage means or the storage medium when used.

DESCRIPTION OF SYMBOLS 101 ... User terminal, 102 ... File server, 103 ... Network, 104 ... OS, 105 ... Application, 106 ... File access control module, 107 ... Device control module, 108 ... Write control module, 109 ... Disk module, 110 ... Application Control file, 111 ... secondary storage, 112 ... confidential data

Claims (6)

A user terminal device comprising a secondary storage device and a cache memory, which forms part of a thin client system,
When an I / O request to the secondary storage device is determined and the I / O request is a write request, data writing to the secondary storage device is permitted for the application that has made the I / O request File access control means for determining whether or not
First write control means for redirecting and storing the requested data in a cache memory;
Second write control means for making a write request to the secondary storage device for data determined to be allowed to be written;
With
The second write control means stores the data in the area in the secondary storage device targeted by the write request in the cache memory before making the write request to the secondary storage device. Notifying the first write control means,
The first write control unit receives the notification, reads data from an area in the secondary storage device, and stores the data in the cache memory.   2. The user terminal device according to claim 1, wherein the first write control unit and the second write control unit manage the same area in the secondary storage device. When the file access control means determines that writing by the application is permitted, the file access control means transfers a write request to the first write control means and the second write control means,
The first write control means redirects the data requested to be written and stores it in a cache memory,
The second write control unit executes the write request to the secondary storage device in real time after the data of the area in the secondary storage device is stored in the cache memory. The user terminal device according to 1. When the file access control means determines that writing by the application is prohibited, it transfers a write-related request only to the first write control means,
2. The user terminal device according to claim 1, wherein the first write control means redirects the data requested to be written and stores it in a cache memory. A control method for a user terminal device comprising a secondary storage device and a cache memory, which forms part of a thin client system,
When the file access control unit determines an I / O request for the secondary storage device and the I / O request is a write request, the secondary storage device Determining whether data writing to the device is permitted;
A first write control means redirecting and storing the data requested to be written in a cache memory;
When the second write control means determines that the file access control means is allowed to write to the secondary storage device, the data in the area in the secondary storage device targeted by the write request is stored. Notifying the first write control means to store in the cache memory;
The first write control means receives the notification, reads data from an area in the secondary storage device and stores it in the cache memory;
A control method for a user terminal device, comprising: Further, the second write control unit makes a write request to the secondary storage device for data determined to be allowed to be written for the application;
The method for controlling a user terminal device according to claim 5, further comprising:

Images