JP3270216B2 - ファイル名検出方式 - Google Patents

ファイル名検出方式

Info

Publication number
JP3270216B2
JP3270216B2 JP25349593A JP25349593A JP3270216B2 JP 3270216 B2 JP3270216 B2 JP 3270216B2 JP 25349593 A JP25349593 A JP 25349593A JP 25349593 A JP25349593 A JP 25349593A JP 3270216 B2 JP3270216 B2 JP 3270216B2
Authority
JP
Japan
Prior art keywords
file
task
management table
name
directory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP25349593A
Other languages
English (en)
Other versions
JPH07105064A (ja
Inventor
剛 橋本
毅 鈴木
キャンベル デビッド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP25349593A priority Critical patent/JP3270216B2/ja
Priority to US08/294,960 priority patent/US5603020A/en
Priority to AU71622/94A priority patent/AU685476B2/en
Priority to DE4435751A priority patent/DE4435751B4/de
Publication of JPH07105064A publication Critical patent/JPH07105064A/ja
Application granted granted Critical
Publication of JP3270216B2 publication Critical patent/JP3270216B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Retry When Errors Occur (AREA)

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明は階層的な構造を持つファ
イルシステムを対象として処理を行うオペレーティング
システムに係り、更に詳しくはファイルをオープンした
後にはファイルの名前を用いず、ファイルオープン時に
ファイルに対して割り当てられたファイル記述子を用い
てファイルにアクセスするオペレーティングシステムに
おいて、ファイル記述子からファイルの名前を求めるフ
ァイル名検出方式に関し、またこのファイル名検出方式
を用いたプログラムのチェックポイント取得、およびリ
スタート処理方式に関する。
【０００２】
【従来の技術】本発明が対象とする階層的な構造を持つ
ファイルシステムの例を図１６に示す。同図において□
印がファイルであり、ファイルに至る中間ノードの○印
は全てディレクトリである。ファイルもディレクトリ
も、共にディバイス番号とｉノード番号で指定され、管
理される。ディバイス番号は、図１６においてディバイ
ス（ディスク）に付けられた番号１、または２であり、
ｉノード番号は各ディバイスの中でディレクトリ、また
はファイルに付けられた番号である。
【０００３】図１６においてファイルの名前はディレク
トリに記憶されている。例えばｘと言うファイルの名前
はディレクトリｅに記憶され、ｖと言うファイルの名前
はディレクトリｃ、およびｇに記憶されている。各ディ
レクトリの名前もそのディレクトリには記憶されず、直
前のディレクトリに記憶されている。例えばディレクト
リｅの名前はディレクトリｄに記憶されている。
【０００４】ディレクトリ相互間には双方向のポインタ
が存在するが、ファイルに対してはその直前のディレク
トリの側からのみポインタが存在し、逆方向のポインタ
は存在しない。従って例えばｅからｘをたどることはで
きるが、逆にｘからｅを求めることはできない。
【０００５】ルートノード／から各ファイルに至るノー
ドの並びを完全パス名と言う。例えばファイルｘの完全
パス名は／ａ／ｂ／ｄ／ｅ／ｘと表わされる。ファイル
ｖに対する完全パス名は２つある。／ａ／ｂ／ｇ／ｖ
と、／ａ／ｃ／ｖとの２つである。
【０００６】ファイルシステムの物理構造について説明
すると、前述のようにファイルもディレクトリもディバ
イス番号とｉノード番号で管理される。ディバイス番号
でディスクが特定され、ｉノード番号でディスク内の物
理的位置が確定される。
【０００７】１つのディスク全体は複数のブロックに分
割され、各ブロックの大きさは固定されている。一般に
第１ブロックは予備であり、第２ブロックはスーパーブ
ロックである。スーパーブロックにはファイルシステム
全体の管理データとして、例えば１つのブロックの大き
さ、すなわちバイト数や、ｉノードブロックの数などが
格納されている。
【０００８】第３ブロック以下にｉノードブロックとデ
ータブロックが格納される。普通は最初のｎブロックが
ｉノードブロックとして利用され、それ以降がデータブ
ロックとして利用される。１つのｉノードブロックには
複数のｉノードが格納され、ｉノード番号からそのｉノ
ードの物理的位置、すなわちブロックの位置とブロック
内での相対位置が求められるように構成されている。
【０００９】ファイルもディレクトリも実体は１つのｉ
ノードと、１つまたは複数のデータブロックから構成さ
れ、ｉノードにはディレクトリに対してもファイルに対
しても、管理情報としての所有者名、アクセス許可条
件、更新日付、そのｉノードの大きさ（バイト数）、そ
の他が格納され、続いてこのｉノードに対するデータが
格納されているデータブロックのブロック番号が１つ以
上格納されている。データブロック番号からそのブロッ
クの物理的位置は確定される。データブロック番号とｉ
ノードブロック番号とは全く独立に付けられている。
【００１０】ファイルのデータブロックにはファイルの
内容そのものが格納されている。これに対してディレク
トリのデータブロックには自分自身のｉノード番号、親
すなわち図１６で上のディレクトリのｉノード番号、子
供すなわち下のディレクトリのｉノードの名前とそのｉ
ノード番号が子供の数だけ格納されている。
【００１１】このように階層的なファイルを処理対象と
する従来のオペレーティングシステム、例えばＵＮＩＸ
においては、応用プログラム（タスク）はファイルの処
理に先立ってファイルの名前を指定してファイルのオー
プン処理をオペレーティングシステムに依頼する。例え
ば完全パス名／ａ／ｂ／ｄ／ｅ／ｘを指定して、ファイ
ルｘのオープンをオペレーティングシステムに依頼す
る。
【００１２】図１７は従来のファイルのオープン処理の
説明図である。同図において、応用プログラム８からフ
ァイルのオープン処理を依頼されたオペレーティングシ
ステムは、ファイルシステム３を検索して指定されたフ
ァイルを求め、以後このファイルにアクセスできるよう
な準備をして、指定されたファイルに対するファイル記
述子を応用プログラム８に返す。
【００１３】すなわち図１７のステップＳ１０におい
て、ファイルシステムが検索され、指定された名前のフ
ァイルが求められる。実際にはファイルのディバイス番
号とｉノード番号が求められる。続いてＳ１１で求めら
れたファイルに対するファイル管理テーブル４が作成さ
れ、指定されたファイルのディバイス番号とｉノード番
号がこのテーブルに格納される。
【００１４】オペレーティングシステム内では、Ｓ１１
で作成されたファイル管理テーブルへのポインタなど
が、Ｓ１２でタスクとファイルの対応管理テーブル５に
記憶される。このテーブルには、例えばファイルのどこ
までが読み書きされたかなどのデータも格納される。続
いてＳ１３でタスク管理テーブル６の内部のファイル記
述子管理テーブル７に１つのエントリが追加され、Ｓ１
２で作成されたタスクとファイルの対応管理テーブル５
へのポインタがそのテーブルに格納され、Ｓ１４でこの
追加されたエントリを示すファイル記述子、例えばエン
トリ番号がオープン要求元の応用プログラム（タスク
Ａ）８に通知されてオープン処理を終了する。
【００１５】図１７のオープン処理によってオープンさ
れたファイルに対して、応用プログラム８は以後ファイ
ル記述子を指定してファイルへの処理をオペレーティン
グシステムに依頼する。すなわちファイルがオープンさ
れた後にはファイルへのアクセスに際してファイルの名
前が用いられず、オペレーティングシステムは指定され
たファイル記述子を基にして制御表をたどり、ファイル
管理テーブル４を求め、ファイルにアクセスして指定さ
れた処理を実行する。オペレーティングシステムはファ
イルの名前を主記憶に記憶することなく処理を実行す
る。言い換えると、ＯＳはファイル記述子から、これに
対応するファイル名を求める手段を持たない。
【００１６】続いて階層的な構造を持つファイルシステ
ムにおけるファイル名検出と共に、本発明のもう１つの
対象となるプログラムのチェックポイント取得・リスタ
ート処理について、従来技術を説明する。チェックポイ
ント取得・リスタート処理とは、何らかの異常事態の発
生に備えて、プログラムの実行途中で途中の状態を退避
し、その後に異常が発生した場合、チェックポイント取
得時点からプログラムの再開が可能になるようにして、
最初から実行をやり直す無駄を省く方法である。
【００１７】またこの処理は異常発生に備えるだけでな
く、例えばプログラムの処理に長時間を要する場合にも
利用される。すなわちプログラムの処理が１日で終了し
ない場合に、途中でプログラムの実行を終了させてシス
テムを止め、翌日チェックポイント取得時点から実行を
再開すると言うような場合にも利用される。
【００１８】チェックポイント取得・リスタート処理
は、チェックポイント取得処理とリスタート処理とから
構成される。チェックポイント取得処理はプログラムの
実行途中でその時点の状態を退避する処理であり、退避
すべきデータとしてプログラムの内容とその管理情報
（例えば中断点の位置など）、およびファイルの内容と
その管理情報（ファイルのアクセス位置、アクセス状態
など）である。
【００１９】リスタート処理は、例えば異常状態が発生
した場合に、チェックポイント取得時に退避したプログ
ラムの内容とその管理情報、およびファイルの内容とそ
の管理情報を基にして、プログラムおよびその実行環境
を復元し、チェックポイント取得時点の状態から処理を
再開するものである。
【００２０】チェックポイント取得時に対象プログラム
がオープン中であったファイルの扱いに関する従来の技
術では、ファイルの属性によってその扱い方がユニーク
に決定されていた。すなわち、リスタート時にはチェッ
クポイント取得時のファイルの終端から書込みを始め
る、ファイルの内容をチェックポイント時に全て退避し
てリスタート時に復元する、システムはファイルを復元
しない、の３つの扱いのいずれかがユニークに適用され
ることになっている。
【００２１】そのためジョブ実行中には個々のファイル
別にデータ属性に関係なくチェックポイント取得時のフ
ァイルの扱いを変更することができなかった。特に長時
間のジョブを実行する場合には、ジョブ開始時とチェッ
クポイント取得時のシステム環境が大きく異なる可能性
があるため、ジョブ実行中にファイルの扱いを個々に変
更したくともそれができなかった。更に同一の属性のフ
ァイルでもチェックポイント対象プログラムの処理によ
って異なる扱いを適用したい場合にも、同一の扱いしか
することができなかった。
【００２２】図１６で説明したような階層的な構造を持
つファイルシステムを用いるオペレーティングシステム
における従来のチェックポイント取得処理においては、
チェックポイント取得対象プログラムが処理中のファイ
ルの名前が分からないため、処理中のファイルのディバ
イス番号とｉノード番号、その他ファイル復元に必要な
管理情報を退避し、リスタート処理時にファイルを復元
する方法を取っていた。
【００２３】
【発明が解決しようとする課題】図１６で説明した階層
的な構造を持つファイルシステムにおいては、ファイル
がオープンされた後にはファイル記述子によってファイ
ルにアクセスがなされ、ファイルの名前は一切用いられ
ることがなかった。
【００２４】ファイルをオープンしたのち、ファイルに
アクセスする（ファイルの内容を読んだり、ファイルに
データを出力する）だけなら、ファイル記述子を指定す
るだけで十分だが、時にファイルの名前も必要になる。
例えば、与えられたファイルの処理中にエラーが発生し
たので、「これこれというファイルの処理中にエラーが
発生しました」というように、ファイル名を含めたメッ
セージを出力したい場合がある。
【００２５】階層的なファイルシステムでは、オープン
中のファイルから、そのファイルを直接指しているディ
レクトリを逆に辿ることができない。オペレーティング
システムも、オープン中のファイルの名前を記憶してい
ない。従って、従来、ファイルのオープン後にファイル
名が必要な場合、応用プログラムは以下のいずれかの方
法をとった。 １）タスク内で動作するプログラムがファイルをオープ
ンする際に、ファイル名（例えば、完全パス名）とファ
イル記述子の対応を表に記憶しておき、ファイル名が必
要になった時、ファイル記述子をキーにしてこの表を検
索して、ファイル名を求める。 ２）上記のような対応表を作っていない既存のプログラ
ムにおいては、タスクがオープンする可能性のあるファ
イルを、ファイル記述子をキーにして検索し、ファイル
名を求める。
【００２６】いずれの方法にも問題がある。方法１）で
は、タスク内のプログラムが全てのファイル記述子とフ
ァイル名の対応を管理しなければならないため、その分
処理が複雑になる。オープンするプログラムとオープン
されたファイルを処理するプログラムが別になっている
場合には、この間でファイル記述子とファイル名の対応
の管理の仕方に関するインタフェースを決めておく必要
がある。特に、ファイル記述子だけを受け取って処理を
していた既存のプログラムが、あとで（機能追加など
で）ファイル名が必要になった場合、他プログラム（オ
ープンしたプログラム）も含めてファイル名とファイル
記述子の対応を管理するように変更する必要がある。若
し、他プログラムの修正が不可能なら（例えば、他プロ
グラムが第３者のプログラムで、ソースプログラムが入
手できない場合）、この方法は適用できない。
【００２７】上述した方法２）では、タスクが処理する
可能性のある全てのファイル（そのタスクがオープンし
たファイル及び親タスクがオープンしたファイル）を全
て検索する必要があり、タスクの起動条件を知らない限
り、ファイルシステム全体を検索することになり、探索
時間が増大する。
【００２８】全てのファイルについて、ファイル記述子
から知ることが可能なキーとファイル名の対応を記録し
た表を事前に作っておけば検索は高速にできるが、この
表が常に正しくなるように管理することは、タスク内の
プログラムでは原理的に不可能である。すなわちあるタ
スク内のプログラムが、別のタスクがオープンしたファ
イルの名を知ることはできない。オペレーティングシス
テムならこのような管理を行うことは可能であるが、階
層的ファイルシステムにより実現される長い名前を記録
するための処理時間やディスク領域の無駄が大きいこと
を初めとする実装上の困難がある。
【００２９】ファイル記述子からファイル名を求める一
般的且つ高速な機構があれば、動作中のタスクの状態表
示処理やタスクのチェックポイント取得リスタート処理
に際してオープン中のファイルの名前を知る処理などに
も容易に適用することができる。
【００３０】次にチェックポイント取得・リスタート処
理に関する問題点について説明する。前述のようにチェ
ックポイント取得時およびリスタート時におけるファイ
ルの扱い方法は、例えばファイルのデータ属性によって
ユニークに決定され、ジョブの実行中にそれを変更する
ことはできなかった。
【００３１】特に長時間ジョブを実行する場合には、ジ
ョブ開始時に必要なファイル容量の見通しがたたずには
ファイル容量が利用可能なストレージの容量以上になる
こともあり、ジョブ実行中にファイルの扱いを個々に変
更する機能が望まれていた。また、同一の属性のファイ
ルでもチェックポイント対象プログラムの処理によって
は異なる扱いが必要であっても、同一の扱いになってい
た。
【００３２】最近のスパコン分野の技術の発展に伴い、
長時間ジョブ（例えば数日）の実行を行うことも稀では
ない。この分野では、チェックポイント取得対象ファイ
ルのファイル容量がジョブ実行前の予測に反して増加す
ることもありうる。このような場合、従来方法では、チ
ェックポイント取得及びリスタート処理におけるファイ
ルの取扱い方法が固定されているため、とにかくストレ
ージの容量を増加するしかなく、増加させることができ
なければ、チェックポイント取得時に容量不足で処理が
できなくなってしまう。
【００３３】ジョブの実行途中で、対象ファイルのファ
イル容量を調べ、もし実装されているストレージの容量
以上に大きくなる可能性が出てくれば、例えば、当初フ
ァイルの内容を退避することを指定していても、この指
定を止め、ファイルの内容は退避しないように指定し、
別の手段で磁気テープに退避する、といったことができ
れば、チェックポイント取得リスタート処理の適用範囲
が広がる。
【００３４】チェックポイント取得・リスタート処理に
関する従来技術について更に次の３つの問題点を説明す
る。第１の問題点は、従来技術ではチェックポイント取
得処理を行うシステムとリスタート処理を行うシステム
を変えることは困難であり、現実的には不可能に近いと
言う問題点である。
【００３５】あるシステム上でプログラムを実行してチ
ェックポイントを取得し、リスタート処理は別システム
で行いたい場合、「チェックポイントを取得したシステ
ム」と「リスタート処理を行うシステム」では、ｉノー
ド番号は一般的に異なるであろうし、ディバイス番号も
異なる可能性がある。
【００３６】従って、ファイルの管理情報として、「デ
ィバイス番号とｉノード番号」その他を退避する従来の
方法では、「チェックポイント取得」システムと「リス
タート処理」システムを変えることができない。システ
ムを変更するには、何らかの方法でｉノード番号（及び
ディバイス番号）を移行先システムに合うように変更す
る必要がある。
【００３７】例えば、あるシステムでチェックポイント
を取得しておいて、予想以上に時間がかかるから、性能
の高い別システムでチェックポイント取得時点から再実
行したい、と考えても、このようなことは簡単にはでき
ない。
【００３８】第２の問題点は、チェックポイント取得の
タイミングによっては一時ファイル、すなわち名前のな
い一時ファイルの退避と復元がうまく行かない場合があ
り、単にプログラムの外からコマンドを与える方法では
チェックポイントの取得処理を正常に行うことができな
い場合があると言うことである。
【００３９】ここで一時ファイルとは、プログラムの実
行時に一時的に使用し、プログラムの実行後には、ファ
イルシステムから削除するファイルのことである。不要
になったファイルを適当な時点で削除しないと、ゴミと
してファイルシステムに存在し、ディスクの利用可能な
スペースを減らす原因になる。
【００４０】名前の無い一時ファイルとは、ファイルを
オープンした後に、ｕｎｌｉｎｋ関数を呼び出して、オ
ペレーティングシステムに一時ファイルとしての宣言を
する。ｕｎｌｉｎｋされたファイルは、その時点以降は
ファイル名（パス名）でのアクセスはできなくなり（フ
ァイル記述子によるアクセスは可能）、そのファイルの
クローズ時に、ファイルシステムから自動的に削除され
る。
【００４１】従来技術の方法では、チェックポイント取
得時に、ｕｎｌｉｎｋされているか否かを調べる。ｕｎ
ｌｉｎｋされていれば、ファイルの管理情報と同時にフ
ァイルの内容を退避する。リスタート時には、任意の名
前でファイルをオープンし（ｕｎｌｉｎｋされているか
らファイルの名前は何であっても構わない）、退避情報
（ファイルの内容と管理情報）を用いてファイルを復元
し、同時にｕｎｌｉｎｋする。こうして、一時ファイル
（名前の無い一時ファイル）が復元できる。尚、このよ
うな一時ファイルは、従来技術でも、仮のファイル名を
指定して内容を復元する（ディバイス番号とｉノード番
号は用いない）。
【００４２】しかしながら、前述のようにチェックポイ
ント取得のタイミングによってはリスタート処理をうま
く行うことができない。例えば図１８においてのファ
イルのオープンと、のｕｎｌｉｎｋの間のの処理１
の時点でチェックポイントが取得され、でファイル処
理が終了してこのファイルが削除された後に、の処理
３の時点でリスタート処理を行おうとしても、うまくリ
スタートを行うことができない。
【００４３】即ち、チェックポイントを取得した時点で
は、ｕｎｌｉｎｋされていないので、チェックポイント
取得プログラムは、一時ファイルという認識ができず、
一般的なファイルとして処理する（従来の方法では、フ
ァイルのアクセス位置などの情報を退避する）。しかる
に、その後ｕｎｌｉｎｋされ（一時ファイルとして宣言
され）、ファイルのクローズ処理において、このファイ
ルはファイルシステムから削除される。その後リスター
ト処理が実行される。各種管理情報を用いて、ファイル
のアクセス状態をチェックポイント取得時点に復元しよ
うとしても、ファイルそのものがもはや存在しないか
ら、ファイルの復元処理を正常に行うことができない。
【００４４】この場合、本来のファイル（処理すべき一
時ファイル）は存在しない。しかし、「ディバイス番号
とｉノード番号」は別のファイルに割り当てられている
可能性がある。全く別のプログラムがリスタートの再開
前に実行され、あるファイルをファイルシステムに作成
したとするとそのファイルにｉノード番号が割り当てら
れる。このｉノード番号が、まさに先程削除されたファ
イルのｉノード番号と一致する可能性がある。
【００４５】つまり、本来のファイル（ｏｐｅｎで割
り当てられたファイル）は存在しないが、「ｉノード番
号とディバイス番号」がたまたま一致するファイルはあ
るかも知れないということである。
【００４６】そして、リスタート処理プログラムが「デ
ィバイス番号とｉノード番号」に基づいてファイルを復
元する限り、「ｉノード番号をチェックすれば」ファイ
ルが削除されているか否かは判断可能であり、何らかの
処置をすることができる。しかし、全く別のファイルが
割り当てられている場合は、「リスタート処理」は、そ
のことを知る手掛かりがないので、正常に処理したと判
断するしかなく、対象プログラムの実行を再開すること
になる。
【００４７】上記のようなタイミングでチェックポイン
ト取得・リスタート処理を行うと別の問題、即ち「名前
無しファイルであっても、同一のファイル名でファイル
を復元しないと正常に処理されない」といった問題も生
じる。
【００４８】つまり、オープンしたあと、ｕｎｌｉｎｋ
でファイル名（パス名）を指定しているから、リスター
ト時に、オープンした時と同じファイル名を指定しない
と、再実行時のｕｎｌｉｎｋが失敗してしまう。
【００４９】尚、「チェックポイントを任意の点で取得
し、かつその時点で処理を中断し、後で（翌日）、チェ
ックポイント取得時点から再開する」方法をとれば、こ
のような問題を回避できるが、異常事態に備える方法と
しては不十分である。
【００５０】従来方法では、名前付の一時ファイルを用
いれば、上述した問題は一応回避できるが、新たな問題
が生じる。ここで名前付の一時ファイルとは、システム
の運用規約に基づき、あるディレクトリの元に作成され
たファイルは全て一時ファイルとみなすものである。す
なわち、システムの立ち上げ時あるいは、適当な時にシ
ステムの運用者が、名前付の一時ファイルを全て削除
し、ディスクに不要なファイルがないようにするもので
ある。
【００５１】従って、チェックポイントリスタート処理
をするプログラムが実行中の間は、名前付の一時ファイ
ルは削除しないようにし、その実行が全て完了した時点
で、名前付の一時ファイルを削除するようにすれば上述
したような問題は回避できる。しかし、チェックポイン
ト処理をしているプログラムが利用している名前付ファ
イルだけでなく、他の利用者が利用している名前付一時
ファイルも、その間削除されないでファイルシステムに
残ってしまうことになり、ディスク容量を圧迫する可能
性がある。こういう事態が発生したら、他の利用者は、
自らが使用していた名前付の一時ファイルを削除すると
いう余分の作業が必要になる。
【００５２】第３の問題点は、チェックポイント取得・
リスタート処理のうちで特にリスタート処理プログラム
は、例えばオペレーティングシステムのカーネルで実現
する必要があり、ＯＳの規模の増大は必要なメモリ量を
増加させ、また信頼性の低下につながると言う問題点で
ある。
【００５３】ファイルの物理的な管理情報に基づく従来
方法によるリスタート処理プログラムでは、「オペレー
ティングシステムが管理しているファイルに関するＯＳ
内の各種制御表を復元する必要がある。ＯＳの管理して
いる制御表の再生はＯＳのカーネルで行う必要がある。
従って、リスタート処理プログラムは、オペレーティン
グシステムのカーネルの機能追加により、乃至これを改
造して行う必要があるため、ＯＳののカーネルの規模が
増大する。
【００５４】ＯＳのカーネルのバグはシステムダウンに
つながる可能性があるため、ＯＳの規模の増大はシステ
ムの信頼性の低下につながる。また、ＯＳのカーネルは
メモリに常駐する必要があるため、必要メモリ量が増大
するという欠点がある。本発明は、ファイルがオープン
された後にもファイルに割り当てられたファイル記述子
からファイルの名前を検出し、またそのようにして検出
されるファイルの名前を用いて個々のファイル毎にチェ
ックポイント取得・リスタート処理におけるファイルの
取り扱い方法を指定可能とすることを目的とする。
【００５５】
【課題を解決するための手段】図１は本発明の原理構成
ブロック図である。同図はルートノードから中間ノー
ド、例えばディレクトリを経て、最終ノードとしてのフ
ァイルに至る階層構造を持つファイルシステムを有し、
該ファイルの使用に先立って行われるオープン処理時に
ファイルに割り当てられるファイル記述子の指定によっ
て、そのファイルをタスク、例えば応用プログラムが使
用可能となるオペレーティングシステムにおける、ファ
イル記述子からファイルの名前を求めるファイル名検出
方式の原理構成ブロック図である。
【００５６】図１において中間ノード記憶手段２１は、
ファイルのオープン処理時にそのファイルの直前の中間
ノード（ディレクトリ）を記憶するものであり、中間ノ
ード検出手段２２は中間ノード記憶手段２１の記憶内容
に応じて、ファイルに割り当てられたファイル記述子に
基づいてそのファイルの直前の中間ノードを検出してタ
スク（応用プログラム）に通知するものである。これに
よってファイルを使用しているタスクはその直前の中間
ノードの格納内容をファイルシステムから読み込んで、
そのファイルの名前を求めることになる。
【００５７】
【作用】図１７で説明したように、従来のファイルのオ
ープン処理においては応用プログラムに対してファイル
記述子が通知され、オープンされたファイルに対しては
以後そのファイル記述子を用いてアクセスが行われる。
本発明においては中間ノード記憶手段２１として、例え
ばオープンされたファイルの直前の中間ノード、例えば
ディレクトリに対するディバイス番号とｉノード番号と
を記憶する、ディレクトリに対するファイル管理テーブ
ルが図１７で説明したオペレーティングシステムに追加
される。このディレクトリに対するファイル管理テーブ
ルの追加は、ファイルのオープン処理時に行われる。
【００５８】ファイルのオープン後にファイルの名前が
必要になった時点で、オペレーティングシステム内の中
間ノード検出手段２２によって、ファイルに割り当てら
れたファイル記述子に基づいてディレクトリに対するフ
ァイル管理テーブルの記憶内容に応じてファイルの直前
の中間ノード（ディレクトリ）が検出され、例えばディ
レクトリに対するファイル管理テーブルを指すタスクと
ファイルの対応管理テーブルが新たに作成され、更にこ
のタスクとファイルの対応管理テーブルを指すポインタ
などを格納したファイル記述子管理テーブルの新しいエ
ントリが追加され、追加されたエントリのエントリ番号
がディレクトリに対するファイル記述子としてタスクに
通知される。
【００５９】その結果、ファイルを使用しているタスク
はこのディレクトリに対するファイル記述子を用いて、
そのディレクトリの格納内容をファイルシステムから読
み込み、そのディレクトリの下のファイル、すなわち使
用中のファイルの名前を求めることになる。
【００６０】すなわち、本発明によればファイル記述子
とｉノード番号の対応を求めておき、ファイルの属する
ディレクトリを獲得することによりこのディレクトリの
中で前記ｉノード番号を用いてファイルの名前を検索す
ることによりファイル記述子よりファイル名を求めるこ
とができる。
【００６１】本発明においては、例えばオペレーティン
グシステムにおいて別のタスクが使用しているファイル
のファイル記述子を含む情報を複写するファイル記述子
情報複写手段を備えて、別のタスクが使用しているファ
イルの名前を求めることも可能である。
【００６２】更に本発明においては、プログラムのチェ
ックポイント取得・リスタート処理において、チェック
ポイント取得時に対象プログラムがオープンしていた個
々のファイルに関してファイルの名前に基づいてチェッ
クポイント取得時のファイル退避方法、リスタート時の
ファイル復元、または再オープンの方法について個別に
指定することが可能となる。これは対象プログラムがオ
ープンしている個々のファイルの名前を前述のファイル
名検出方式によって検出することが可能となったためで
ある。
【００６３】以上のように本発明によればオープンされ
ているファイルの名前をファイル記述子から求めること
が可能となる。したがって、エラー時、チェックポイン
ト取得時にファイル名を例えば表示可能である。
【００６４】
【実施例】図２は本発明におけるファイルオープン処理
実施例の説明図である。同図ではオペレーティングシス
テム内に図１７の構成要素に加えてディレクトリに対す
るファイル管理テーブル２８が追加され、タスクとファ
イルの対応管理テーブル５に、ファイル管理テーブル４
とディレクトリに対するファイル管理テーブル２８との
両方を指すポインタが格納されている点が異なる。ディ
レクトリに対するファイル管理テーブル２８には図１６
のファイルｘの直前のディレクトリ、すなわちｅのディ
バイス番号として２、ｉノード番号として２が記憶され
る。
【００６５】ファイルのオープン処理においては、まず
Ｓ３０でファイルシステム３が検索され、指定された名
前のファイル、およびこのファイルを直接指すディレク
トリが求められる。すなわちそれぞれのディバイス番号
とｉノード番号が求められる。そしてＳ３１で求められ
たファイルおよびディレクトリに対して、それぞれファ
イル管理テーブル４、およびディレクトリに対するファ
イル管理テーブル２８が作成され、それぞれに対応する
ディバイス番号とｉノード番号が記憶される。
【００６６】続いてＳ３２でタスクとファイルの対応管
理テーブル５が作成され、ファイル管理テーブル４、お
よびディレクトリに対するファイル管理テーブル２８へ
のポインタなどが記憶される。Ｓ３３，Ｓ３４の処理は
図１７におけるＳ１３およびＳ１４の処理と同様であ
り、Ｓ３４でファイル記述子管理テーブルのエントリ番
号がファイル記述子として応用プログラム（タスクＡ）
８に通知されて、オープン処理を終了する。
【００６７】図２のファイルオープン処理はファイルシ
ステムの階層性がファイル名の形式としての完全パス名
によって表わされ、ディレクトリがファイルの一種とし
て扱われ、ファイル記述子がタスク毎に、例えばファイ
ル記述子管理テーブルのエントリ番号として与えられ、
ファイル記述子によってディレクトリ内でのファイルの
検索キーとしてのディバイス番号とｉノード番号が得ら
れるオペレーティングシステムにおける処理の例であ
る。このようなオペレーティングシステムの典型例とし
てＵＮＩＸがある。
【００６８】図３はオープンされたファイルの名前が必
要になった時にファイル記述子からファイル名を求める
実施例の説明図である。同図においては、図２で求めら
れたディレクトリに対するファイル管理テーブル２８を
直接ポイントするタスクとファイルの対応管理テーブル
２９が新たに作成され、このタスクとファイルの対応管
理テーブル２９を指すポインタなどが格納された新しい
エントリがファイル記述子管理テーブル７に追加され
る。
【００６９】応用プログラム８は、例えばオープンされ
たファイルの処理中にファイルの名前を知る必要がある
時にはＳ３６〜Ｓ３９の処理によってその名前を求め
る。まずＳ３６においてファイル記述子を指定してｉノ
ード番号獲得手段を用いてファイルのｉノード番号を求
める。このｉノード番号獲得手段は既存の技術であり、
例えばＵＮＩＸではＦＳＴＡＴ関数を用いることにより
指定されたファイル記述子に対するｉノード番号が求め
られる。
【００７０】続いてＳ３７でファイル記述子を指定し
て、そのファイルの直前のディレクトリに対するファイ
ル記述子をディレクトリ獲得処理によって求める。この
ディレクトリ獲得処理の詳細については次の図４で説明
する。
【００７１】続いてＳ３８で、求められたディレクトリ
に対するファイル記述子を指定してディレクトリ読込み
手段を用いてディレクトリの内容を読み込む。このディ
レクトリ読込み手段も既存の技術であり、ＵＮＩＸでは
ＲＥＡＤＤＩＲ関数を用いて指定されたファイル記述子
に対するディレクトリの内容が主記憶に読み込まれる。
最後にＳ３９で読み込まれたディレクトリの内容を検索
し、Ｓ３６で求められたｉノード番号に対するファイル
の名前（直前のディレクトリに対する相対的な名前で、
完全パス名ではない。）が求められ、処理を終了する。
【００７２】Ｓ３９ではファイルと１対１に対応するｉ
ノード番号に基づいて、直前のディレクトリに対する相
対的なファイル名が求められるため、図１６のファイル
ｘの直前のディレクトリｅのように、その下に他のファ
イルｙがある場合にもＳ３６で求められたｉノード番号
が例えばファイルｘに対応することによって、ファイル
名ｘが求められる。なお、一般にファイルの直前のディ
レクトリの下には、このように複数のファイルが存在す
る。
【００７３】図４は図３のＳ３７、すなわちディレクト
リ獲得処理の詳細フローチャートである。同図において
処理が開始されると、Ｓ４１において応用プログラム８
によって指定されたファイル記述子に対するファイル記
述子管理テーブルのエントリ、およびタスクとファイル
の対応管理テーブル５がたどられ、図２のオープン処理
のＳ３１において作成されたディレクトリに対するファ
イル管理テーブル２８が求められる。なお、図４におい
て応用プログラム８からオペレーティングシステムに指
定されるファイル記述子を示す矢印はディレクトル獲得
要求に対応するものである。そしてＳ４２で、このディ
レクトリに対するファイル管理テーブル２８に直接アク
セスできるように新しくタスクとファイルの対応管理テ
ーブル２９が作成され、Ｓ４３でタスク管理テーブル６
の内部のファイル記述子管理テーブル７にエントリが１
つ追加され、新しく作られたタスクとファイルの対応管
理テーブル２９を指すポインタがそこに格納され、Ｓ４
４で追加されたファイル記述子管理テーブルのエントリ
番号がディレクトリに対するファイル記述子として応用
プログラム８、すなわちディレクトリ獲得要求元に通知
されて処理を終了する。
【００７４】図３、および図４のフローチャートを用い
てファイルの属するディレクトリ、すなわち図１６にお
いてファイルの直前のディレクトリが求められ、またそ
のディレクトリに対応する相対的な名前としてのファイ
ル名、例えばディレクトリｅに対する相対的な名前とし
てのｘとが求められると、階層的なファイルシステム内
でのｘに対する完全パス名を求めることができる。
【００７５】図５はこの完全パス名を求めるプログラム
の例である。図５においてディレクトリに対するファイ
ル記述子が与えられると、そのディレクトリにカレント
ディレクトリを移す関数、ＵＮＩＸではＦＣＨＤＩＲ関
数と、カレントディレクトリの名前を求める関数ＧＥＴ
ＣＷＤ関数とを組み合わせて完全パス名を求めることが
できる。すなわちカレントディレクトリを一時的に今の
処理対象となっているファイル記述子が属するディレク
トリに移し、カレントディレクトリの名前を求めるプロ
グラムによりディレクトリの名前が求められ、そのディ
レクトリの名前とディレクトリに相対的なファイル名と
を文字列としてつなぐことにより、完全パス名が求めら
れる。なお一般にディレクトリが特定されればファイル
システムも特定されるために、本実施例においては複数
のファイルシステムを検索する必要がない。
【００７６】以上の説明では、ある１つの応用プログラ
ムが自プログラムがオープンしていたファイルの名前を
求めるファイル名検出方式を実施例として説明したが、
本発明においては自プログラムとは異なる他のプログラ
ムがオープンしているファイルの名前を求めることも可
能である。
【００７７】図６はそのような別タスクがオープンして
いるファイル名を求める処理の説明図である。同図にお
いてはタスクＡ８がオープンしているファイルの名前
を、タスクＡ８と異なるタスクＢ４５が求める処理につ
いて説明する。
【００７８】タスクＡ８側では図２で説明したオープン
処理が行われ、ファイル管理テーブル４と共にディレク
トリに対するファイル管理テーブル２８が作成され、こ
れらの管理テーブルを指すポインタなどが格納されたタ
スクとファイルの対応管理テーブル５、およびこのテー
ブル５を指すポインタなどを格納したファイル記述子管
理テーブル７のエントリが作成され、テーブル７のエン
トリ番号としてのファイル記述子がタスクＡに返された
状態となっている。
【００７９】タスクＢ４５側で処理が開始されると、ま
ずＳ５０でタスク名、ここではタスクＡを基にしてその
タスクのファイル記述子管理テーブル７が求められ、Ｓ
５１で求められたファイル記述子管理テーブルの内容が
ファイル記述子複製要求元、すなわちタスクＢ側のタス
ク管理テーブル４６の内部にファイル記述子管理テーブ
ル４７として複写され、Ｓ５２で複写されたファイル記
述子管理テーブル４７が指す他の制御表としてのタスク
とファイルの対応管理テーブル４８がタスクＢ側に新し
く作られ、このテーブル４８からタスクＡ側のファイル
管理テーブル４、およびディレクトリに対するファイル
管理テーブル２８にアクセスできるようにポインタなど
が張られる。そしてＳ５３で要求元タスク、ここではタ
スクＢに、複写されたファイル記述子管理テーブル４７
のエントリ番号がファイル記述子として通知され、タス
クＢ４５はタスクＡ８がオープンしているファイルにそ
の記述子を用いて以後アクセスすることが可能となる。
【００８０】続いて本発明の内容、すなわちファイル記
述子からファイル名を検出するファイル名検出方式を応
用するチェックポイント取得・リスタート処理の実施例
について説明する。前述のように、プログラムのチェッ
クポイント取得・リスタート処理とは、例えば異常事態
の発生に備えて、プログラムの実行途中で途中の状態を
退避し、異常が発生した場合などにチェックポイント取
得時点からプログラムを再開できるようにする処理であ
る。本発明を用いれば、このチェックポイント取得・リ
スタート処理において、チェックポイント採取要求者は
チェックポイントを取得するにあたって対象プログラム
がオープンしていた個々のファイルに関してファイルの
名前に基づいてチェックポイント取得時のファイルの退
避方法、リスタート時のファイルの復元、または再オー
プンの方法について指定することが可能となり、従来技
術で説明した多くの問題点を解決することができる。
【００８１】図７はチェックポイント取得・リスタート
処理の動作環境を説明するシステム構成図である。同図
においてチェックポイント取得・リスタートサービス要
求者は、端末５５を介してＣＰＵ５６に対してコマンド
を投入することによって、サービスを要求する。この要
求に対応して、まずＣＰＵ５６の内部のチェックポイン
トサービス提供プログラム５７が起動され、プログラム
５７は必要に応じてチェックポイント取得・リスタート
時のファイルの扱いを格納したファイル（ＣＰＲファイ
ル）５８の内容を参照し、チェックポイント取得・リス
タート対象プログラム５９がオープンして現在読み書き
中のファイル群６０のデータを、オペレーティングシス
テム６１を介してチェックポイントデータ退避域６２に
退避させ、リスタート時に備える。なお、チェックポイ
ント取得リスタート対象プログラム５９そのものもチェ
ックポイントデータ退避域６２に退避する。リスタート
処理においては、リスタートサービス提供プログラム６
３が、チェックポイント・データ退避域６２に退避され
ているデータを対象プログラムが読み書き中のファイル
群６０に復元し、チェックポイント取得・リスタート対
象プログラム５９そのものも復元し処理が再開される。
【００８２】図８はチェックポイント取得・リスタート
処理におけるファイル処理方法の指定の実施例である。
図７で説明したように、チェックポイント取得・リスタ
ートサービス要求者は、端末５５を介してＣＰＲコマン
ドによってまずチェックポイント取得処理を起動する。
そのコマンドのパラメータには、オープン中であったフ
ァイルの扱いをファイルの名前に基づいて指定すること
ができる。必要に応じてパラメータを事前にＣＰＲファ
イルと呼ばれるファイルに格納しておき、コマンド投入
時にはパラメータ指定を省略することもできる。従って
個々のファイル毎にチェックポイント取得・リスタート
処理における扱いを指定することができ、この指定は一
般にジョブの実行開始からチェックポイント取得時まで
の間に行うことができる。
【００８３】図８においてチェックポイント取得・リス
タート処理におけるファイル処理方法の指定方式として
は４つの方式がある。まず第１の方式はセーブリストア
と呼ばれ、チェックポイント取得時にはファイルの内容
とアクセス状態を退避し、リスタート処理時にはその内
容とアクセス状態を基にファイルが復元される。復元時
のファイルの名前としては元の名前がそのまま用いられ
る。
【００８４】第２の方式はセーブコピーである。この方
式ではチェックポイント取得時にはファイルの内容とア
クセス状態が退避され、リストア処理時にその内容とア
クセス状態を用いてファイルが復元されるが、リスター
ト時に復元されるファイルは一時ファイルとして扱わ
れ、その名前は元の名前と一致してもしなくてもよい。
【００８５】第３の方式はアペンドである。この方式で
はチェックポイント取得時にはファイルの内容を退避す
ることなく、リスタート処理時にはアペンドモードで再
オープンされる。すなわちリスタート時にはファイルの
内容としてリスタート時の状態をそのまま継続し、ファ
イルに対するアクセス状態についてもリスタート時の状
態がそのまま引き継がれる。
【００８６】第４の方式はイグノアである。この方式で
はチェックポイント取得時には、ファイルの内容は退避
せず、アクセス状態（アクセス位置など）を退避し、リ
スタート処理時には、チェックポイント取得時に退避し
たアクセス状態で再オープンする。
【００８７】図９はプログラムのチェックポイントを取
得するチェックポイント取得タスクの処理の流れの説明
図である。同図においてチェックポイント取得タスク
は、チェックポイント取得対象としてのタスクグループ
の識別子、およびファイル名と、ファイルの退避・復元
に関する情報を基にして、対象タスクグループからチェ
ックポイントデータを取得する。ここで対象タスクグル
ープとはチェックポイント取得リスタート処理の対象と
なるプログラムのことであり、一般にこのようなプログ
ラムは１つの親タスクと１つ又は複数の子タスクや孫タ
スクからなる。親タスクと子タスクとの関係その他につ
いては、図１２〜図１４で詳述する。
【００８８】チェックポイントサービス要求者は、図７
の端末５５からチェックポイント取得コマンドをシステ
ムに投入することにより、チェックポイント取得タスク
を起動する。起動されたチェックポイント取得タスクは
以下の手順で処理を行う。
【００８９】チェックポイント取得タスクはまずＳ６５
においてコマンド解析（パラメータ解析）、およびＣＰ
Ｒファイル解析を行う。チェックポイント取得コマンド
にはチェックポイントを取得すべき対象タスクの識別子
が指定されている。またコマンドにおいて対象タスクが
処理中のファイルの退避・復元方法が指定されることも
あるが、場合によってはファイル毎の退避・復元方法は
前もってＣＰＲファイルと呼ばれるファイルに記述され
ていて、コマンドではそのファイル名を指定することも
できる。いずれにせよ、チェックポイント取得対象タス
クグループの識別子、ファイル名、およびそのファイル
の退避・復元方法に関する情報が得られる。
【００９０】図１０はこのコマンド解析、およびＣＰＲ
ファイル解析の詳細フローチャートである。同図におい
て、Ｓ７０でファイルの扱いに関するパラメータをＣＰ
Ｒファイルから取り出すことがＣＰＲコマンドに指定さ
れているか否かが判定され、指定されている時にはＳ７
１でＣＰＲファイルからファイルの扱いに関するパラメ
ータが得られ、指定されていない時にはＳ７２でＣＰＲ
コマンドからファイルの扱いに関するパラメータが得ら
れる。
【００９１】図１０の処理が終了すると、図９でチェッ
クポイント取得タスクはＳ６６の処理を行う。ここでは
対象タスクグループがストップ状態にされる。すなわち
対象タスクグループに属する全てのタスクがストップ状
態とされる。前述のように対象タスクグループが親タス
クと１つの子タスクとからなる場合には、この２つのタ
スクがストップ状態とされる。
【００９２】続いてチェックポイント取得タスクはＳ６
７の処理を行う。この処理では対象タスクグループの状
態採取が行われる。すなわち対象タスクグループに属す
るタスクの一覧（タスク識別子の一覧）を求めて、各タ
スクの状態の採取が行われる。タスクの状態とはそのタ
スクの仮想空間の内容（プログラムやデータの内容）、
およびＯＳの管理情報（実行を中断した命令の位置やレ
ジスタの内容など）を意味し、これらの情報は図７のチ
ェックポイントデータ退避域６２のファイルに退避され
る。
【００９３】その後チェックポイント取得タスクは、Ｓ
６８の処理として対象タスクグループがオープンしてい
るファイル状態の採取を行う。この処理では図２〜図６
で説明したファイル記述子からファイル名を検出する方
法が用いられる。
【００９４】図１１はこのファイル状態採取処理の詳細
フローチャートである。同図において対象タスクのタス
ク名に基づいて、Ｓ７５で図６で説明したファイル記述
子情報の複製処理が行われる。すなわち対象タスク側の
ファイル記述子管理テーブルがチェックポイント取得タ
スク側に複写され、これによって他のタスク、すなわち
対象タスクのファイル記述子情報が得られる。次にＳ７
６で図３〜図５で説明したファイル記述子からファイル
名を求める処理が行われ、ファイルに対する完全パス名
が求められる。すなわち複写されたファイル記述子管理
テーブルのエントリ番号に対応するファイル名として完
全パス名が求められ、ファイル記述子とファイル名の対
応データが得られる。最後にＳ７７でファイルからのチ
ェックポイントデータの取得処理が行われる。前述のよ
うにコマンド解析、およびＣＰＲファイル解析から、フ
ァイル名とファイルの内容の退避・復元方法、すなわち
チェックポイントデータの取得方法に関する指示が得ら
れ、その指示に基づいてチェックポイントデータの取得
処理が実行される。
【００９５】図１１の処理が終了すると図９でチェック
ポイント取得タスクはＳ６９の処理を行い、対象タスク
グループの実行終了、または再開が行われる。例えば１
日の業務の終了時にチェックポイント取得を行う場合に
は、ここで実行を終了させ、これに対して実行継続の必
要がある場合には実行が再開される。
【００９６】次に図９で説明を保留した親タスクと子タ
スクとについてその詳細を説明する。一般論として２つ
の処理を並行して行うときに、親タスクが子タスクを生
成して１つの処理を子タスク側に実行させる場合などに
用いられるものである。このように処理Ａを行うプログ
ラムと、処理Ｂを行うプログラムを別々のタスクとして
並行して実行することができる。
【００９７】処理Ａと処理Ｂとを並行して行うために
は、例えば親タスクは１つの子タスクを生成し、子タス
クは処理Ａを行い、親タスクは子タスクを生成した後に
処理Ｂを行うことができる。この場合処理Ａと処理Ｂと
が並行して実行されるために、処理効率が向上する。ま
た他の方法として親タスクが２つの子タスクを生成し、
２つの子タスクがそれぞれ処理Ａ、処理Ｂを行うように
してもよい。
【００９８】ＵＮＩＸでは、タスクの起動方法がやや複
雑である。すなわちＵＮＩＸにおいてはタスク起動まで
の処理が、第１に親タスクと同じタスク（子タスク）を
生成する機能と、第２に子タスクが自分自身を本来の処
理としてのプログラムＡに置き換えてそれを行う機能と
の２つに分かれる。すなわち別の処理（処理Ａ）を行う
プログラムを直接的に子タスクとして生成することはで
きず、タスクの生成そのものとしては、自分と同じ子タ
スクを生成すると言う方法しか用いることができない。
そこでまず親タスクと同じ子タスクを生成し、生成され
たタスクの中でプログラムＡを自分自身と置き換えて実
行するように依頼することが必要となる。
【００９９】図１２〜図１４はＵＮＩＸにおけるタスク
起動方法の詳細説明図である。まず図１２は処理Ａを子
タスクで行うようにするために作られる２つのプログラ
ムである。すなわち２つのプログラム７９および８０が
作られる。プログラム７９においては子タスクとして自
分自身が生成され、子タスクの生成結果の調査として親
タスクか子タスクかの判定が行われる。子タスクである
場合には子タスクとしての処理、すなわち自分自身を処
理Ａを行うプログラムと置き換えてそのプログラムを実
行し、親タスクである場合には親タスクとしての処理を
行う。プログラム８０は処理Ａを行うプログラムであ
る。
【０１００】図１３は親タスクと子タスクの実行時の状
態の説明図である。同図において親タスク８１側でのシ
ステムコールｆｏｒｋにより、親タスクと同じプログラ
ムが子タスク８２として生成されている。この処理によ
り子タスク（自分自身）が生成された直後には、図１３
に示すように２つの同じプログラムが別々の仮想空間の
内部に存在する。
【０１０１】親タスク、子タスクの両側で(1) の時点で
は２つのタスクは全く同じであり、どちらのプログラム
も(2) の命令から実行が開始される。この実行は独立し
て並行的に行われる。
【０１０２】ところが親タスク８１側では(2) において
親タスクと判定され、(3) の処理は実行されず、(4) の
処理が実行される。すなわち親タスクとしての処理が行
われる。これに対して子タスク８２側では(2) で子タス
クと判定され、(3) の処理、すなわち自分自身を処理Ａ
を行うプログラムで置き換え、そのプログラムの実行を
行う。(4) の処理は行われない。
【０１０３】図１４は子タスク８２側で自分自身を処理
Ａを行うプログラムで置き換え、それを実行している状
態を示す。最後にリスタート処理の流れについて図１５
を用いて説明する。図１５のＳ８５でリスタート処理の
準備として、リスタートすべきタスクグループの識別
子、およびチェックポイント取得時の管理情報などが得
られ、Ｓ８６で対象タスクグループがオープンしていた
ファイルの内容が復元される。ただしファイルへのアク
セス状態の復元は後述するＳ９３で行われる。
【０１０４】続いてＳ８７でＩＤ指定のタスク生成機能
（pidfork システムコール）を用いて、対象タスクグル
ープの親タスクの生成が行われる。ここでＩＤ指定のタ
スク生成機能は従来技術としてのタスク生成機能（for
k) を参考にして作成されるものであり、forkが新規の
タスク識別子の割り当てを行うのに対して、pidfork で
は与えられたタスク識別子のタスクが生成される。もし
も同一識別子を持つタスクが動作中の場合には、その実
行終了を待ってタスクの生成が行われる。
【０１０５】次にＳ８８で、現在処理中のタスクがＳ８
７で生成された親タスクか否かの判定が行われ、親タス
クでない場合にはＳ９５の処理に移行し、親タスクであ
る場合にはＳ８９の処理に移行する。
【０１０６】Ｓ８８で生成された親タスクと判定された
場合には、Ｓ８９でそのタスクが子タスクを持つか否か
が判定され、持つ場合にはＳ９０で前述のＩＤ指定のタ
スク生成機能（pidfork システムコール）を用いてその
子タスクが生成され、Ｓ９１でこのタスク、すなわち処
理中のタスクがＳ９０で生成されたタスクか否かが判定
され、Ｓ９０で生成されたものであるときにはＳ８９以
降の処理が繰り返される。この場合にはＳ９０で生成さ
れた子タスクがさらに子タスクを持つか、すなわちＳ８
７で生成された親タスクが孫タスクを持っているか否か
がＳ８９で判定される。
【０１０７】Ｓ９１の判定結果が“ＮＯ”のときには、
Ｓ９２で未生成の子タスクを持つか否か、最初のループ
ではＳ８７で生成された親タスクがさらに別の子タスク
を持つか否かが判定され、持つときにはＳ９０以降の処
理が繰り返される。
【０１０８】これに対してＳ９２で未生成の子タスクを
持たないとき、およびＳ８９で子タスクを持たないと判
定された時には、Ｓ９３でそのタスクがオープンしてい
たファイルのアクセス状態の復元、タスクの状態復元
（ＯＳの管理情報の復元）、およびタスクの実行権の復
元が行われ、Ｓ９４でユーザ空間プログラムの実行途中
の回復機能（restore システムコール）によってこのタ
スクの仮想空間が対象タスクの内容で置き換えられる。
置き換えられたプログラムはストップ状態とされ、スト
ップ状態であることを示す信号の発信が行われる。
【０１０９】ここでユーザ空間プログラムの実行途中の
回復機能（restore)は、従来技術としての「プログラム
を仮想空間にロードしてそのプログラムを実行する機能
（exec) 」を参考にして作成されるシステムコールであ
り、execがプログラムの命令部、および初期化データを
仮想空間にロードしてプログラムの先頭から実行させる
のに対して、restore ではチェックポイント取得時に退
避した命令、およびデータが仮想空間に読み込まれ、そ
の後プログラムはストップ状態とされ、ストップ状態で
あることを示す信号が発信されて、処理が終了する。
【０１１０】Ｓ９３、およびＳ９４の処理は生成された
親タスクと全ての子タスクについてそれぞれ行われる。
すなわちリスタートすべきタスクグループのタスクの数
だけ、これらの処理が実行される。
【０１１１】Ｓ８８で生成された親タスクでないと判定
された時、すなわち前述のリスタートタスクに対して
は、Ｓ９５の処理が行われる。Ｓ９５では、対象タスク
グループに属する全てのタスクがストップ状態になるの
を待って、すなわち全てのタスクに対してＳ９４の処理
が終了するのを待った後に、未回復のタスクの状態、お
よびファイルの状態の復元が行われる。ここで未回復の
タスクの状態としては、例えばベクトルレジスタの内容
や、close on exec フラグがある。ベクトルレジスタの
内容が未回復にされていたのは実装上の問題であり、本
質的な問題ではない。またclose on exec フラグとは、
ファイル記述子を指定して「そのファイルに対してはex
ec機能実行時にクローズして下さい」とシステムに通知
があった場合に設定されるフラグであり、このフラグを
未回復にしていた理由はＳ９４でのrestore 機能を従来
技術としてのexecの機能にできるだけ近づけるためであ
るが、その詳細説明は省略する。
【０１１２】続いてＳ９５で対象タスクグループの実行
が再開され、対象タスクグループの親タスクの実行が終
了するのを待った後に、実行終了が行われる。以上、本
発明のファイル名検出方式を、チェックポイント取得・
リスタート処理に応用する実施例を述べた。ＵＮＩＸラ
イクのＯＳにおいてはファイルの属性が１つであるため
に、個々のプログラムの処理に対応してチェックポイン
ト取得・リスタート時のファイルの扱いを決める必要が
ある。その指定方法としてはプログラムの実行開始時に
指定する方法と、チェックポイント取得時に指定する方
法があるが、ユーザにとって最も単純な指定方法はチェ
ックポイント取得要求者がファイル名毎に扱いを指定す
ることである。
【０１１３】これを実現するためには実行中のプログラ
ムがオープンしている個々のファイルの名前を知る必要
があるが、ＵＮＩＸの従来技術ではそのファイル名を知
る方法がなかった。本発明においてファイル記述子から
ファイル名を検出することが可能になり、これによって
ユーザが指定したファイルの名前とオープンされている
ファイルの名前とを照合することにより、ファイル毎の
チェックポイント取得・リスタート処理におけるファイ
ルの退避・復元方法を指定することが可能となった。
【０１１４】すなわちチェックポイント取得要求時に個
々のファイルの扱いを指定できるようになるために、チ
ェックポイント取得時のシステム環境に応じてファイル
の扱いを指定できるようになる。そこで、ジョブ開始時
に個々のファイルに対するチェックポイント取得時のフ
ァイルの扱い方法が決定される従来方式に比べて、より
柔軟な運用が可能になり、特に長時間のジョブを実行さ
せる場合に有効となる。
【０１１５】またオープンされている個々のファイルの
扱いを、ファイルの属性に関係なく、個々のファイル名
毎に指定できるようになるため、ジョブの動作状況に応
じてより柔軟な運用が可能となる。従来は、例えばファ
イルの属性によって個々のファイルの扱いがユニークに
決定されていたために、ジョブの性質や動作状況に適応
した指定ができなかった。
【０１１６】更に個々のファイルの扱いがあらかじめ格
納されたファイルを指定して、チェックポイント取得を
ユーザが要求できるようになるために、指定すべきファ
イルの数量に関係なく、チェックポイント取得要求を短
いコマンドによって実現することが可能となる。
【０１１７】従来技術においてチェックポイント取得・
リスタート処理に関する３つの問題点を述べたが、第１
の問題点の解決、すなわちチェックポイント取得処理を
行うシステムとリスタート処理を行うシステムとを変更
することは本発明によって容易となる。すなわち本発明
においては、チェックポイント取得時にはファイルの管
理情報としてファイルの完全パス名や、ファイルのアク
セス位置などの管理情報を記憶しておき、復元時にはフ
ァイルの完全パス名を用いてそのファイルをオープン
し、その他の管理情報を用いてファイルのアクセス状態
などを復元することになる。ファイルの状態の復元にお
いてディバイス番号やｉノード番号を用いず、ファイル
のオープンをＯＳに依頼することにより、ＯＳがファイ
ルのディバイス番号とｉノード番号、その他を適切に設
定することになるため、チェックポイント取得システム
とリスタート処理システムとを別にすることは容易に実
現される。
【０１１８】次に第２の問題点、すなわち一時ファイル
の退避・復元がうまく行かない場合があると言う問題に
ついては、本発明においてファイルの退避・復元法を各
ファイル毎に、ファイルの名前を復元するか否かを含め
て指定できるようになるため、解決される。一時ファイ
ルであっても名前を含めて退避・復元する必要がある場
合には、前述のセーブリストアを指定することにより、
第２の問題点が解決される。
【０１１９】次の第３の問題点、すなわちリスタート処
理プログラムを実現するためにＯＳのカーネルの規模が
増大すると言う問題点については、本発明においてはこ
のカーネルへの機能追加は５つの独立したシステムコー
ルを実現するだけでよく、ＯＳの規模の増大は最小限に
抑えられる。
【０１２０】この５つのシステムコールの第１は既存の
システムコール（open）を機能拡張したものである。図
２で説明したようにディレクトリに対するファイル管理
テーブル２８を追加し、このテーブル２８に対するポイ
ンタをタスクとファイルの対応管理テーブル５に格納す
る手段を従来のオープン処理に追加して実現する、第２
は図４で説明したディレクトリ獲得処理のためのシステ
ムコールであり、第３は図６で説明した他のタスクのフ
ァイル記述子管理テーブルの内容を複写するためのシス
テムコールであり、第４は図１５で説明したＩＤ指定の
タスク生成機能のシステムコールであり、第５は同じく
図１５で説明したユーザ空間プログラムの実行途中の回
復機能のシステムコールである。
【０１２１】更に本発明によってファイルの扱いを個々
に指定することが可能になるが、その必要性について補
足する。前述の４つの指定方法のうちアペンドの必要性
については、例えばジョブの実行履歴情報を記録するフ
ァイルであるログファイルに対してアペンドが利用でき
る。このアペンドは既にＵＮＩＸにある概念であるが、
従来のアペンド機能の使い方によってはチェックポイン
ト取得・リスタート処理が必ずしもうまく行かないこと
があるために、本発明における１つの指定方式としてい
る。セーブリストアは、前述のように一時ファイルにつ
いての問題点を解決するために有効であり、セーブコピ
ー、およびイグノアは従来からある指定方式である。
【０１２２】ジョブ実行中（リスタートの前）にファイ
ルの扱い方法を変更することの必要性について更に説明
する。一般に削除される可能性のあるファイル、すなわ
ち一時ファイルにはセーブコピー、またはセーブリスト
アの指定が行われる。このようなファイルは、何らかの
理由で処理が中断された場合に削除される可能性がある
ため、チェックポイントを取得してファイルの内容を退
避しておき、リスタート時に復元する必要がある。しか
しながら、その例は後述するが、削除される可能性があ
っても実際には削除されない場合もある。その場合には
わざわざ退避した内容で復元を行う必要がなく、システ
ムに存在するファイルをそのまま使えばよいことにな
る。すなわちセーブリストアをイグノアに変更すること
により、復元処理を省略できる。
【０１２３】削除される可能性があるが実際には削除さ
れない場合もある例として、名前のある一時ファイルが
あげられる。名前のある一時ファイルに対しては、毎朝
システムを立ち上げる時にシステムの運用者が削除する
と言う運用が行われているものとする。この場合、数日
の実行を必要とするプログラムに対しては、毎日夕方シ
ステムを止める前にチェックポイントデータを取得し
て、翌朝リスタート処理を行うことが必要となる。しか
しながら、名前のある一時ファイルをシステムの運用者
が削除しなければ翌日も利用可能であり、更にチェック
ポイントを取得した結果一時ファイルの量が膨大であっ
た時には、システムの運用者に依頼して、その日は名前
のある一時ファイルを削除しないようにすることも可能
になり、退避・復元処理を行うと言う無駄が省けること
になる。
【０１２４】以上の説明では、ファイルの退避・復元時
の扱いをチェックポイント取得時に指定するものとして
実施例を説明したが、チェックポイント取得時に指定さ
れた個々のファイルの扱いをリスタート処理時に更に変
更することも可能である。この変更は、例えば既存のコ
マンド、すなわちエディタのコマンドで行われる。一般
にチェックポイント取得タスクによって取得された情報
は、その一部を利用者が参照・変更可能なような形式
（テキスト形式）でストラクチャファイルと呼ばれる特
別のファイルに出力される。
【０１２５】利用者はこの出力結果を見て、エディタの
コマンドにより利用者の責任でファイルの扱い方法を変
更することができる。なお、ストラクチャファイルには
オープンされているファイルの名前、アペンドかセーブ
コピーかなどのファイルの退避・復元方法に関する指
定、およびリードオンリーかライトオンリーかなどのア
クセス許可情報などが出力される。
【０１２６】
【発明の効果】以上詳細に説明したように、本発明によ
ればファイル記述子に対応して、タスクの内外のプログ
ラムがファイル記述子に対応するファイルの名前を高速
に検出することが可能になる。その結果、タスクの状態
表示処理や、チェックポイント取得・リスタート処理に
おいてオープンされているファイルの名前を求めること
が可能になり、階層的なファイルシステムを持つオペレ
ーティングシステムの実用性の向上に寄与するところが
大きい。
【図面の簡単な説明】
【図１】本発明の原理構成ブロック図である。
【図２】本発明におけるファイルオープン処理の実施例
を説明する図である。
【図３】ファイル記述子からファイル名を求めるファイ
ル名検出方式の実施例を説明する図である。
【図４】ディレクトリ獲得処理の詳細説明図である。
【図５】ファイルの完全パス名を求めるプログラムの例
を示す図である。
【図６】ファイル記述子情報複製処理実施例の説明図で
ある。
【図７】チェックポイント取得・リスタート処理を行う
システムの動作環境の説明図である。
【図８】ファイル処理方法の指定の実施例を説明する図
である。
【図９】チェックポイント取得タスクの処理の流れを説
明する図である。
【図１０】コマンド解析およびＣＰＲファイル解析の詳
細処理を説明する図である。
【図１１】ファイル状態の採取処理の詳細を説明する図
である。
【図１２】ＵＮＩＸにおけるタスク起動方法を説明する
図（その１）である。
【図１３】ＵＮＩＸにおけるタスク起動方法を説明する
図（その２）である。
【図１４】ＵＮＩＸにおけるタスク起動方法を説明する
図（その３）である。
【図１５】リスタートタスクの処理の流れを説明する図
である。
【図１６】階層的構造を持つファイルシステムの例を示
す図である。
【図１７】ファイルオープン処理の従来例を示す図であ
る。
【図１８】チェックポイント取得・リスタート処理の従
来例の問題点を説明する図である。
【符号の説明】
３ ファイルシステム ４ ファイル管理テーブル ５，２９，４８ タスクとファイルの対応管理テーブ
ル ６，４６ タスク管理テーブル ７，４７ ファイル記述子管理テーブル ８ 応用プログラム（タスクＡ） ２１ 中間ノード記憶手段 ２２ 中間ノード検出手段 ２８ ディレクトリに対するファイル管理テーブル ４５ タスクＢ ５７ チェックポイントサービス提供プログラム ５８ ＣＰＲファイル ５９ チェックポイント取得・リスタート対象プログ
ラム ６１ オペレーションシステム（ＯＳ） ６３ リスタートサービス提供プログラム
───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平４−260945（ＪＰ，Ａ) 特開 平３−85644（ＪＰ，Ａ) (58)調査した分野(Int.Cl.7，ＤＢ名) G06F 12/00 G06F 11/14 ＷＰＩ（ＤＩＡＬＯＧ)

Claims (12)

    (57)【特許請求の範囲】
  1. 【請求項１】 ルートノードから中間ノードを経て最終
    ノードとしてのファイルに至る階層構造を有するファイ
    ルシステムを有し、該ファイルの使用に先立って行われ
    るオープン処理時に該ファイルに割り当てられるファイ
    ル記述子の指定によって該ファイルをタスクが使用可能
    となるオペレーティングシステムにおいて、 前記オープン処理時に前記ファイルの直前の中間ノード
    を記憶する中間ノード記憶手段と、 該中間ノード記憶手段の記憶内容に応じて、前記ファイ
    ルに割り当てられたファイル記述子に基づいて該ファイ
    ルの直前の中間ノードを検出し、該検出結果を前記タス
    クに通知する中間ノード検出手段とを備え、 該ファイルを使用しているタスクが該直前の中間ノード
    の格納内容を前記ファイルシステムから読み込み、該フ
    ァイルの名前を求めることを特徴とするファイル名検出
    方式。
  2. 【請求項２】 前記ファイルシステムにおいて、前記中
    間ノードがディレクトリによって構成され、 該ディレクトリ間では相互にポインタが張られ、前記最
    終ノードとしてのファイルに対しては直前のディレクト
    リ側からのみポインタが張られていることを特徴とする
    請求項１記載のファイル名検出方式。
  3. 【請求項３】 前記中間ノード検出手段が、前記ファイ
    ルの直前の中間ノードとしてのディレクトリに対するフ
    ァイル記述子を、前記検出結果として前記タスクに通知
    することを特徴とする請求項１、または２記載のファイ
    ル名検出方式。
  4. 【請求項４】 前記ファイルおよびディレクトリがそれ
    ぞれ対応するｉノード番号によって特定されることと、 前記ファイルに割り当てられたファイル記述子を指定し
    て該ファイルに対応するｉノード番号を求め、 該ファイル記述子の指定によって前記ファイルの直前の
    ディレクトリに対するファイル記述子を前記中間ノード
    検出手段を構成するディレクトリ獲得処理によって求
    め、 該求められたディレクトリに対するファイル記述子を指
    定して該直前のディレクトリの格納内容を読み込み、 該読み込まれたディレクトリの格納内容によって、前記
    求められたｉノード番号に対応するファイルの名前を該
    直前のディレクトリからの相対的な名前として求めるこ
    とを特徴とする請求項３記載のファイル名検出方式。
  5. 【請求項５】 前記オペレーティングシステムにおい
    て、前記ファイル記述子が割り当てられたファイルに対
    応するｉノード番号を格納するファイル管理テーブル
    と、 前記中間ノード記憶手段を構成し、前記ファイルの直前
    のディレクトリに対応するｉノード番号を格納するディ
    レクトリに対するファイル管理テーブルと、 該ファイル管理テーブルとディレクトリに対するファイ
    ル管理テーブルとを指すポインタを格納するタスクとフ
    ァイルの対応管理テーブルと、 該タスクとファイルの対応管理テーブルを指すポインタ
    を格納するテーブルであって、該テーブルのエントリ番
    号が前記ファイル記述子として前記ファイルに割り当て
    られるファイル記述子管理テーブルとを備え、 前記ディレクトリ獲得処理において、指定されたファイ
    ル記述子に対するファイル記述子管理テーブルのエント
    リ、およびタスクとファイルの対応管理テーブルをたど
    って前記ディレクトリに対するファイル管理テーブルを
    求め、 求められたディレクトリに対するファイル管理テーブル
    に直接アクセス可能となるように、該ディレクトリに対
    するファイル管理テーブルのみを直接ポイントするタス
    クとファイルの対応管理テーブルを新たに作成し、 該新たに作成されたタスクとファイルの対応管理テーブ
    ルを指すポインタを前記ファイル記述子管理テーブルに
    エントリを追加して格納し、 該ファイル記述子管理テーブル内で該追加されたエント
    リのエントリ番号を、前記ファイルの直前のディレクト
    リに対するファイル記述子として前記タスクに通知する
    ことを特徴とする請求項４記載のファイル名検出方式。
  6. 【請求項６】 前記オペレーティングシステムにおい
    て、１つのタスクが使用しているファイルのファイル記
    述子を含む情報を該１つのタスクと異なるタスクのため
    に複写するファイル記述子情報複写手段を更に備え、該
    １つのタスクが使用しているファイルの名前を該異なる
    タスクが求めることを可能とすることを特徴とする請求
    項１記載のファイル名検出方式。
  7. 【請求項７】 前記オペレーティングシステムにおい
    て、前記ファイル記述子が割り当てられたファイルに対
    応するｉノード番号を格納するファイル管理テーブル
    と、 前記中間ノード記憶手段を構成し、前記ファイルの直前
    のディレクトリに対応するｉノード番号を格納するディ
    レクトリに対するファイル管理テーブルと、 該ファイル管理テーブルとディレクトリに対するファイ
    ル管理テーブルとを指すポインタを格納するタスクとフ
    ァイルの対応管理テーブルと、 該タスクとファイルの対応管理テーブルを指すポインタ
    を格納するテーブルであって、該テーブルのエントリ番
    号が前記ファイル記述子として前記ファイルに割り当て
    られるファイル記述子管理テーブルとを備え、 前記ファイル記述子情報複写手段を構成するファイル記
    述子情報復製処理において、前記１つのタスクの名前を
    基にして該１つのタスクに対するファイル記述子管理テ
    ーブルを求め、 該求められたファイル記述子管理テーブルの内容の前記
    異なるタスクに対するファイル記述子管理テーブルに複
    写し、 前記１つのタスクに対して作成されているファイル管理
    テーブル、およびディレクトリに対するファイル管理テ
    ーブルを指すポインタを格納し、前記異なるタスク側に
    複写されたファイル記述子管理テーブルからポイントさ
    れるタスクとファイルの対応管理テーブルを前記異なる
    タスク側に新たに作成し、 前記複写されたファイル記述子管理テーブルのエントリ
    番号を、前記１つのタスクが使用しているファイルのフ
    ァイル記述子として前記異なるタスクに通知することを
    特徴とする請求項６記載のファイル名検出方式。
  8. 【請求項８】 前記オペレーティングシステムを用いる
    コンピュータシステムにおけるプログラムのチェックポ
    イント取得処理およびリスタート処理において、チェッ
    クポイント取得時にチェックポイント取得対象プログラ
    ムがオープンしていた個々のファイルに対して、チェッ
    クポイント取得時のファイル退避方法、リスタート時の
    ファイル復元、または再オープン方法をファイルの名前
    に基づいてチェックポイント取得要求者が指定し、 チェックポイント取得機構が、前記オペレーティングシ
    ステムを用いて前記検出された直前の中間ノードの格納
    内容をファイルシステムから読み込んで前記対象プログ
    ラムがオープン中のファイルの名前を求め、該求められ
    た名前と前記チェックポイント取得要求者が指定したフ
    ァイルの名前とを対比させて、チェックポイント取得時
    とリスタート時のファイルの扱いを決定することを特徴
    とする請求項１記載のファイル名検出方式。
  9. 【請求項９】 前記オペレーティングシステムに対し
    て、ファイルの名前に基づいて、該ファイルのチェック
    ポイント取得時の退避方法、リスタート時の復元または
    再オープン方法を格納したファイル取り扱い方法格納フ
    ァイルをさらに備え、 前記チェックポイント取得要求者が該取得要求時に該フ
    ァイル取り扱い方法格納ファイルを指定し、 前記チェックポイント取得機構が該ファイル取り扱い方
    法格納ファイルの格納内容に従って、前記チェックポイ
    ント取得時とリスタート時のファイルの扱いを決定する
    ことを特徴とする請求項８記載のファイル名検出方式。
  10. 【請求項１０】 前記ファイルの名前に基づいて指定さ
    れるチェックポイント取得時のファイル退避方法、リス
    タート時のファイル復元または再オープン方法が、チェ
    ックポイント取得時にファイルの内容とアクセス状態を
    退避し、リスタート時に同一ファイル名を用いて復元す
    るセーブリストア、 チェックポイント取得時にファイルの内容とアクセス状
    態を退避し、リストア時に一時ファイルとして復元する
    セーブコピー、 チェックポイント取得時にファイルのアクセス状態だけ
    を退避し、リストア時にチェックポイント取得時のファ
    イルのアクセス状態で再オープンするイグノア、 またはチェックポイント取得時にはファイルのアクセス
    状態だけを退避し、リストア時には該リスタート時点の
    ファイルの内容とアクセス状態とがそのまま引き継がれ
    るアペンドモードで再オープンするアペンドのいずれか
    であることを特徴とする請求項８、または９記載のファ
    イル名検出方式。
  11. 【請求項１１】 前記チェックポイント取得機構を構成
    するチェックポイント取得タスクの処理において、 前記チェックポイント取得要求者によって投入されたコ
    マンドの解析、および該コマンドの指定により必要なと
    きには、前記ファイル退避方法、ファイル復元または再
    オープン方法が格納されたＣＰＲファイルの解析を行
    い、 １つ以上のタスクによって構成されるチェックポイント
    取得対象の対象タスクグループをストップ状態とし、 該対象タスクグループの状態として、タスクの仮想空間
    の内容、オペレーティングシステムの管理情報を含むデ
    ータを採取し、 該対象タスクグループがオープン中のファイルの名前を
    求めて、該オープン中のファイルの状態を採取し、 対象タスクグループの実行を終了、または再開させるこ
    とを特徴とする請求項８記載のファイル名検出方式。
  12. 【請求項１２】 前記リスタート処理を行うリスタート
    タスクの処理において、 処理の準備としてリスタートすべきタスクグループの識
    別子、およびチェックポイント取得時の管理情報を求
    め、 対象タスクグループがオープンしていたファイルの内容
    を復元し、 ＩＤ指定のタスク生成機能を用いて、対象タスクグルー
    プの親タスクを生成し、 処理中のタスクが生成された親タスクか否かを判定し、 生成された親タスクである時には該処理中のタスクが子
    タスクを持つか否かを判定し、 子タスクを持つ時にはＩＤ指定のタスク生成機能を用い
    て該子タスクを生成し、 処理中のタスクが生成された子タスクか否かを判定し、
    生成された子タスクである時には前記処理中のタスクが
    子タスクを持つか否かの判定以降の処理を繰り返し、 生成された子タスクでない時には処理中のタスクか未生
    成の子タスクを持つか否かを判定し、未生成の子タスク
    を持つ時には前記ＩＤ指定のタスク生成機能を用いて子
    タスクを生成する処理以降を繰り返し、 未生成の子タスクを持たない時、および前記処理中のタ
    スクが子タスクを持つか否かの判定において子タスクを
    持たない時には、処理中のタスクがオープンしていたフ
    ァイルのアクセス状態の復元、タスクの状態の復元、お
    よびタスクの実行権の復元を行い、 ユーザ空間プログラムの実行途中の回復機能により処理
    中のタスクの仮想空間を対象タスクの内容で置き換え、
    置き換えられたプログラムをストップ状態として、該プ
    ログラムがストップ状態である旨の信号を発信し、 前記処理中のタスクが生成された親タスクか否かの判定
    において親タスクでないと判定された時には、対象タス
    クグループに属する全てのタスクがストップ状態になる
    のを待ち、未回復のタスクの状態およびファイルの状態
    を復元し、対象タスクグループの実行を再開し、対象タ
    スクグループの親タスクの実行が終了するのを待ち、実
    行を終了することを特徴とする請求項８記載のファイル
    名検出方式。
JP25349593A 1993-10-08 1993-10-08 ファイル名検出方式 Expired - Fee Related JP3270216B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP25349593A JP3270216B2 (ja) 1993-10-08 1993-10-08 ファイル名検出方式
US08/294,960 US5603020A (en) 1993-10-08 1994-08-24 Method for detecting file names by informing the task of the identification of the directory antecedent to the file
AU71622/94A AU685476B2 (en) 1993-10-08 1994-09-01 File name detecting methd for use with operating system
DE4435751A DE4435751B4 (de) 1993-10-08 1994-10-06 Dateiname- und Verzeichnis- Erfassungsverfahren zur Verwendung mit einem Betriebssystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP25349593A JP3270216B2 (ja) 1993-10-08 1993-10-08 ファイル名検出方式

Publications (2)

Publication Number Publication Date
JPH07105064A JPH07105064A (ja) 1995-04-21
JP3270216B2 true JP3270216B2 (ja) 2002-04-02

Family

ID=17252176

Family Applications (1)

Application Number Title Priority Date Filing Date
JP25349593A Expired - Fee Related JP3270216B2 (ja) 1993-10-08 1993-10-08 ファイル名検出方式

Country Status (4)

Country Link
US (1) US5603020A (ja)
JP (1) JP3270216B2 (ja)
AU (1) AU685476B2 (ja)
DE (1) DE4435751B4 (ja)

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2715486B1 (fr) * 1994-01-21 1996-03-29 Alain Nicolas Piaton Procédé de comparaison de fichiers informatiques.
DE19520030C1 (de) * 1995-05-31 1996-05-15 Siemens Ag Verfahren zur Aktualisierung der Programmstruktur einer modularen Kommunikationsanlage
JPH0934765A (ja) * 1995-07-20 1997-02-07 Fuji Xerox Co Ltd ファイル管理装置
US5870757A (en) * 1995-09-11 1999-02-09 Sun Microsystems, Inc. Single transaction technique for a journaling file system of a computer operating system
JP3120033B2 (ja) * 1996-03-19 2000-12-25 株式会社東芝 分散メモリ型マルチプロセッサシステム及び故障回復方法
US6173291B1 (en) 1997-09-26 2001-01-09 Powerquest Corporation Method and apparatus for recovering data from damaged or corrupted file storage media
US7107591B1 (en) * 1998-11-05 2006-09-12 Hewlett-Packard Development Company, L.P. Task-specific flexible binding in a software system
US7296060B2 (en) * 1998-12-24 2007-11-13 Intel Corporation System and method for automatically identifying and attaching related documents
JP2000250667A (ja) * 1999-02-26 2000-09-14 Nec Corp システム処理機能を提供するサスペンド・レジューム方法
JP3440991B2 (ja) * 1999-03-05 2003-08-25 日本電気株式会社 ファイルリビジョン管理システム
US6374265B1 (en) * 1999-03-29 2002-04-16 Inventec Corp. Method for backup and recovery of the long filename in computer system
US6754680B1 (en) * 1999-05-20 2004-06-22 Matsushita Electric Industrial Co., Ltd. Data control equipment, method to control data and recording medium to record data control procedure
US6976258B1 (en) 1999-11-30 2005-12-13 Ensim Corporation Providing quality of service guarantees to virtual hosts
US6711607B1 (en) 2000-02-04 2004-03-23 Ensim Corporation Dynamic scheduling of task streams in a multiple-resource system to ensure task stream quality of service
US6529985B1 (en) 2000-02-04 2003-03-04 Ensim Corporation Selective interception of system calls
US6560613B1 (en) * 2000-02-08 2003-05-06 Ensim Corporation Disambiguating file descriptors
US6754716B1 (en) 2000-02-11 2004-06-22 Ensim Corporation Restricting communication between network devices on a common network
US7343421B1 (en) * 2000-02-14 2008-03-11 Digital Asset Enterprises Llc Restricting communication of selected processes to a set of specific network addresses
US6948003B1 (en) 2000-03-15 2005-09-20 Ensim Corporation Enabling a service provider to provide intranet services
US6985937B1 (en) 2000-05-11 2006-01-10 Ensim Corporation Dynamically modifying the resources of a virtual server
US6907421B1 (en) 2000-05-16 2005-06-14 Ensim Corporation Regulating file access rates according to file type
JP2001331321A (ja) * 2000-05-22 2001-11-30 Canon Inc 情報処理装置、情報処理方法、情報処理システム、及び媒体
US7143024B1 (en) 2000-07-07 2006-11-28 Ensim Corporation Associating identifiers with virtual processes
US7117354B1 (en) * 2000-07-20 2006-10-03 International Business Machines Corporation Method and apparatus for allowing restarted programs to use old process identification
US6909691B1 (en) 2000-08-07 2005-06-21 Ensim Corporation Fairly partitioning resources while limiting the maximum fair share
US6732211B1 (en) 2000-09-18 2004-05-04 Ensim Corporation Intercepting I/O multiplexing operations involving cross-domain file descriptor sets
US7219354B1 (en) 2000-12-22 2007-05-15 Ensim Corporation Virtualizing super-user privileges for multiple virtual processes
US6618736B1 (en) 2001-03-09 2003-09-09 Ensim Corporation Template-based creation and archival of file systems
US7406432B1 (en) * 2001-06-13 2008-07-29 Ricoh Company, Ltd. Project management over a network with automated task schedule update
US7191141B2 (en) * 2001-06-13 2007-03-13 Ricoh Company, Ltd. Automated management of development project files over a network
EP1300757A1 (en) * 2001-10-02 2003-04-09 Sun Microsystems, Inc. Shareable installation hierarchies
US7171652B2 (en) * 2002-12-06 2007-01-30 Ricoh Company, Ltd. Software development environment with design specification verification tool
US7512790B2 (en) * 2003-04-17 2009-03-31 International Business Machines Corporation Method, system and article of manufacture for management of co-requisite files in a data processing system using extended file attributes
US7237224B1 (en) * 2003-08-28 2007-06-26 Ricoh Company Ltd. Data structure used for skeleton function of a class in a skeleton code creation tool
US7308675B2 (en) * 2003-08-28 2007-12-11 Ricoh Company, Ltd. Data structure used for directory structure navigation in a skeleton code creation tool
US20050076005A1 (en) * 2003-09-15 2005-04-07 International Business Machines Corporation Method and apparatus to associate data files with tasks or events
GB0408868D0 (en) 2004-04-21 2004-05-26 Level 5 Networks Ltd Checking data integrity
US7213103B2 (en) * 2004-04-22 2007-05-01 Apple Inc. Accessing data storage systems without waiting for read errors
JP4557650B2 (ja) * 2004-09-13 2010-10-06 キヤノン株式会社 通信システム並びに通信装置及びその制御方法
GB0505300D0 (en) * 2005-03-15 2005-04-20 Level 5 Networks Ltd Transmitting data
EP1861778B1 (en) * 2005-03-10 2017-06-21 Solarflare Communications Inc Data processing system
GB0506403D0 (en) 2005-03-30 2005-05-04 Level 5 Networks Ltd Routing tables
US8495015B2 (en) * 2005-06-21 2013-07-23 Apple Inc. Peer-to-peer syncing in a decentralized environment
US7523146B2 (en) * 2005-06-21 2009-04-21 Apple Inc. Apparatus and method for peer-to-peer N-way synchronization in a decentralized environment
GB0600417D0 (en) 2006-01-10 2006-02-15 Level 5 Networks Inc Virtualisation support
US7797670B2 (en) * 2006-04-14 2010-09-14 Apple Inc. Mirrored file system
US8799043B2 (en) * 2006-06-07 2014-08-05 Ricoh Company, Ltd. Consolidation of member schedules with a project schedule in a network-based management system
US20070288288A1 (en) * 2006-06-07 2007-12-13 Tetsuro Motoyama Use of schedule editors in a network-based project schedule management system
US8050953B2 (en) * 2006-06-07 2011-11-01 Ricoh Company, Ltd. Use of a database in a network-based project schedule management system
US20080016077A1 (en) * 2006-07-11 2008-01-17 International Business Machines Corporation A system for ensuring that only one computer application maintains edit or delete access to a file at all times
US7860826B2 (en) 2006-08-04 2010-12-28 Apple Inc. Method and system for using global equivalency sets to identify data during peer-to-peer synchronization
US7657769B2 (en) 2007-01-08 2010-02-02 Marcy M Scott N-way synchronization of data
US8131579B2 (en) * 2007-07-09 2012-03-06 Raytheon Company Web-based system and application for collaborative planning of a networked program schedule
US20090265780A1 (en) * 2008-04-21 2009-10-22 Varonis Systems Inc. Access event collection
US8473949B2 (en) 2010-07-08 2013-06-25 Microsoft Corporation Methods for supporting users with task continuity and completion across devices and time
US10116077B1 (en) * 2016-09-28 2018-10-30 Engineered Energy Products, LLC Kit having a tube surrounding an end portion of a tracer wire and a conductive end cap engaging the tube and the wire

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63100562A (ja) * 1986-10-17 1988-05-02 Hitachi Ltd フアイルシステム管理方式
JPS6410353A (en) * 1987-07-03 1989-01-13 Hitachi Ltd Computer file system
US5371885A (en) * 1989-08-29 1994-12-06 Microsoft Corporation High performance file system
JPH0385644A (ja) * 1989-08-30 1991-04-10 Nec Corp チェックポイント取得リスタート方式
US5367671A (en) * 1990-09-25 1994-11-22 International Business Machines Corp. System for accessing extended object attribute (EA) data through file name or EA handle linkages in path tables
JPH04260945A (ja) * 1991-01-11 1992-09-16 Mitsubishi Electric Corp ファイル・アクセス装置及びファイル・アクセス方法
US5325526A (en) * 1992-05-12 1994-06-28 Intel Corporation Task scheduling in a multicomputer system
US5355497A (en) * 1992-06-10 1994-10-11 Physiotronics Corporation File directory structure generator and retrevial tool with document locator module mapping the directory structure of files to a real world hierarchical file structure
CA2110243C (en) * 1992-12-31 1998-08-11 Philip Steven Winterbottom Apparatus and methods for making a portion of a first name space available as a portion of a second name space

Also Published As

Publication number Publication date
AU7162294A (en) 1995-04-27
US5603020A (en) 1997-02-11
DE4435751A1 (de) 1995-05-04
JPH07105064A (ja) 1995-04-21
DE4435751B4 (de) 2009-05-07
AU685476B2 (en) 1998-01-22

Similar Documents

Publication Publication Date Title
JP3270216B2 (ja) ファイル名検出方式
US6526441B2 (en) Input/output device information management system for multi-computer system
US5761677A (en) Computer system method and apparatus providing for various versions of a file without requiring data copy or log operations
US4945474A (en) Method for restoring a database after I/O error employing write-ahead logging protocols
JP4436036B2 (ja) 情報処理装置、トレース処理方法、プログラム及び記録媒体
US7606842B2 (en) Method of merging a clone file system with an original file system
US11531594B2 (en) Data recovery method and apparatus, server, and computer-readable storage medium
JPH0713751A (ja) ファイル・システムの副作用の選択的追加装置
US6233727B1 (en) Computer system for supporting utilization of functions provided by OS
WO2022127557A1 (zh) 代码分析的方法和相关设备
CN117112522A (zh) 并发进程日志管理方法、装置、设备和存储介质
CN114356849B (zh) 文件系统的数据管理方法及装置、电子设备及存储介质
CN115391337A (zh) 数据库分区的方法、装置、存储介质及电子设备
CN115114258A (zh) 数据复制方法、装置、电子设备及计算机存储介质
JPH02260045A (ja) アプリケーション・トラブル・チェック方式
JPS62131349A (ja) デ−タベ−ス処理方式
JPS6362007B2 (ja)
JP3514332B2 (ja) データベースバックアップ方法
JP3497053B2 (ja) オンラインデータベース管理システムにおける処理方法及びオンラインデータベース管理システム
CN114547191A (zh) 区块链虚拟机异步执行智能合约的方法、系统及p2p网络
JPH02226350A (ja) 計算機システムのデータ管理方法
CN118092885A (zh) 一种基于前后端插件架构的代码框架方法
JPH03246643A (ja) ダンプサマリ編集処理方法
KR100545654B1 (ko) 시스템 시동 후 디스크에 존재하는 파일의 무결점을감지하는 방법
CN115658033A (zh) 一种rpa代码开发方法及系统

Legal Events

Date Code Title Description
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20020108

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080118

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090118

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100118

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110118

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110118

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120118

Year of fee payment: 10

LAPS Cancellation because of no payment of annual fees