(57)【要約】【課題】復元させることができるファイルが破損した場合、リソースを圧迫することなく、かつ、キャッシュにあるユーザデータを削除せずに破損したファイルを復元させる。【解決手段】キャッシュ領域内に格納されたファイルから破損したファイルを検知する検知手段と、前記検知手段により検知された破損したファイルが復元可能なファイルであるか否かを判断する判断手段と、前記判断手段により復元可能と判断された場合、キャッシュ領域内の復元可能なファイルを削除し、前記削除したファイルをキャッシュ領域内に復元させる復元手段と、前記判断手段により復元不可能と判断された場合、キャッシュ領域内のファイルを削除して初期化する初期化手段と、を有することによって課題を解決する。【選択図】図７
2014109821.tif 000002
【特許請求の範囲】
【請求項１】
キャッシュ領域内に格納されたファイルから破損したファイルを検知する検知手段と、
前記検知手段により検知された破損したファイルが復元可能なファイルであるか否かを判断する判断手段と、
前記判断手段により復元可能と判断された場合、キャッシュ領域内の復元可能なファイルを削除し、前記削除したファイルをキャッシュ領域内に復元させる復元手段と、
前記判断手段により復元不可能と判断された場合、キャッシュ領域内のファイルを削除して初期化する初期化手段と、
を有する情報処理装置。
【請求項２】
前記復元手段は、前記削除したファイルが前記情報処理装置の動作に要するアプリケーションファイルであった場合、アプリケーションファイルが格納されているバンドルディレクトリ内のファイルに基づいて前記削除したファイルを復元させる請求項１記載の情報処理装置。
【請求項３】
前記復元手段は、前記削除したファイルがアプリケーションファイルの実行に要する管理ファイルであった場合、アプリケーションファイルの初期インストールに関する情報が記述されたファイルが格納されているライブラリディレクトリ内のファイルに基づいて前記削除したファイルを復元させる請求項１記載の情報処理装置。
【請求項４】
前記検知手段により検知された破損したファイルが復元可能なファイルであるか否かの情報が記述されたフラグファイルを作成して前記情報処理装置を再起動するフラグファイル作成手段を更に有し、
前記判断手段は、前記フラグファイル作成手段による前記再起動の後に、前記フラグファイル作成手段により作成された前記フラグファイルに基づいて前記破損したファイルが復元可能なファイルであるか否かを判断する請求項１乃至３何れか１項記載の情報処理装置。
【請求項５】
前記復元可能なファイルとは、保持しているファイル、又は通信可能なネットワーク上に格納されているファイルに基づいて再インストール、又は再作成することができるファイルであり、
前記判断手段は、前記検知手段により検知された破損したファイルが前記復元可能なファイルであるか否かを判断する請求項１乃至４何れか１項記載の情報処理装置。
【請求項６】
前記検知手段は、キャッシュ領域内に格納されたファイルに記載されている誤り検出符号と、前記ファイルの内容から計算して取得した誤り検出符号とが一致するか否かに基づいて破損したファイルを検知する請求項１乃至５何れか１項記載の情報処理装置。
【請求項７】
前記検知手段は、キャッシュ領域内に格納されたファイルのインストール処理が正常に終了しなかった場合、前記ファイルを破損しているファイルとして検知する請求項１乃至５何れか１項記載の情報処理装置。
【請求項８】
入力装置を介してユーザからの指示を受信する受信手段を更に有し、
前記復元手段は、前記受信手段により破損したファイルの復元を実行する旨の指示が受信された場合、キャッシュ領域内の復元可能なファイルを削除し、前記削除したファイルをキャッシュ領域内に復元させ、
前記初期化手段は、前記受信手段により初期化を実行する旨の指示が受信された場合、キャッシュ領域内のファイルを削除して初期化する請求項１乃至７何れか１項記載の情報処理装置。
【請求項９】
前記復元手段による復元及び前記初期化手段による初期化に係る処理を実行するか否かに関して予め設定する設定手段を更に有し、
前記復元手段は、前記設定手段により破損したファイルの復元を実行する旨の設定がされている場合、キャッシュ領域内の復元可能な破損したファイルを削除し、前記削除したファイルをキャッシュ領域内に復元させ、
前記初期化手段は、前記設定手段により初期化を実行する旨の設定がされている場合、キャッシュ領域内のファイルを削除して初期化する請求項１乃至７何れか１項記載の情報処理装置。
【請求項１０】
前記判断手段により復元可能と判断された場合、アプリケーションファイルが格納されているバンドルディレクトリ内のファイルの情報と、前記バンドルディレクトリ内のファイルの実行に要するキャッシュ領域のファイルの情報とを関連付けた関連情報を作成する関連情報作成手段を更に有し、
前記復元手段は、前記関連情報作成手段により前記関連情報が作成されると、キャッシュ領域内の復元可能なファイルを削除し、前記削除したファイルをキャッシュ領域内に復元させる請求項１乃至９何れか１項記載の情報処理装置。
【請求項１１】
情報処理装置が実行する情報処理方法であって、
キャッシュ領域内に格納されたファイルから破損したファイルを検知する検知ステップと、
前記検知ステップにより検知された破損したファイルが復元可能なファイルであるか否かを判断する判断ステップと、
前記判断ステップにより復元可能と判断された場合、キャッシュ領域内の復元可能なファイルを削除し、前記削除したファイルをキャッシュ領域内に復元させる復元ステップと、
前記判断ステップにより復元不可能と判断された場合、キャッシュ領域内のファイルを削除して初期化する初期化ステップと、
を含む情報処理方法。
【請求項１２】
コンピュータに、
キャッシュ領域内に格納されたファイルから破損したファイルを検知する検知ステップと、
前記検知ステップにより検知された破損したファイルが復元可能なファイルであるか否かを判断する判断ステップと、
前記判断ステップにより復元可能と判断された場合、キャッシュ領域内の復元可能なファイルを削除し、前記削除したファイルをキャッシュ領域内に復元させる復元ステップと、
前記判断ステップにより復元不可能と判断された場合、キャッシュ領域内のファイルを削除して初期化する初期化ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
キャッシュを有するシステムにおいて、キャッシュファイルへ書き込みを行っている最中に電源切断されると、キャッシュファイルが破損した状態で書き込まれる可能性がある。そして、この破損したキャッシュファイルの読み込みが原因となり、システムやアプリケーションの動作不良が起こり得る。このようなキャッシュファイルが破損した場合の改善策としては、キャッシュファイルを全て削除し、製造直後の状態に戻す方法がある。また、これ以外にも以下のような技術が挙げられる。
電源の遮断に先立って終了処理が実施されたか否かを示す電源断フラグ信号を保持し、電源断フラグ信号が電源断に先立って終了処理が実施されていないことを示していれば、外部記憶装置に構築されたファイルシステムの修復を行う（特許文献１）。
各業務に対応した複数のデータをデータファイル領域で記憶すると共に、データバックアップ領域を設ける。そして、業務メニューから何れかの業務が選択されると、その業務のデータ処理を開始する前にその業務に対応するデータファイルをバックアップ領域に複写する。もし、データ処理中にアプリケーションプログラムが強制終了されると、バックアップ領域に記憶されているファイルをデータファイル領域に復元させる（特許文献２）。
操作パネル用プログラムの先頭部と、最終部とにそれぞれ同一のユニークなデータを設定し、操作パネル用プログラム起動時にユニークなデータの不一致を検出した場合、自動的に破損された操作パネル用プログラムの修復を行う（特許文献３）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１１−７６３６７号公報
【特許文献２】特開２０１０−９７５６０号公報
【特許文献３】特開２００８−１８６６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
キャッシュファイルの全削除では、キャッシュ内にある全てのファイルを削除してしまう。このため、キャッシュ内にアプリケーションが利用するデータが格納されている場合には、そのデータまでも削除されてしまう。
特許文献１に開示されている技術は、電源切断以前に処理が終了したか否かを判断し、終了していないと判断した場合に修復処理を行う。このため、特許文献１に開示されている技術は、ファイル破損が発生したという観点でしか復旧の対応をすることができない。
特許文献２、特許文献３に開示されている技術は、機器内部に予め復旧に必要なファイル等を格納し、ファイルが破損した際にはそれらを用いて修復を行う。このため、修復に必要なファイルが機器のリソースを圧迫してしまう。また、特許文献３に開示されている技術では、復旧に必要なファイルが機器内部に存在しない場合、問題が発生した際に対応することができない。
本発明は、上記問題を鑑みてなされたものであり、復元させることができるファイルが破損した場合であれば、リソースを圧迫することなく、かつ、ユーザデータを削除せずに復元させることができる技術を提供することを目的とする。また、本発明は、復元させることができないファイルが破損した場合であっても、システムが起動できなくなる問題に対して対処することができる技術を提供することを目的とする。
【課題を解決するための手段】
【０００５】
そこで、本発明は、キャッシュ領域内に格納されたファイルから破損したファイルを検知する検知手段と、前記検知手段により検知された破損したファイルが復元可能なファイルであるか否かを判断する判断手段と、前記判断手段により復元可能と判断された場合、キャッシュ領域内の復元可能なファイルを削除し、前記削除したファイルをキャッシュ領域内に復元させる復元手段と、前記判断手段により復元不可能と判断された場合、キャッシュ領域内のファイルを削除して初期化する初期化手段と、を有する。
【発明の効果】
【０００６】
本発明によれば、復元させることができるファイルが破損した場合、リソースを圧迫することなく、かつ、キャッシュにあるユーザデータを削除せずに破損したファイルを復元させることができる。また、復元させることができないファイルが破損した場合であっても、システムが起動できなくなる問題に対して対処することができる。
【図面の簡単な説明】
【０００７】
【図１】破損ファイル対応装置のハードウェア構成の一例を示す図である。
【図２】破損ファイル対応装置のソフトウェア構成の一例を示す図である。
【図３】記憶装置のディレクトリ構成の一例を示す図である。
【図４】フレームワークが有する機能の一例を示す図である。
【図５】破損ファイル対応装置の起動処理における機能と、起動処理の際に扱う情報との一例を示す図である。
【図６】破損対応部による処理の一例を示すフローチャートである。
【図７】アプリケーション起動準備部による処理の一例を示すフローチャートである。
【図８】アプリケーション起動部による処理の一例を示すフローチャートである。
【図９】管理情報読み込み部による処理の一例を示すフローチャートである。
【図１０】管理情報書き込み部による処理の一例を示すフローチャートである。
【図１１】アプリケーション監視部による処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面に基づき説明する。
【０００９】
＜実施形態１＞
図１は、本実施形態の破損ファイル対応装置のハードウェア構成の一例を示す図である。
破損ファイル対応装置は、ハードウェア構成としてＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０１、入力装置１０２、記憶装置１０３、表示装置１０４を含む。なお、破損ファイル対応装置は、情報処理装置の一例である。
ＣＰＵ１０１は、記憶装置１０３に格納されているプログラムを実行することにより後述の破損ファイル対応装置の機能（ソフトウェア構成）及びフローチャートに係る処理を実現する。
入力装置１０２は、キーボード、マウス、タッチディスプレイ等のユーザが情報を入力するためのデバイスである。
記憶装置１０３は、プログラムやアプリケーションの実行に要するデータであるユーザデータが格納されているハードディスクやＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等である。
表示装置１０４は、ユーザへ各種情報を表示するディスプレイである。
ＣＰＵ１０１、入力装置１０２、記憶装置１０３、表示装置１０４は、バス１０５を介して、接続されている。
【００１０】
図２は、本実施形態の破損ファイル対応装置のソフトウェア構成の一例を示す図である。
破損ファイル対応装置は、ソフトウェア構成としてオペレーティングシステム２０１、実行環境２０２、フレームワーク２０３、アプリケーション２０４を含む。
オペレーティングシステム２０１は、システムの基盤となるソフトウェアである。
実行環境２０２は、オペレーティングシステム２０１上で動作し、自身の上でアプリケーション２０４が動作する環境を提供する。
フレームワーク２０３は、アプリケーション２０４の動作状態を管理するソフトウェアである。本実施形態では、Ｊａｖａ（登録商標）モジュールの動的インストールや実行を管理するフレームワーク２０３として、ＯＳＧｉ（Ｏｐｅｎ  Ｓｅｒｖｉｃｅｓ  Ｇａｔ
ｅｗａｙ  ｉｎｉｔｉａｔｉｖｅ）フレームワークを用いる。
【００１１】
フレームワーク２０３は、インストールされたアプリケーション２０４の起動順、状態、利用するデータの格納先等の情報（以下、管理情報という）をファイル（以下、管理ファイルという）に記述し、アプリケーション２０４の管理に利用している。また、フレームワーク２０３は、起動時に管理ファイルを読み込み、前回の起動時と同じ状態を再現する。そして、フレームワーク２０３は、アプリケーション２０４のインストールやアップデート、状態変更等により管理情報に変更が発生すると、それに合わせて管理ファイルを更新する。管理ファイルは、破損ファイル対応装置が保持する情報によってファイルが分かれており、複数個存在してもよい。
なお、本実施形態において、アプリケーション２０４をインストールするとは、より具体的には、アプリケーション２０４の機能を実現するためにＣＰＵ１０１が実行するアプリケーションファイルをインストールすることである。ただし、説明の便宜上、以後の説明ではアプリケーションファイルをインストールする場合でも、アプリケーションをインストールするという。
【００１２】
図３は、記憶装置１０３のディレクトリ構成の一例を示す図である。
記憶装置１０３は、キャッシュディレクトリ３０１、バンドルディレクトリ３０２、ライブラリディレクトリ３０３を含む。
キャッシュディレクトリ３０１には、インストールされたアプリケーション２０４、アプリケーション２０４が利用するデータであるユーザデータ、管理ファイル、後述するフラグファイル等が格納されている。
フレームワーク２０３は、キャッシュディレクトリ３０１内にアプリケーション２０４がインストールされると、インストールされたアプリケーション２０４そのものを格納し、ユーザデータを格納するディレクトリを作成する。また、フレームワーク２０３は、アプリケーション２０４と、ユーザデータとの関係について記述したファイルである管理ファイルを格納する。
バンドルディレクトリ３０２内には、破損ファイル対応装置を動作させるために必要となるアプリケーション２０４が格納されており、破損ファイル対応装置の初回起動時に利用される。
ライブラリディレクトリ３０３内には、破損ファイル対応装置が利用するライブラリファイルが格納されている。また、ライブラリディレクトリ３０３内には、初回起動時にインストールされるアプリケーションやアプリケーションをインストールする順番等の初期インストールに関する情報が記載されたファイルも格納されている。
【００１３】
次に、フレームワーク２０３の動作について、図４を用いて説明する。
図４は、フレームワーク２０３が有する機能の一例を示す図である。
フレームワーク２０３は、起動処理において、前回の動作で管理ファイルやアプリケーション２０４に問題が発生していないかをチェックし、対応する破損対応部４０１による処理を実行する。そして、フレームワーク２０３は、キャッシュディレクトリ３０１内に格納されたアプリケーション２０４の読み込み等を行うアプリケーション起動準備部４０２、アプリケーション２０４の起動を行うアプリケーション起動部４０３による処理を実行する。なお、フレームワーク２０３が管理しているアプリケーション２０４は、起動時に参照される起動レベルを含んでいる。一方で、フレームワーク２０３は、起動するアプリケーション２０４を制限するためのレベルである起動指示レベルを含んでいる。
アプリケーション起動部４０３は、フレームワーク２０３が起動指示レベル以下の起動レベルを含むアプリケーション２０４を順次起動させる。また、フレームワーク２０３は、ユーザが起動指示レベルを変更するための機能として、起動指示レベル変更部４０４を有する。同様に、フレームワーク２０３は、アプリケーション２０４の起動レベルを変更する機能として、起動レベル変更部４０５を有する。
【００１４】
フレームワーク２０３は、アプリケーション２０４の動作状態を管理する。すなわち、フレームワーク２０３は、アプリケーション２０４のインストール、アップデート、アンインストール、開始、停止を行う機能を有する。本実施形態では、上記の機能それぞれをアプリケーション追加部４０６、アプリケーション更新部４０７、アプリケーション削除部４０８、アプリケーション開始部４０９、アプリケーション停止部４１０とする。また、フレームワーク２０３は、アプリケーション２０４の開始時や動作中に異常が発生していないかをアプリケーション監視部４１１により監視している。
フレームワーク２０３は、起動時に管理情報読み込み部４１２により、記憶装置１０３のハードディスクに格納されている管理ファイルの読み込みを行い、記憶装置１０３のＲＡＭに格納する。そして、フレームワーク２０３は、記憶装置１０３のＲＡＭに格納した管理ファイルの内容に基づき処理を行う。また、フレームワーク２０３は、管理情報の更新が行われると、管理情報書き込み部４１３により管理情報を管理ファイルに記載し、ハードディスクに保存する。また、フレームワーク２０３は、起動指示レベル変更部４０４、起動レベル変更部４０５により、各種レベルの更新を行う。また、フレームワーク２０３は、アプリケーション追加部４０６、アプリケーション更新部４０７、アプリケーション削除部４０８、アプリケーション開始部４０９、アプリケーション停止部４１０により、アプリケーションに関する情報の更新を行う。
【００１５】
次に、破損ファイル対応装置の起動処理について、図５を用いて説明する。
図５は、破損ファイル対応装置の起動処理における機能と、起動処理の際に扱う情報との一例を示す図である。
破損ファイル対応装置の起動処理の機能は、破損対応部４０１、アプリケーション起動準備部４０２、アプリケーション起動部４０３の３つの機能に大きく分けることができる。
まず、破損対応部４０１について説明する。
破損対応部４０１は、部分削除部５０１、全削除部５０２を機能として有し、情報として段階１フラグファイル５０３、段階２フラグファイル５０４を利用する。
段階１フラグファイル５０３、段階２フラグファイル５０４とは、前回の動作時に管理ファイルやアプリケーション２０４に破損があったことを示すフラグファイルである。フラグファイルの詳細については後述する。
【００１６】
破損ファイル対応装置は、動作に必要となるアプリケーション２０４をバンドルディレクトリ３０２内に格納する。このため、破損ファイル対応装置は、バンドルディレクトリ３０２内に格納されているアプリケーション２０４がキャッシュディレクトリ３０１内から削除されても、再度インストールすることができる。なお、破損ファイル対応装置は、破損ファイル対応装置が通信可能なネットワークに接続されている場合、ネットワーク上にアプリケーションを格納することで、そこから再インストールを行うようにすることもできる。
また、管理ファイルにおいても、ライブラリディレクトリ３０３内に格納されている初期インストールに関する情報等を基に再作成が可能な管理ファイルが存在する。キャッシュディレクトリ３０１内に段階１フラグファイル５０３が存在するということは、このように再インストールや再作成が可能なファイルが破損したことを意味している。なお、上記の再インストールや再作成が可能なファイルは、復元可能なファイルの一例である。また、上述したようにバンドルディレクトリ内のファイル、ネットワーク上のファイル、ライブラリディレクトリ内のファイルに基づいて、破損したファイルをキャッシュ領域内に再インストールや再作成する処理は、復元処理の一例である。
また、フレームワーク２０３は、アプリケーション追加部４０６によって、バンドルディレクトリ３０２内に格納されていないアプリケーション２０４をインストールすることができる。しかし、破損ファイル対応装置は、バンドルディレクトリ３０２内にアプリケーション２０４が存在しないので、アプリケーション２０４がキャッシュディレクトリ３０１内から削除されると、再インストールや再作成をすることができなくなる。キャッシュディレクトリ３０１内に段階２フラグファイル５０４が存在するということは、このように再インストールや再作成が不可能なファイルが破損したことを意味している。なお、上記の再インストールや再作成が不可能なファイルは、復元不可能なファイルの一例である。
【００１７】
部分削除部５０１は、キャッシュディレクトリ３０１内に段階１フラグファイル５０３が存在した場合に、キャッシュディレクトリ３０１内に格納されている再インストールや再作成が可能なアプリケーション２０４や管理ファイル等の削除を行う。この際、部分削除部５０１は、破損したファイルだけでなく、キャッシュディレクトリ３０１内の再作成や再インストールが可能な全てのファイルを削除する。
部分削除部５０１が破損したファイルだけでなく、再作成や再インストールが可能な全てのファイルを削除するのは、管理ファイル間の整合性を保つためである。破損ファイル対応装置が保持している管理ファイルの再作成に利用する情報には、インストール後の変更内容が含まれていない。そのため、破損ファイル対応装置は、インストール直後の情報に基づいて管理ファイルを再作成する。破損ファイル対応装置が破損した管理ファイルのみを再作成すると、再作成した管理ファイルと、再作成していない管理ファイルとの間で整合性がとれず、破損ファイル対応装置が正常に動作しない可能性がある。そのため、破損ファイル対応装置は、整合性が取れるように再作成可能な管理ファイルを全て削除してから再作成を行う。なお、破損ファイル対応装置は、再インストール可能なアプリケーション２０４は削除するが、破損ファイル対応装置が持つ情報から再作成することができないユーザデータは削除しない。
一方、全削除部５０２は、キャッシュディレクトリ３０１内に段階２フラグファイル５０４が存在した場合に、各アプリケーション２０４のユーザデータを含むキャッシュディレクトリ３０１内の全てのファイルの削除を行う。
【００１８】
次に、アプリケーション起動準備部４０２について説明する。
アプリケーション起動準備部４０２は、初期インストール部５０５、キャッシュ読み込み部５０６、キャッシュ復元部５０７を機能として有し、情報としてキャッシュアプリケーション関連情報５０８を利用する。
初期インストール部５０５は、破損ファイル対応装置の出荷直後等のようにアプリケーション２０４が何もインストールされていない状態のときに、初期インストール等の処理を実行する。より具体的には、初期インストール部５０５は、バンドルディレクトリ３０２内に格納されているアプリケーション２０４のインストールや管理ファイルの新規作成を行う。なお、初期インストール部５０５は、全削除部５０２によりキャッシュディレクトリ３０１内の全ファイルが削除された場合に、バンドルディレクトリ３０２内に格納されているアプリケーション２０４のインストールや管理ファイルの新規作成を行う。
キャッシュ読み込み部５０６は、破損ファイル対応装置にアプリケーション２０４が既にインストールされている場合に、キャッシュディレクトリ３０１の読み込み等を行う。より具体的には、キャッシュ読み込み部５０６は、キャッシュディレクトリ３０１内に格納されているインストール済みのアプリケーション２０４の情報を読み取り、アプリケーションの起動準備を行う。
【００１９】
キャッシュ復元部５０７は、部分削除部５０１にてキャッシュディレクトリ３０１内の再インストールや再作成が可能なファイルが削除された場合に、削除されたファイルを復元させる処理を実行する。より具体的には、キャッシュ復元部５０７は、部分削除部５０１にて削除されたアプリケーション２０４、管理ファイルの再インストールや再作成、アプリケーション２０４を初期状態に戻す処理を行う。
最初に、部分削除部５０１にて削除されたアプリケーション２０４、管理ファイルの再インストールや再作成の処理について説明する。
部分削除部５０１により削除されたアプリケーション２０４は、バンドルディレクトリ３０２内に格納されている。そのため、キャッシュ復元部５０７は、バンドルディレクトリ３０２を参照することで再インストールをすることができる。
一方、キャッシュ復元部５０７は、部分削除部５０１にて削除された管理ファイルを、ライブラリディレクトリ３０３内に格納されている初期インストールに関する情報等から収集した必要な情報に基づいて再作成することができる。但し、キャッシュ復元部５０７により再作成された管理ファイルの記述に含まれる設定値は、初期値（インストール直後のアプリケーション２０４に設定される値）となる。これは、キャッシュ復元部５０７が管理ファイルの再作成に利用する情報が、インストール後の変更内容を含んでいないためである。また、キャッシュ復元部５０７は、部分削除部５０１で削除されなかったユーザデータと、アプリケーション２０４との関連が記載された管理ファイルを再作成する際に、キャッシュアプリケーション関連情報５０８を利用する。なお、キャッシュアプリケーション関連情報５０８は、アプリケーション２０４と、ユーザデータとが関連付けられた関連情報を持つ管理ファイルの破損に備えたバックアップ情報である。より具体的には、キャッシュアプリケーション関連情報５０８は、インストールされているアプリケーションと、ユーザデータとが関連付けられた関連情報であり、破損ファイル対応装置により作成される。なお、キャッシュアプリケーション関連情報５０８の作成は、関連情報作成処理の一例である。
【００２０】
次に、アプリケーション起動準備部４０２がアプリケーション２０４を初期状態に戻す処理について説明する。
破損ファイル対応装置では、アプリケーション２０４間で依存関係を有する可能性がある。依存関係の例としては、アプリケーションＡを動作させるためには事前にアプリケーションＢが動作している必要がある等のケースである。破損ファイル対応装置では、このような依存関係を有するアプリケーション２０４がインストールされている状況において、再作成可能な管理ファイルが初期値に変更された場合、依存関係が崩れ、起動時にエラーが発生する可能性がある。このような事態を避けるため、アプリケーション起動準備部４０２は、インストールされている全てのアプリケーション２０４の状態を初期状態に変更する必要がある。なお、初期状態とは、インストール直後のアプリケーション２０４の状態に設定されている状態のことである。
破損ファイル対応装置は、初回起動時にバンドルディレクトリ３０２内に格納されたアプリケーション２０４を、ライブラリディレクトリ３０３内に格納された初期インストールに関する情報に従ってインストールしている。このような初回起動時にインストールされるアプリケーション２０４については、初回起動時に設定される状態が初期状態となる。一方、初回起動時にインストールされていないアプリケーション２０４については、停止状態が初期状態となる。全てのアプリケーション２０４の状態を初期状態にすることで、アプリケーション２０４の動作状況が初回起動時と同じになり、依存関係が原因となるエラーを防ぐことができる。
【００２１】
次に、アプリケーション起動部４０３による処理について説明する。
アプリケーション起動部４０３は、前述した通り、フレームワーク２０３が有する起動指示レベル以下の起動レベルを含むアプリケーション２０４を起動レベルの一番低い順から起動させる。但し、対象となるアプリケーション２０４は、管理ファイルに記載されている前回の状態が起動中のアプリケーション２０４のみとなる。
以上のように、破損ファイル対応装置では、管理ファイルやアプリケーション２０４に破損が発生した場合、破損対応部４０１が破損したファイルを削除し、アプリケーション起動準備部４０２が前記ファイルの再インストールや再作成を行う。そして、アプリケーション起動部４０３は、再インストールや再作成されたファイルを利用し、通常通りにアプリケーションを起動させる。これにより、破損ファイル対応装置は、再インストールや再作成が可能なファイルが破損した場合に、ユーザデータを削除することなく復元させることができる。また、破損ファイル対応装置は、復元させることができないファイルが破損した場合であっても、正常起動することができるように対処を行うことができる。
【００２２】
次に、破損対応部４０１の動作について図６を用いて説明する。
図６は、破損対応部４０１による処理の一例を示すフローチャートである。
破損対応部４０１は、まずキャッシュディレクトリ３０１内に段階１フラグファイル５０３が存在するか否かを確認する（Ｓ６０１）。
段階１フラグファイル５０３が存在する場合、破損対応部４０１は、キャッシュディレクトリ３０１内の再作成や再インストールが可能なファイルが破損したと判断し、同ディレクトリ内の再作成や再インストールが可能なファイルを削除する（Ｓ６０２）。なお、前述したように、破損対応部４０１は、Ｓ６０２で各アプリケーションが利用するユーザデータを削除しない。
一方、段階１フラグファイル５０３が存在しない場合、破損対応部４０１は、段階２フラグファイル５０４がキャッシュディレクトリ３０１内に存在するか否かを確認する（Ｓ６０３）。
段階２フラグファイル５０４が存在する場合、破損対応部４０１は、キャッシュディレクトリ３０１内の再作成や再インストールが不可能なファイルが破損したと判断し、ユーザデータを含む同ディレクトリ内の全てのファイルを削除する（Ｓ６０４）。
なお、段階１フラグファイル５０３及び段階２フラグファイル５０４のどちらも存在しない場合、破損対応部４０１は、ファイルの破損は発生していないと判断し、破損ファイルの対応処理を行わない。
【００２３】
次に、アプリケーション起動準備部４０２の動作について図７を用いて説明する。
図７は、アプリケーション起動準備部４０２による処理の一例を示すフローチャートである。
アプリケーション起動準備部４０２は、まずキャッシュディレクトリ３０１が存在するか否かを確認する（Ｓ７０１）。
キャッシュディレクトリ３０１が存在しない場合、アプリケーション起動準備部４０２は、アプリケーション２０４が何もインストールされていないと判断する。そして、アプリケーション起動準備部４０２は、バンドルディレクトリ３０２内に格納されているアプリケーション２０４をインストールする（Ｓ７０２）。
そして、アプリケーション起動準備部４０２は、フレームワーク２０３が持つ起動指示レベルや各アプリケーションの起動レベル等の管理情報を記載した管理ファイルを新規に作成する（Ｓ７０３）。
【００２４】
一方、キャッシュディレクトリ３０１が存在する場合、アプリケーション起動準備部４０２は、段階１フラグファイル５０３がキャッシュディレクトリ３０１内に存在するか否かを確認する（Ｓ７０４）。
段階１フラグファイル５０３が存在する場合、アプリケーション起動準備部４０２は、破損対応部４０１により再作成や再インストールが可能なファイルが削除されたと判断する。そのため、アプリケーション起動準備部４０２は、削除されたアプリケーション２０４をバンドルディレクトリ３０２又はネットワーク上から再度インストールする（Ｓ７０５）。
そして、アプリケーション起動準備部４０２は、破損ファイル対応装置が保持している初期インストールに関する情報等を基に削除された管理ファイルを再作成する（Ｓ７０６）。
最後に、アプリケーション起動準備部４０２は、起動時のエラーを避けるためにアプリケーション２０４の状態を初期状態に変更する（Ｓ７０７）。
段階１フラグファイル５０３が存在しない場合、アプリケーション起動準備部４０２は、前回の動作で異常は何も発生していないと判断する。そして、アプリケーション起動準備部４０２は、キャッシュディレクトリ３０１内に格納されているアプリケーション２０４の情報を読み込み、アプリケーション２０４の起動準備を行う（Ｓ７０８）。
【００２５】
次に、アプリケーション起動部４０３の動作について図８を用いて説明する。
図８は、アプリケーション起動部４０３による処理の一例を示すフローチャートである。
アプリケーション起動部４０３は、まず管理ファイルからフレームワーク２０３が含む起動指示レベルを読み込む（Ｓ８０１）。
そして、アプリケーション起動部４０３は、１から起動指示レベルまでの起動レベルを含み、前回の状態が起動中であるアプリケーション２０４を起動レベルが一番低い順に起動させる（Ｓ８０２、Ｓ８０３、Ｓ８０４、Ｓ８０５、Ｓ８０６）。
このように、フレームワーク２０３は、起動処理において破損したファイルへの対処を行い、破損ファイル対応装置を正常起動させる。
【００２６】
次に、管理情報読み込み部４１２の動作について図９を用いて説明する。
図９は、管理情報読み込み部４１２による処理の一例を示すフローチャートである。
フレームワーク２０３では、管理ファイルが破損しているか否かのチェックを管理情報読み込み部４１２にて行う。
管理情報読み込み部４１２は、まず読み込み対象となる管理ファイルの末尾に記載されているチェックサムを取得する（Ｓ９０１）。このチェックサムは、後述する管理情報書き込み部４１３にて追加されたものである。管理情報読み込み部４１２は、この値を用いて動作確認を行う。なお、チェックサムは、誤り検出符号の一例である。
次に、管理情報読み込み部４１２は、読み込む対象となる管理ファイルの内容からチェックサムを計算する（Ｓ９０２）。
そして、管理情報読み込み部４１２は、管理ファイルが破損していないかを調べるために、Ｓ９０１で取得したチェックサムと、Ｓ９０２で計算したチェックサムとが一致するか否かを調べる（Ｓ９０３）。
取得したチェックサムと、計算したチェックサムとが一致する場合、管理情報読み込み部４１２は、管理ファイルは破損していないと判断し、そのまま管理ファイルの内容を読み込み、処理を終了する（Ｓ９０４）。
【００２７】
取得したチェックサムと、計算したチェックサムとが等しくなかった場合、管理情報読み込み部４１２は、管理ファイルの破損が発生したと判断する。そして、管理情報読み込み部４１２は、破損を示すフラグファイルを作成するため、破損した管理ファイルが再作成可能なファイルであるか否かを判断する（Ｓ９０５）。より具体的には、管理情報読み込み部４１２は、破損した管理ファイルがライブラリディレクトリ３０３内に格納されている初期インストールに関する情報等を基に再作成可能なファイルであるか否かを調べる。
管理情報読み込み部４１２は、破損した管理ファイルが再作成可能であると判断した場合、再作成可能なファイルが破損していることを表示装置１０４に表示する（Ｓ９０６）。
そして、管理情報読み込み部４１２は、破損した管理ファイルの再作成を実施するか否かを判断するため、入力装置１０２を介したユーザからの入力を待つ（Ｓ９０７）。
管理情報読み込み部４１２は、入力装置１０２を介してユーザから破損した管理ファイルの再作成を実施する旨の入力を受信した場合、再作成可能なファイルが破損したことを示す段階１フラグファイル５０３を作成する（Ｓ９０８）。なお、段階１フラグファイル５０３の作成は、フラグファイル作成処理の一例である。
一方、管理情報読み込み部４１２は、入力装置１０２を介してユーザから破損した管理ファイルの再作成を実施しない旨の入力を受信した場合、処理を終了する。
【００２８】
一方、Ｓ９０５で、管理情報読み込み部４１２は、破損した管理ファイルが再作成不可能であると判断した場合、再作成不可なファイルが破損していることを表示装置１０４に表示する（Ｓ９０９）。
そして、管理情報読み込み部４１２は、初期化を実施するか否かを判断するため、入力装置１０２を介したユーザからの入力を待つ（Ｓ９１０）。
管理情報読み込み部４１２は、入力装置１０２を介してユーザから初期化を実施する旨の入力を受信した場合、再作成不可なファイルが破損したことを示す段階２フラグファイル５０４を作成する（Ｓ９１１）。なお、段階２フラグファイル５０３の作成は、フラグファイル作成処理の一例である。
管理情報読み込み部４１２は、フラグファイルを作成すると、管理ファイルの修復を行う必要があるため、破損ファイル対応装置を再起動する（Ｓ９１２）。これは、破損ファイル対応装置が起動処理中に対処を行うためである。
なお、本実施形態では、管理情報読み込み部４１２は、対象の管理ファイルに記載されたチェックサムと、対象の管理ファイルの内容から計算したチェックサムとの比較基づいて管理ファイルの破損の有無を判断するようにしたが、これに限る必要はない。例えば、フレームワーク２０３は、ファイルのインストール等の処理を監視し、監視の結果、インストール処理が正常に終了しなかった場合等にファイルが破損したと判断するようにしてもよい。なお、上記のファイル破損の判断は、破損ファイルの検知処理の一例である。
【００２９】
次に、管理情報書き込み部４１３の動作について図１０を用いて説明する。
図１０は、管理情報書き込み部４１３による処理の一例を示すフローチャートである。
管理情報書き込み部４１３は、まず管理ファイルに書き込む内容からチェックサムを計算して取得する（Ｓ１００１）。Ｓ１００１で計算されたチェックサムは、図９で前述したように、管理情報読み込み部４１２が読み込み時の内容から取得するチェックサムと比較してファイルが破損しているか否かを調べるために利用される。
次に、管理情報書き込み部４１３は、書き込む内容をファイルに書き込む（Ｓ１００２）。
そして、管理情報書き込み部４１３は、ファイルの末尾にＳ１００１で計算して取得したチェックサムを書き込む（Ｓ１００３）。
このように、フレームワーク２０３は、管理情報書き込み部４１３により破損チェックに利用するチェックサムを埋め込み、その後、管理情報読み込み部４１２により、埋め込まれたチェックサムを利用したファイル破損のチェックを行っている。これにより、フレームワーク２０３は、破損ファイル対応装置が管理ファイルの破損により動作しない状態になることを防いでいる。
【００３０】
次に、アプリケーション監視部４１１の動作について図１１を用いて説明する。
図１１は、アプリケーション監視部４１１による処理の一例を示すフローチャートである。
フレームワーク２０３は、アプリケーション２０４の状態管理を行っている。そのため、アプリケーション監視部４１１は、アプリケーション２０４が破損している等の異常を検知することができる。なお、アプリケーション２０４の破損等の異常検知は、検知処理の一例である。アプリケーション監視部４１１は、アプリケーション２０４の動作中に例外が発生したことを検知し、その対処を行う。
アプリケーション監視部４１１は、アプリケーション２０４の異常を検知すると、そのアプリケーション２０４が再インストール可能であるか否かを判断する（Ｓ１１０１）。より具体的には、アプリケーション監視部４１１は、Ｓ１１０１で異常を検知したアプリケーション２０４がバンドルディレクトリ３０２又はネットワーク上に格納されているアプリケーション２０４であれば再インストール可能であると判断する。
【００３１】
アプリケーション監視部４１１は、異常が発生したアプリケーション２０４が再インストール可能であると判断した場合、表示装置１０４を介して再作成可能なファイルが破損していることをユーザに通知する（Ｓ１１０２）。
そして、アプリケーション監視部４１１は、再作成を実施するか否かを判断するため、入力装置１０２を介したユーザからの入力を待つ（Ｓ１１０３）。
アプリケーション監視部４１１は、入力装置１０２を介してユーザから再作成を実施する旨の入力を受信した場合、再作成可能なファイルが破損したことを示す段階１フラグファイル５０３を作成する（Ｓ１１０４）。なお、段階１フラグファイル５０３の作成は、フラグファイル作成処理の一例である。
一方、アプリケーション監視部４１１は、異常が発生したアプリケーション２０４が再インストール不可能であると判断した場合、表示装置１０４を介して再作成不可なファイルが破損していることをユーザに通知する（Ｓ１１０５）。
そして、アプリケーション監視部４１１は、初期化を実施するか否かを判断するため、入力装置１０２を介したユーザからの入力を待つ（Ｓ１１０６）。
アプリケーション監視部４１１は、入力装置１０２を介してユーザから初期化を実施する旨の入力を受信した場合、再作成不可なファイルが破損したことを示す段階２フラグファイル５０４を作成する（Ｓ１１０７）。なお、段階２フラグファイル５０３の作成は、フラグファイル作成処理の一例である。
そして、アプリケーション監視部４１１は、異常が発生したアプリケーション２０４に対して対応するために破損ファイル対応装置の再起動を行う（Ｓ１１０８）。
このように、フレームワーク２０３は、アプリケーション監視部４１１によってアプリケーション２０４の破損を検知し、破損ファイル対応装置が動作しない状態になることを防いでいる。
なお、本実施形態では、アプリケーション監視部４１１は、破損したファイルの再作成を実施するか否か、キャッシュディレクトリの初期化を実施するか否かについて、入力装置１０２を介したユーザからの入力に基づいて判断するようにした。しかし、これに限る必要はない。例えば、アプリケーション監視部４１１は、予め定めておいた設定に従って、前記再作成及び前記初期化を実施するか否かを判断するようにしてもよい。
【００３２】
＜その他の実施形態＞
また、本実施形態は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００３３】
以上、上述した各実施形態によれば、復元させることができるファイルが破損した場合、リソースを圧迫することなく、かつ、キャッシュにあるユーザデータを削除せずに破損したファイルを復元させることができる。また、復元させることができないファイルが破損した場合であっても、システムが起動できなくなる問題に対して対処することができる。
【００３４】
以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
2014109821.tif 000003
【図２】
2014109821.tif 000004
【図３】
2014109821.tif 000005
【図４】
2014109821.tif 000006
【図５】
2014109821.tif 000007
【図６】
2014109821.tif 000008
【図７】
2014109821.tif 000009
【図８】
2014109821.tif 000010
【図９】
2014109821.tif 000011
【図１０】
2014109821.tif 000012
【図１１】
2014109821.tif 000013