An information processing apparatus includes a detection unit configured to detect a damaged file from files stored in a cache area, a determination unit configured to determine whether the damaged file detected by the detection unit is restorable, a restoration unit configured to, if the determination unit determines that the damaged file is restorable, delete every restorable file in the cache area including the damaged file and restore the deleted file in the cache area, and an initialization unit configured to, if the determination unit determines that the damaged file is not restorable, delete every file in the cache area and initialize the cache area.

DESCRIPTION OF THE EMBODIMENTS

Various exemplary embodiments, features, and aspects will be described in detail below with reference to the drawings.

FIG. 1is a diagram illustrating an example of a hardware configuration of a damaged file handling device according to an exemplary embodiment.

The hardware configuration of the damaged file handling device includes a central processing unit (CPU)101, an input device102, a storage device103, and a display device104. Here, the damaged file handling device is an example of an information processing apparatus.

The CPU101executes a program stored in the storage device103to realize the functions (software configuration) of the damaged file handling device and the processing of flow charts, which are described later.

The input device102is a device that allows a user to input data, such as a key board, a mouse, or a touch display.

The storage device103is a hard disk or a random access memory (RAM), which stores user data required for execution of programs and applications.

The display device104is configured to show various kinds of information to a user.

The CPU101, the input device102, the storage device103, and the display device104are connected to one another via a bus105.

FIG. 2is a diagram illustrating an example of a software configuration of the damaged file handling device according to the exemplary embodiment.

The software configuration of the damaged file handling device includes an operating system201, an execution environment202, a framework203, and an application204.

The operating system201is software that serves as a system platform.

The execution environment202runs on the operating system201and provides an environment that allows the application204to run thereon.

The framework203is software configured to manage the operating state of the application204. In this exemplary embodiment, the Open Services Gateway Initiative (OSGi) framework is used as a framework203for managing dynamic installation and execution of a Java (registered trademark) module.

The framework203describes information on the installed application204, such as the startup sequence, the state, the storage location of data to be used (hereinafter, referred to as “management information”) in a file (hereinafter, referred to as a “management file”). Thus, the framework203uses the information to manage the application204. The framework203is configured to read the management file at startup and to reproduce the same state as that of the last startup. When the management information needs to be modified due to installation, update, or state change of the application204, the framework203updates the management file accordingly. The management file is created separately depending on the information held in the damaged file handling device. Thus, a plurality of the management files may exist.

In this exemplary embodiment, the phrase “installation of the application204” more specifically means installation of an application file to be executed by the CPU101to implement the function of the application204. For convenience of description, however, the phrase “installation of the application204” will be used even in the case of installation of the application file.

FIG. 3is a diagram illustrating an example of a directory configuration of the storage device103.

The storage device103includes a cache directory301, a bundle directory302, and a library directory303.

The cache directory301stores the installed application204, user data to be used by the application204, the management file, a flag file described later, and the like.

When the application204is installed in the cache directory301, the framework203creates a directory and stores the installed application204itself and the user data into the directory. In addition, the framework203stores a management file that describes a relationship between the application204and the user data in the cache directory301.

The bundle directory302stores the application204required for operating the damaged file handling device. The application204is used at the initial startup of the damaged file handling device.

The library directory303stores a library file to be used by the damaged file handling device. In addition, the library directory303stores a file that describes information on initial installation, such as applications to be installed at initial startup and the installation order of applications.

Next, the operation of the framework203will be described with reference toFIG. 4.

FIG. 4is a diagram illustrating an example of functions of the framework203.

In the startup processing, the framework203determines whether a problem occurred in the management file or the application204during the last operation, followed by causing the corresponding damage handling unit401to execute processing. Subsequently, the framework203executes processing by an application startup preparing unit402that reads the application204stored in the cache directory301, and by an application startup unit403that starts up the application204. Here, the application204managed by the framework203includes a startup level to be referenced at startup. On the other hand, the framework203includes a startup instruction level that determines which applications204to be started by its startup level.

The application startup unit403sequentially starts up the applications204which have a startup level not higher than the startup instruction level of the framework203. Furthermore, the framework203includes a startup instruction level changing unit404as a function which allows the user to change the startup instruction level. Similarly, the framework203has a startup level changing unit405as a function which allows the user to change the startup level of the application204.

The framework203controls the operating state of the application204. In other words, the framework203has functions to install, update, uninstall, start, and stop the application204. In the present exemplary embodiment, these functions are respectively referred to as an application adding unit406, an application updating unit407, an application deleting unit408, an application starting unit409, and an application stopping unit410. Furthermore, the framework203uses an application monitoring unit411to check whether a trouble has occurred at startup or during operation of the application204.

At startup, the framework203uses a management information reading unit412to read a management file stored in a hard disk of the storage device103and then to store the contents of the management file in a RAM of the storage device103. Subsequently, the framework203performs processing based on the contents of the management file, the management information, stored in the RAM of the storage device103. Upon update of the management information, the framework203uses a management information writing unit413to write the updated management information into the management file in the hard disk. The framework203uses the startup instruction level changing unit404and the startup level changing unit405to update various kinds of levels. Furthermore, the framework203allows the application adding unit406, the application updating unit407, the application deleting unit408, the application starting unit409, and the application stopping unit410to update the information on the application204.

Referring now toFIG. 5, the startup processing of the damaged file handling device will be described.

FIG. 5is a diagram illustrating an example of functions of startup processing performed by the damaged file handling device and of information to be used in the startup processing.

The functions of startup processing performed by the damaged file handling device can be mainly classified into three functions: the damage handling unit401, the application startup preparing unit402, and the application startup unit403.

First, the damage handling unit401will be described.

The damage handling unit401includes a partial deleting unit501and a complete deleting unit502as functions thereof, and utilizes a stage-1 flag file503and a stage-2 flag file504as pieces of information.

The stage-1 flag file503and the stage-2 flag file504are flag files indicating that damage occurred in the management file and/or the application204during the last operation. The details of the flag files will be described later.

The damaged file handling device stores the application204required for the operation in the bundle directory302. Thus, even if the application204stored in the bundle directory302has been removed from the cache directory301, the damaged file handling device103can reinstall the application204. When the damaged file handling device is connected to a communicable network, the damaged file handling device may store the application204on the network to reinstall the application204therefrom.

Furthermore, some of the management files can be recreated based on the information on initial installation stored in the library directory303. The presence of the stage-1 flag file503in the cache directory301means that a reinstallable or recreatable file is damaged. Here, the above-mentioned reinstallable or recreatable file is an example of a restorable file. Furthermore, as described above, processing of reinstalling or recreating a damaged file in a cache area based on the file in the bundle directory, the file on the network, or the file in the library directory is an example of restoration processing.

Furthermore, the framework203can install the application204, which has not been stored in the bundle directory302, by using the application adding unit406. However, since the application204is not in the bundle directory302, the damaged file handling device cannot perform reinstallation and recreation after removal of the application204from the cache directory301. Thus, the presence of the stage-2 flag file504in the cache directory301indicates that a file, which cannot be reinstalled or recreated, has been damaged. Here, the above-mentioned unreinstallable or unrecreatable file is an example of an unrestorable file.

When the stage-1 flag file503is in the cache directory301, the partial deleting unit501deletes the reinstallable application204or the recreatable management file, which is stored in the cache directory301and can be re-installed or re-created. At this time, the partial deleting unit501deletes not only the damaged file but also all the recreatable and reinstallable files in the cache directory301.

The partial deleting unit501deletes not only the damaged file but also all the recreatable and reinstallable files in order to ensure consistency between the management files. Information used for management file recreation held by the damaged file handling device does not include any change made to the application204after installation. Thus, the damaged file handling device recreates a management file based on the information obtained immediately after installation. If the damaged file handling device recreates only the damaged management file, the damaged file handling device may not properly run because of inconsistency between the recreated management file and the non-recreated management file. The damaged file handling device therefore recreates a management file after deleting all the recreatable management files to maintain the consistency. The damaged file handling device deletes the reinstallable application204but does not delete user data that cannot be recreated based on the information held by the damaged file handling device.

On the other hand, the complete deleting unit502deletes all the files in the cache directory301including the user data of the respective applications204when the stage-2 flag file504is in the cache directory301.

Next, the application startup preparing unit402will be described.

The application startup preparing unit402includes an initial installation unit505, a cache reading unit506, and a cache recovery unit507as functions, and uses cache application-related information508as information thereof.

In a state that no application204has been installed, for example, in a state immediately after shipment of the damaged file handling device, the initial installation unit505executes processing such as initial installation. More specifically, the initial installation unit505performs installation of the application204stored in the bundle directory302and creation of a new management file. Here, when the complete deleting unit502has deleted all the files in the cache directory301, the initial installation unit505installs the application204stored in the bundle directory302and creates a new management file.

When the application204has been already installed in the damaged file handling device, the cache reading unit506reads the cache directory301. More specifically, the cache reading unit506reads information on the application204that has been installed and stored in the cache directory301to prepare for startup of the application204.

When the partial deleting unit501deletes the reinstallable or recreatable file in the cache directory301, the cache recovery unit507executes processing for restoring the deleted file. More specifically, the cache recovery unit507performs processing for reinstallation of the application204deleted by the partial deleting unit501or recreation of the management file or processing for returning the application204to the initial state thereof.

First, the processing for reinstallation of the application204or recreation of the management file, deleted by the partial deleting unit501will be described.

The application204deleted by the partial deleting unit501is stored in the bundle directory302. Thus, the cache recovery unit507can reinstall the application204by referring to the bundle directory302.

On the other hand, the cache recovery unit507can recreate a management file, which has been deleted by the partial deleting unit501, based on necessary information collected from the information on initial installation stored in the library directory303. However, the set values included in the description of the management file recreated by the cache recovery unit507are the initial values (i.e. the values specified for the application204immediately after installation). This is because information used for recreating the management file does not include any change made to the application204after installation. Furthermore, the cache recovery unit507uses cache application-related information508to recreate the management file that describes the relationship between the user data, which has not been deleted by the partial deleting unit501, and the application204. Here, the cache application-related information508is backup information provided for any possible damage to the management file which includes information associating the application204with the user data. More specifically, the cache application-related information508is information associating the installed application204and the user data, and is created by the damaged file handling device. Here, creation of the cache application-related information508is an example of related information creation processing.

Next, processing for returning the application204to the initial state by the application startup preparing unit402will be described.

In the damaged file handling device, the applications204may have dependence relationships with each other. The dependence relationship is, for example, a case where operating an application A requires an application B to be operated in advance. In the damaged file handling device where the applications204having such a dependence relationship are installed, the dependence relationship may be lost if the set values of the recreatable management file are changed to the initial set values. As a result, an error may occur at startup. To avoid such a situation, the application startup preparing unit402needs to change the states of all the installed applications204to the initial states thereof. Here, the term “initial state” means a state being set to the state of the application204immediately after installation.

The damaged file handling device installs the application204that has been stored in the bundle directory302at initial startup, based on the information on the initial installation stored in the library directory303. In such a manner, if the application204is installed at initial startup, the state specified at initial startup is considered as the initial state. On the other hand, if the application204has not been installed at initial startup, the stopped state thereof is considered as the initial state. Thus, the operating state of the respective applications204can be equal to the state at initial startup thereof by changing the states of all the applications204to the initial states. As a result, the damaged file handling device can be prevented from causing any error due to the dependence relationship.

Next, processing performed by the application startup unit403is described.

As mentioned above, the application startup unit403allows the applications204having a startup level not higher than the startup instruction level of the framework203to start up in the order from the one having the lowest startup level. However, the started application204here is only the application204whose last state is described as running in the management file.

As described above, when the management file or the application204is damaged, the damaged file handling device uses the damage handling unit401to delete the damaged file, and then uses the application startup preparing unit402to reinstall or recreate the file. Subsequently, the application startup unit403uses the reinstalled or recreated file to start the application204as usual. Thus, when the reinstallable or recreatable file is damaged, the damaged file handling device can restore the file without deleting user data. Furthermore, even if an unrestorable file is damaged, the damaged file handling device can properly start the system.

Next, the operation of the damage handling unit401will be described with reference toFIG. 6.

FIG. 6is a flowchart illustrating an example of processing performed by the damage handling unit401.

In step S601, the damage handling unit401first checks whether the stage-1 flag file503is present in the cache directory301.

In step S602, the stage-1 flag file503is present, the damage handling unit401determines that a recreatable or reinstallable file in the cache directory301has been damaged, and then deletes every recreatable or reinstallable file in the cache directory301. As described above, in step S602, the damage handling unit401does not delete user data to be used by each application204.

On the other hand, in step S603, if the stage-1 flag file503is not present, the damage handling unit401checks whether the stage-2 flag file504is present in the cache directory301.

In step S604, if the stage-2 flag file504is present, the damage handling unit401determines that a file in the cache directory301, which cannot be recreated or reinstalled, is damaged and then deletes all the files in the cache directory301including the user data.

Furthermore, if neither the stage-1 flag file503nor the stage-2 flag file504is present, the damage handling unit401determines that no file is damaged, thereby performing no processing for handling a damaged file.

Next, the operation of the application startup preparing unit402will be described with reference toFIG. 7.

FIG. 7is a flowchart illustrating an example of processing performed by the application startup preparing unit402.

First, in step S701, the application startup preparing unit402checks whether the cache directory301is present.

In step S702, if the cache directory301is not present, the application startup preparing unit402determines that no application204has been installed, and then installs the application204stored in the bundle directory302. Executing the processing in step S702after deleting all the files in the cache directory301in step S604means that the cache directory301is initialized.

Subsequently, in step S703, the application startup preparing unit402creates a new management file that describes management information, including the startup instruction level held by the framework203, and the startup levels of the respective applications204.

On the other hand, in step S704, if the cache directory301is present, the application startup preparing unit402checks whether the stage-1 flag file503is present in the cache directory301.

In step S705, if the stage-1 flag file503is present, the application startup preparing unit402determines that the damage handling unit401has deleted a recreatable or reinstallable file, and reinstalls the deleted application204from the bundle directory302or the network.

Then, in step S706, the application startup preparing unit402recreates the deleted management file based on the information on initial installation held by the damaged file handling device.

Finally, in step S707, the application startup preparing unit402changes the state of the application204to the initial state to avoid an error at startup.

In step S708, if the stage-1 flag file503is not present, the application startup preparing unit402determines that no abnormality occurred in the last operation. Then, the application startup preparing unit402reads information on the application204stored in the cache directory301to prepare for startup of the application204.

Next, the operation of the application startup unit403will be described with reference toFIG. 8.

FIG. 8is a flowchart illustrating an example of processing performed by the application startup unit403.

First, in step S801, the application startup unit403reads the startup instruction level included in the framework203from the management file.

In steps S802, S803, S804, S805, and S806, the application startup unit403starts up the applications204which have a startup level within 1 to the startup instruction level, as well as which were previously in a running state, in the order from the one having the lowest startup level.

Thus, the framework203handles a damaged file in the startup processing, allowing the damaged file handling device to be properly started.

Next, the operation of the management information reading unit412will be described with reference toFIG. 9.

FIG. 9is a flowchart illustrating an example of processing performed by the management information reading unit412.

In the framework203, the management information reading unit412determines whether the management file is damaged.

In step S901, the management information reading unit412acquires a checksum described at the end of the management file to be read. This checksum has been added by the management information writing unit413described later. The management information reading unit412uses this value to perform an operational check. Here, the checksum is an example of an error detection code.

Next, in step S902, the management information reading unit412calculates a checksum based on the contents of the target management file to be read.

Then, in step S903, the management information reading unit412determines whether the checksum acquired in step S901matches the checksum calculated in step S902to check if there is any damage in the management file.

In step S904, if the acquired checksum matches the calculated checksum, the management information reading unit412determines that the management file is not damaged, and then reads the contents of the management file and ends the processing.

In step S905, if the acquired checksum does not match the calculated checksum, the management information reading unit412determines that the management file has been damaged. Then, the management information reading unit412determines whether the damaged management file is recreatable, in order to create a flag file indicating that the file is damaged. More specifically, the management information reading unit412determines whether the damaged management file is recreatable, based on the information on initial installation stored in the library directory303.

In step S906, if the management information reading unit412determines that the management file is recreatable, the management information reading unit412shows on the display device104that a recreatable file is damaged.

Subsequently, in step S907, the management information reading unit412waits for an input from the user via the input device102to determine whether the damaged management file needs to be recreated.

In step S908, if the management information reading unit412receives an input from the user via the input device102, informing that the user desires to recreate the damaged management file, the management information reading unit412creates the stage-1 flag file503indicating that a recreatable file is damaged. Here, creation of the stage-1 flag file503is an example of flag file creation processing.

On the other hand, if the management information reading unit412receives an input from the user via the input device102, informing that the user does not desire to recreate the damaged management file, the processing is ended.

In step S909, on the other hand, if the management information reading unit412determines that the damaged management file is not recreatable in step S905, the management information reading unit412shows on the display device104that an unrecreatable file has been damaged.

Then, in step S910, the management information reading unit412waits for an input from the user to determine whether initialization needs to performed.

In step S911, if the management information reading unit412receives an input from the user via the input device102, informing that the user desires to perform initialization, the management information reading unit412creates the stage-2 flag file504indicating that an un-recreatable file has been damaged. Creation of the stage-2 flag file504is an example of flag file creation processing.

After creating a flag file, in step S912, the management information reading unit412restarts the damaged file handling device in order to restore the damaged management file. This is because the damaged file is to be handled while the damaged file handling device is in startup processing.

In the present exemplary embodiment, the management information reading unit412is configured to determine the presence or absence of any damage in the management file based on the result of a comparison between the checksum described in the target management file and the checksum calculated from the contents of the target management file. However, the determination procedure is not limited to such a procedure. Alternatively, for example, the framework203may monitor processing such as installation of files and determine that a file is damaged based on a result of the monitoring, such as improper completion of installation. The determination on whether a file is damaged as described above is an example of the damaged file detection processing.

Referring now toFIG. 10, the operation of the management information writing unit413will be described.FIG. 10is a flowchart illustrating an example of processing performed by the management information writing unit413. First, in step S1001, the management information writing unit413calculates and acquires a checksum based on contents to be written to the management file. As described inFIG. 9, the checksum calculated in step S1001is compared with the checksum acquired from the contents read by the management information reading unit412to determine whether the file is damaged.

Next, in step S1002, the management information writing unit413writes the contents to be written to the file.

Subsequently, in step S1003, the management information writing unit413writes the checksum calculated and acquired in step S1001at the end of the file.

Thus, the framework203uses the management information writing unit413to embed in the file the checksum to be used to check for damage. Subsequently, the framework203uses the management information reading unit412to determine whether the file is damaged by using the checksum. Thus, the framework203prevents the damaged file handling device from being disabled due to a damaged management file.

Next, the operation of the application monitoring unit411will be described with reference toFIG. 11.

FIG. 11is a flowchart illustrating an example of processing performed by the application monitoring unit411.

The framework203controls the state of the application204. For this purpose, the application monitoring unit411is capable of detecting abnormalities, such as damage to the application204. Here, the detection of abnormalities, such as damage to the application204is an example of detection processing. The application monitoring unit411detects and handles an exceptional event during the operation of the application204.

In step S1101, if the application monitoring unit411detects any abnormality in the application204, the application monitoring unit411determines whether the application204is reinstallable. More specifically, if the application204having the abnormality detected in step S1101is the application204stored in the bundle directory302or on the network, the application monitoring unit411determines that the application204is reinstallable.

In step S1102, if the application monitoring unit411determines that the application204having an abnormality is reinstallable, the application monitoring unit411notifies the user via the display device104that a reinstallable file is damaged.

Subsequently, in step S1103, the application monitoring unit411waits for an input from the user via the input device102to determine whether the reinstallation needs to be performed.

In step S1104, if the application monitoring unit411receives an input from the user via the input device102, informing that the user desires to perform the reinstallation, the application monitoring unit411creates the stage-1 flag file503indicating that a reinstallable file has been damaged. Creation of the stage-1 flag file503is an example of flag file creation processing.

On the other hand, in step S1105, if the application monitoring unit411determines that the application204having an abnormality cannot be reinstalled, the application monitoring unit411notifies the user via the display device104that an unrecreatable file is damaged.

Subsequently, in step S1106, the application monitoring unit411waits for an input from the user via the input device102to determine whether initialization of the cache directory301needs to be performed.

In step S1107, if the application monitoring unit411receives an input from the user via the input device102, informing that the user desires to perform initialization of the cache directory301, the application monitoring unit411creates the stage-2 flag file504indicating that an unrecreatable file has been damaged. Creation of the stage-2 flag file504is an example of flag file creation processing.

Then, in step S1108, the application monitoring unit411restarts the damaged file handling device to handle the application204having an abnormality.

Thus, the framework203uses the application monitoring unit411to detect damage to the application204, thereby preventing the damaged file handling device from being disabled.

In the present exemplary embodiment, the application monitoring unit411is configured to determine whether to reinstall a application204and whether to initialize a cache directory301, based on an input from the user via the input device102. However, the determination procedure is not limited to such a procedure. Alternatively, for example, the application monitoring unit411may determine whether the reinstallation or the initialization need to be performed, based on predetermined settings.

According to each of the exemplary embodiments described above, if a restorable file is damaged, the damaged file can be restored without taking up resources or deleting user data in the cache. Furthermore, a system startup failure can be handled even when an unrestorable file is damaged.

According to the exemplary embodiment, if a restorable file is damaged, the damaged file can be restored without taking up resources or deleting user data in the cache. Furthermore, a system startup failure can be handled even when an unrestorable file is damaged.

This application claims the benefit of Japanese Patent Application No. 2012-262776 filed Nov. 30, 2012, which is hereby incorporated by reference herein in its entirety.