JPH11134226A

JPH11134226A - 情報記録方法

Info

Publication number: JPH11134226A
Application number: JP9294460A
Authority: JP
Inventors: Masahiro Tamegai; 正博為我井
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1997-10-27
Filing date: 1997-10-27
Publication date: 1999-05-21

Abstract

(57)【要約】【課題】オープンしている複数のファイルをクローズ
するときに、光カードの記録容量が不足し、バッファメ
モリのデータやオープンしているファイルのディレクト
リを記録できないことがある。【解決手段】ファイルのアクセス要求を実行する前
に、データを記録する光カードの残り容量、アクセス要
求を実行したときにデータを記録するのに必要と予測さ
れる容量、及びディレクトリを記録するのに必要と予測
される容量に基づいてアクセス要求を実行するか否かを
判断する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、光カードなどの記
録情報担体に情報を記録する情報記録方法に関するもの
である。

【０００２】

【従来の技術】従来、光学的に情報を記録したり、ある
いは記録された情報を読み出す記録担体の形態として
は、ディスク状、カード状、テープ状のものなど各種の
ものが知られている。このうち、カード状の記録担体
（以下、光カードという）は小型、軽量で持ち運びに便
利な上、大容量の記録容量を有するために今後追記型記
録媒体として大きな需要が見込まれている。

【０００３】ここで、本願出願人は、光カードなどの記
録媒体の記録領域が少なくなったときにディレクトリを
確実に記録できる方法を特開平６−２６６６０２号公報
で提案している。以下、この記録方法について説明す
る。まず、図８は光カードの記録面を示している。図中
１は光カード、２は情報記録領域である。情報記録領域
２にはトラッキングトラック３₁ 〜３_n+1 が平行に多数
配列され、その各トラッキングトラックの間に情報を記
録するための情報トラック４₁ 〜４_n が設けられてい
る。また、各情報トラックの両端部には情報トラックを
識別するための物理的トラックナンバー５₁ 〜５_n が記
録されている。

【０００４】ところで、このような光カード、特に情報
の消去が不可能な追記式の光カードは寸法がクレジット
カード程度ではあるが、このサイズであっても大容量の
記録容量を持っている。例えば、光カードの寸法を８５
ｍｍ×５５ｍｍ、情報トラックピッチを２０μｍ、１ビ
ットの記録長を５μｍとすると、光カードのトラック数
は２７５０本、１トラック当りのビット容量は１７００
０ビット、バイト容量では２１２５バイトとなる。これ
だけの大容量のメモリのデータを管理するには、ディレ
クトリによるファイル管理が必要である。通常、ディレ
クトリとしては図９に示すようにファイル名、ファイル
長、先頭データトラック番号などファイル管理に必要な
情報からなっていて、このディレクトリを記録媒体の一
部に書き込んで、データの記録や再生時にはディレクト
リをもとにファイルの管理を行っている。

【０００５】図８の光カードは以上のようなディレクト
リによるファイル管理のために、情報記録領域２はファ
イルデータを記録するためのデータ部１０と、ディレク
トリを記録するためのディレクトリ部２０に分けられて
いる。データ部１０は１トラックが１セクタとして構成
され、先頭の情報トラック４_n から順にデータ１０₁，
１０₂ ，…１０_m が記録される。一方、ディレクトリ部
２０は１トラックが４セクタとして構成され、データ部
１０とは反対側の情報トラック４₁ から順にディレクト
リ２０₁ ，２０₂ ，…２０_n が記録される。

【０００６】図１０は特開平６−２６６６０２号公報に
よる情報記録方法を示したフローチャートである。図１
０において、まず、光カード１にファイルデータを追記
する場合、ファイルデータの記録後にファイルデータを
管理するためのディレクトリを記録する必要がある。ま
た、ディレクトリはディレクトリ部２０の最終ディレク
トリ部（以下、ＥＯＤという）の次のセクタに記録され
るため、最終ディレクトリの記録位置が分からない場合
は、最終ディレクトリ検索する処理を行う。また、ファ
イルデータもデータ部１０の最終データ（以下、ＥＯＳ
という）の次のセクタから記録されるため、予め最終デ
ータの記録位置がわかっていないときは最終データを検
索する処理を行う。

【０００７】従って、始めに最終ディレクトリが検出さ
れているか否かを判断し（Ｓ１）、もし検出されていな
ければ光カード１のディレクトリ部２０を検索して最終
ディレクトリの検出を行う（Ｓ２）。次いで、最終デー
タの記録位置が検出されているか否かを判断し（Ｓ
３）、検出されていなければデータ部１０を検索して最
終データの検出処理を行う（Ｓ４）。最終ディレクトリ
や最終データを検出するには、例えばディレクトリ（デ
ータ）が記録されているトラックから連続して何も記録
されていないトラックが所定数続いたときに前記ディレ
クトリ（データ）を最終ディレクトリ（データ）として
検出する。

【０００８】最終ディレクトリ及び最終データを検出す
ると、次に記録するデータのトラックＷＤＴ＿ＴＲＫか
ら最終ディレクトリのトラックであるＥＯＤ＿ＴＲＫを
引いた値と予め決められた値Ｎ₁ を比較する（Ｓ５）。
このＮ₁ は光カードの最終データの記録位置を検出する
のに用いる数値で、後述する最終ディレクトリの記録位
置を検出する数値Ｎ₂ とは異なる値に設定されている。
Ｎ₁ は数本程度、Ｎ₂はこれよりも少ない値に設定さ
れ、Ｎ₁ ＞Ｎ₂ となるようにそれぞれの値が決められて
いる。一方、ＷＤＴ＿ＴＲＫからＥＯＤ＿ＴＲＫを引い
た値は、光カードの全トラックにおけるデータ部とディ
レクトリ部の残りトラック数を表わすもので、この残り
トラック数と前述したＮ₁ を比較する。

【０００９】ここで、もし、残りトラック数がＮ₁ より
も小さい場合は、データ部１０の記録領域がなくなった
と判断して、記録処理をエラー終了する。一方、残りト
ラック数がＮ₁ よりも大きい場合は、図８の光カードの
データ部１０のＷＤＴ＿ＴＲＫで示される情報トラック
に１セクタ分のデータを記録する（Ｓ６）。次いで、１
セクタのデータを記録したことによりＷＤＴ＿ＴＲＫ、
ＥＯＳ＿ＴＲＫをそれぞれ更新し（Ｓ７）、１ファイル
のデータを記録したかどうかが判断する（Ｓ８）。記録
していないデータが残っていれば、再びＳ５に戻って同
様の処理を行い、このＳ５〜Ｓ８の処理を繰り返すこと
によってファイルデータを光カードの情報トラックに１
セクタづつ記録していく。

【００１０】ファイルデータの記録を終了すると、先に
検出した最終ディレクトリのトラックのＥＯＤ＿ＴＲＫ
から次に記録するディレクトリのトラックＷＤＲ＿ＴＲ
Ｋを引いた値と予め決められた値Ｎ₂ を比較する（Ｓ
９）。Ｎ₂ は前述のように光カードの最終ディレクトリ
の記録位置を検出するのに用いる値で、最終データの記
録位置を検出するのに用いるＮ₁ よりも小さく設定され
た数値である。また、ＥＯＤ＿ＴＲＫからＷＤＲ＿ＴＲ
Ｋを引いた値は、光カードの全トラックにおけるデータ
部とディレクトリ部の残りトラック数を表わす。ここ
で、この残りトラック数とＮ₂ を比較すると、Ｎ₁ ＞Ｎ
₂ に設定されているために、比較結果は必らずＥＯＤ＿
ＴＲＫ−ＷＤＲ＿ＴＲＫ＞Ｎ₂ となり、ディレクトリを
記録するための記録領域がなくなることはない。

【００１１】次いで、先に記録されたファイルデータを
管理するためのディレクトリ、即ち図９のファイル名、
ファイル長などのファイル管理情報を光カードのディレ
クトリ部２０に記録する（Ｓ１０）。また、ディレクト
リを記録したことによりＷＤＲ＿ＴＲＫとＥＯＤ＿ＴＲ
Ｋをそれぞれ更新する（Ｓ１１）。このトラックの更新
処理は図８に示したように、１トラックに４つのディレ
クトリが記録されるために、ディレクトリを４回記録す
るごとに１回の更新を行う。以上で一連のファイルデー
タの記録処理を終了する。この記録方法によれば、光カ
ードに順次ファイルデータを記録していってデータ部の
記録領域がなくなったとしても、Ｎ₁ −Ｎ₂ の分を最終
ディレクトリを記録するためのトラックとして確保する
ことができ、ファイルデータは記録したにも拘わらずデ
ィレクトリは記録できないということはなく、最後に記
録したファイルのデータのディレクトリを必らず記録す
ることができる。

【００１２】また、本願出願人は、複数のファイルをラ
イトモードで同時にオープンして各々のファイルに情報
を記録する方法を、特願平９−３４８０９号として出願
している。この記録方法は、記録媒体にファイルデータ
を記録する場合、ホストコンピュータのバッファメモリ
がなくなったときにバッファメモリのデータを記録媒体
に記録し、また、記録したデータを管理する情報をメモ
リに蓄え、ファイルのクローズ時にメモリに蓄えた管理
情報をディレクトリとして記録するというものである。
以上の２つの情報記録方法においては、ファイルが記録
モードでオープンされ、何もデータを記録せずにクロー
ズしてもファイルのエントリのみ作成する必要があるた
め、ディレクトリを記録する必要がある。

【００１３】

【発明が解決しようとする課題】ところで、従来におい
ては、ホストコンピュータに外部記憶装置を接続し、ホ
ストコンピュータによって外部記憶装置を制御すること
で光カードに情報を記録または再生している。ホストコ
ンピュータ上のソフトウェアの構成としては、アプリケ
ーション、ＯＳ（基本ソフト）、デバイスドライバーか
らなっていて、アプリケーションの指示のもとにデバイ
スドライバーによって外部記憶装置を制御している。こ
こで、上記従来例の複数のファイルをライトモードで同
時にオープンして記録する方法においては、ファイルの
記録を担うデバイスドライバーはバッファメモリに蓄積
されたデータやファイルのクローズ時に記録するディレ
クトリを考慮せずに記録担体の実際の残り容量（未記録
領域）によってアプリケーションから渡されたデータを
記録可能か否かを判断している。

【００１４】しかしながら、このような方法では、未記
録領域がわずかでも残っていれば、デバイスドライバー
はアプリケーションからのデータをキャッシュ（バッフ
ァメモリ）に蓄えるので、キャッシュのデータ量の合計
が未記録領域の容量を越えることがある。そのため、フ
ァイルのクローズ時にキャッシュのデータを記録担体に
記録できないことがあった。更に、バッファメモリのデ
ータやファイルのクローズ時のディレクトリを考慮せず
にアプリケーションからのライトモードのファイルオー
プンを無条件に許可しているので、ライトモードで多く
のファイルが同時にオープンされ、クローズされたとき
にディレクトリを記録するのに必要な領域が未記録領域
の容量を越えてしまうことがあり、すべてのディレクト
リを記録できないという問題があった。

【００１５】また、図１０で説明した記録方法では、Ｎ
₁ （最終データ記録位置を検出するのに用いる数値）と
Ｎ₂ （最終ディレクトリ記録位置を検出するのに用いる
数値）との差は、データ記録終了後に記録できるディレ
クトリの個数Ｒを表わす。しかし、Ｒがシステム固定で
あると、Ｒ個を越える多くのファイルがライトモードで
同時にオープンされた場合、すべてのファイルをクロー
ズするときに、ディレクトリをすべて記録できないとい
う問題があった。

【００１６】更に、本願出願人は、特開昭６３−６９０
７２号公報及び特開昭６３−９１８８８号公報において
消去ディレクトリを用いて記録媒体の不要なデータを論
理的に消去する方法を提案している。即ち、追記型記録
媒体において実際には消去することができないファイル
に関してファイルを消去したことを示す消去ディレクト
リを新たにディレクトリ部に記録することにより、ファ
イルを論理的に消去したものとして扱うというものであ
る。また、この消去ディレクトリを用いることにより、
ファイル名の変更も可能である。ファイル名を変更する
場合は、消去ディレクトリを記録後、ファイル名のみ異
なり、先頭データトラック番号などのアドレス情報は同
一の新たなディレクトリを記録すればよい。これは、フ
ァイルの属性などを変更する場合にも応用が可能であ
る。

【００１７】ところで、前述のように複数のファイルを
ライトモードで同時にオープンして記録する方法では、
バッファメモリのデータやファイルのクローズ時に記録
するディレクトリを考慮せずにアプリケーションからフ
ァイルの消去命令やファイル名の変更命令を実行してい
る。しかしながら、ライトモードで複数のファイルが同
時にオープンしている間、クローズしているファイルの
消去命令が発行されると、消去ディレクトリを記録して
しまう。また、ファイル名の変更命令が発行されると、
消去ディレクトリと変更後のファイル名の変更のための
ディレクトリの２つのディレクトリを記録してしまう。
そのため、記録担体の残り容量が減少し、消去するファ
イル数やファイル名を変更するファイル数によってはオ
ープンしているファイルをクローズするときに、バッフ
ァメモリの記録データやディレクトリを記録する領域が
不足し、すべてのデータやディレクトリを記録できない
ことがあった。

【００１８】本発明は、上記従来の問題点に鑑み、記録
担体の容量が不足することなく、データやディレクトリ
を確実に記録することが可能な情報記録方法を提供する
ことを目的とする。

【００１９】

【課題を解決するための手段】本発明の目的は、ファイ
ルへのアクセス要求を実行する前に、データを記録する
情報記録担体の残り容量、前記アクセス要求を実行した
ときにデータを記録するのに必要と予測される容量、及
びディレクトリを記録するのに必要と予測される容量に
基づいて前記アクセス要求を実行するか否かを判断する
ことを特徴とする情報記録方法によって達成される。

【００２０】また、本発明の目的は、ファイルごとに記
録要求のデータを蓄積するためのバッファメモリと、フ
ァイルデータを管理するための管理情報を格納するメモ
リとを用い、複数のファイルを同時にオープンして各々
のファイルのデータを情報記録担体に記録し、且つファ
イルのクローズ時に前記メモリの管理情報を前記記録担
体にディレクトリとして記録する方法において、前記フ
ァイルへのアクセス要求を実行する前に、前記記録担体
の残り容量、前記アクセス要求を実行したときにデータ
を記録するのに必要と予測される容量、オープンしてい
るすべてファイルをクローズしたときにディレクトリを
記録するのに必要と予測される容量に基づいて前記アク
セス要求を実行するか否かを判断することを特徴とする
情報記録方法によって達成される。

【００２１】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を参照して詳細に説明する。まず、本発明の第１
の実施形態について説明する。図１は本発明の情報記録
方法に係るホストコンピュータと情報記録再生装置から
なる情報記録再生システムの構成例を示している。図１
において、３１は情報記録担体に情報を記録、再生する
情報記録再生装置（以下、ドライブという）である。ド
ライブ３１は上位制御装置のホストコンピュータ３２に
接続され、ホストコンピュータ３２の制御に基づいて情
報の記録、再生を行う。情報記録担体としては図８の光
カード１を用いている。３７は不図示の搬送機構を駆動
して、光カード１をドライブ３１内の所定位置に導入
し、また、所定位置にて光カード１をＲ方向に往復移動
させ、更に光カード１を機外に排出するためのカード送
りモータである。３８は光源の半導体レーザを含む光ビ
ーム照射光学系であり、情報の記録、再生時には光源の
光ビームを微小光スポットに絞って光カード１上に照射
する。

【００２２】また、３９は光カード１から反射された光
を検出する光検出器、４０は光ビーム照射光学系３８の
一部を駆動して光カード１面上の光スポットのピント位
置をＺ方向、即ち光カード面と垂直方向に移動させてオ
ートフォーカス制御を行うためのＡＦアクチュエータ、
４１は光ビーム照射光学系３８の一部を駆動して光カー
ド１面上の光スポットをＹ方向、即ち光カードの情報ト
ラックに直交する方向に移動させてオートトラッキング
制御を行うためのＡＴアクチュエータである。これらの
光ビーム照射光学系３８、光検出器３９、ＡＦアクチュ
エータ４０、ＡＴアクチュエータ４１を含んで光ヘッド
５０が構成されている。３６は光ヘッド５０をＹ方向に
移動させて光スポットを所望のトラックにアクセスする
ためのヘッド送りモータである。

【００２３】ＭＰＵ３３はドライブ３１内の各部を制御
するためのプロセッサ回路であってＲＯＭ、ＲＡＭを内
蔵している。ＭＰＵ３３はヘッド送りモータ３６、カー
ド送りモータ３７などを制御し、また、ホストコンピュ
ータ３２とデータの送受信を行う。ＡＴ／ＡＦ制御回路
３４は光検出器３９からの出力信号をもとにＡＦアクチ
ュエータ４０とＡＴアクチュエータ４１を駆動し、光ビ
ーム照射光学系３８からの光スポットがカード面に焦点
を結ぶように、また、光スポットが情報トラックに追従
して走査するように、オートフォーカス制御とオートト
ラッキング制御を行う。

【００２４】変復調回路３５はＭＰＵ３３の制御に基づ
いて記録情報を変調し、再生情報を復調するための回路
である。情報の記録時には、ホストコンピュータ３２か
らの記録データを変復調回路３３で変調し、変調信号に
応じて光ビーム照射光学系３８内の光源を駆動すること
によって、光カード１上に情報の記録を行う。また、情
報の再生時には、光ビーム照射光学系３８から光カード
１に再生用の光ビームを照射し、光検出器３９で光カー
ド１からの反射光を検出し、変復調回路３５で光検出器
３９の信号をもとに記録情報を復調する。復調された情
報はＭＰＵ３３からホストコンピュータ３２に転送され
る。なお、一般に光カード１は媒体の性質上エラー率が
高いので、信頼性の高い情報記録が要求される場合は、
誤り訂正手段が必要である。

【００２５】ここで、通常、ホストコンピュータ３２に
は、２次記憶装置としてハードディスクやフロッピーデ
ィスクが搭載され、これらのハードディスクやフロッピ
ーディスクのデバイスドライバーは予めオペレーティン
グシステム（ＯＳ）に標準で装備されている。一方、新
規デバイスである光カード用のデバイスドライバーはド
ライブメーカーが提供しており、従来のデバイスと同様
の機能を提供することによって、アプリケーションの開
発を容易にしている。

【００２６】図２はホストコンピュータ３２内のソフト
ウェアの概念図を示している。まずアプリケーションＳ
Ｆ１からのファイルのオープン、クローズ、あるいは記
録、再生などの要求は、オペレーティングシステム（Ｏ
Ｓ）ＳＦ２を介してデバイスドライバーＳＰ３に伝えら
れる。デバイスドライバーＳＦ３では、与えられた要求
に対してハードウェアを直接操作し、ホストコンピュー
タ３２の外部に接続されたドライブ３１を動作させる。
また、デバイスドライバーＳＦ３はドライブ３１の動作
結果をオペレーティングシステムを介してアプリケーシ
ョンＳＦ１に通知する。

【００２７】ここで、例えば、デバイスドライバーＳＦ
３はアプリケーションＳＦ１からの記録要求に対し、外
部のドライブ３１を動作させずに、記録データをデバイ
スドライバーＳＦ３の内部のバッファメモリ（キャッシ
ュ）に保存するキャッシュ技術を用いる場合がある。光
カードのような書き換え不可能な記録担体においてはア
プリケーションＳＦ１から渡された１セクタに満たない
データを記録すると、冗長が増すため、ライトキャッシ
ュ技術は必須となっている。

【００２８】次に、本発明の第１の実施形態による情報
記録方法を図３を参照しながら説明する。なお、本実施
形態では、図２のデバイスドライバーＳＦ３はアプリケ
ーションＳＦ１から記録要求のあったデータはすべてバ
ッファメモリ（ライトキャッシュ）に蓄えるものとし、
また、デバイスドライバーＳＦ３のライトキャシュの大
きさは便宜的に無限であるものとする。また、本実施形
態では、特願平９−３４８０９号に記載しているよう
に、複数のファイルごとに記録データを蓄積するための
バッファメモリとファイルを管理するワークメモリを備
えている。そして、アプリケーションからの記録要求の
データをファイルごとにバッファメモリに蓄積し、バッ
ファメモリが一杯になったらバッファメモリのデータを
記録担体に記録し、更に、ファイルのクローズ時にワー
クメモリの管理情報を記録担体にディレクトリとして記
録するものとする。これは、以下のすべての実施形態に
おいて同じである。

【００２９】図３において、まず、本実施形態では、ア
プリケーションからファイルの書き込み要求が発行され
たものとする。デバイスドライバーは書き込み要求を受
け取ると、図８の光カードの最終ディレクトリ（ＥＯ
Ｄ）の記録位置、及び最終データ（ＥＯＳ）の記録位置
を検索する処理を行う（Ｓ３０１〜Ｓ３０４）。このＥ
ＯＤとＥＯＳを検索する処理は図１０のＳ１〜Ｓ４の処
理と同じである。また、本実施形態では、ＥＯＤとＥＯ
Ｓを検出する場合、特開平１−４３８４４号公報に記載
されているようにディレクトリが記録されているトラッ
クから未記録のトラックが連続して所定数Ｎ続いたとき
に、そのディレクトリとＥＯＳとして検出し、同様にデ
ータが記録されているトラックから未記録のトラックが
連続して所定数Ｎ続いたときに、そのデータをＥＯＳと
して検出するものとする。これも、以下のすべての実施
形態において同じである。

【００３０】ＥＯＤとＥＯＳを検出すると、デバイスド
ライバーはバッファメモリ上のデータと記録要求のデー
タの両方を光カードに記録したときに必要と予測される
トラック数ＣＡＳ＿ＴＲＫ、ファイルのクローズ時にデ
ィレクトリを記録するのに必要と予測されるトラック数
ＣＡＤ＿ＴＲＫを考慮して、記録要求のデータを光カー
ドに記録可能か否かを判断する（Ｓ３０５）。具体的に
は、ＥＯＤのアドレスをＥＯＤ＿ＴＲＫ、次に記録する
トラックをＷＤＴ＿ＴＲＫとして、ＷＤＴ＿ＴＲＫ−ＥＯＤ＿ＴＲＫ−（ＣＡＤ＿ＴＲＫ＋ＣＡＳ＿ＴＲＫ）≧Ｎ …（１）の演算を行い、（１）式の結果によって光カードに記録
要求のデータを記録可能かどうかを判断する。

【００３１】ここで、（ＷＤＴ＿ＴＲＫ−ＥＯＤ＿ＴＲ
Ｋ）は光カード全体の残り容量、（ＣＡＤ＿ＴＲＫ＋Ｃ
ＡＳ＿ＴＲＫ）はこれからデータとディレクトリを記録
するのに必要な容量である。従って、Ｓ３０５の判定結
果がＹＥＳであれば、光カードに最小限必要なトラック
数Ｎ以上の残り容量があるので、記録要求のデータをバ
ッファメモリに格納して（Ｓ３０６）、処理を終了す
る。但し、記録要求のデータとバッファメモリ上のデー
タがファイル内の領域において重複している場合は、重
複している領域について記録要求のデータをバッファメ
モリのデータに上書きし、残りの記録要求のデータをバ
ッファメモリに格納する。一方、Ｓ３０５の判定がＮＯ
であれば、光カードの残り容量がＮ以下であるので、ア
プリケーションに記録領域がない旨を通知して処理をエ
ラー終了する。

【００３２】また、ＣＡＳ＿ＴＲＫを算出する場合、例
えば次のように算出する。即ち、バッファメモリ上に存
在するデータを記録するために必要なセクタ数をｎ、記
録要求のデータを記録するために必要なセクタ数をＬ、
Ｌとｎのファイル上の領域で重複するセクタ数をｖ、デ
ータ領域の１トラック当りのセクタ数をｒ、ＥＯＤトラ
ックの未記録セクタ数をｗとすると、ＣＡＳ＿ＴＲＫ
は、ＣＡＳ＿ＴＲＫ＝（Ｌ＋ｎ−ｖ−ｗ＋ｒ−１）／ｒ … （２）の演算によって得られる。但し、この計算は整数域で行
う。

【００３３】更に、ＣＡＤ＿ＴＲＫは、例えば次のよう
に算出する。即ち、ライトモードでオープンしているフ
ァイル数をＫ（Ｋ＞０）、ＥＯＤトラックの未記録セク
タ数をｐ、ディレクトリ領域の１トラック当りのセクタ
数をｑとすると、ＣＡＤ＿ＴＲＫは、ＣＡＤ＿ＴＲＫ＝（ｋ−ｐ＋ｑ＋１）／ｑ … （３）の計算によって得られる。但し、この計算も整数域で行
うものとする。

【００３４】次に、ファイルのクローズ処理について図
４を参照して説明する。図４において、まず、アプリケ
ーションからファイルのクローズ要求が発行されると、
デバイスドライバーは図１のドライブ３１を制御して該
当するファイルのバッファメモリ上のすべてのデータを
光カードのデータ領域に記録する（Ｓ４０１）。次い
で、図９のファイル名、ファイル長、先頭データのトラ
ック番号などの情報をディレクトリとして光カードのデ
ィレクトリ領域に記録する（Ｓ５０２）。また、データ
とディレクトリを記録したので、ＷＤＴ＿ＴＲＫとＥＯ
Ｄ＿ＴＲＫをそれぞれ更新して（Ｓ５−３）、ファイル
のクローズ処理を終了する。

【００３５】本実施形態では、光カードの残りの容量、
バッファメモリのデータと記録要求のデータを記録する
のに必要な容量、及びオープンしているすべてのファイ
ルのクローズ時にディレクトリを記録するのに必要な容
量に基づいて光カードにデータを記録するか否かを判断
しているので、バッファメモリ上のデータを確実に記録
することができる。また、ライトモードでオープンして
いるすべてのファイルをクローズする場合、すべてのフ
ァイルのディレクトリを確実に記録することができる。

【００３６】次に、本発明の第２の実施形態を図５を参
照して説明する。本実施形態では、第１の実施形態と同
様に図２のデバイスドライバーはアプリケーションから
記録要求のあったデータをすべてバッファメモリに蓄
え、デバイスドライバーのバッファメモリの大きさは無
限であるものとする。図５において、まず、本実施形態
では、アプリケーションからライトモードのファイルオ
ープン要求から発行されたものとする。デバイスドライ
バーはファイルオープン要求を受け取ると、Ｓ５０１〜
Ｓ５０４で光カードの最終ディレクトリ記録位置（ＥＯ
Ｄ）、最終データ記録位置（ＥＯＳ）を検出する処理を
行う。ＥＯＳとＥＯＤは、第１の実施形態と同様にディ
レクトリやデータが記録されたトラックから各々未記録
のトラックが連続して所定数Ｎ続いたときに、そのディ
レクトリやデータをＥＯＤ，ＥＯＳとして検出する。

【００３７】ＥＯＤとＥＯＳを検出すると、デバイスド
ライバーは次にバッファメモリ上のデータを光カードに
記録したときに必要と予想されるトラック数ＣＡＳ＿Ｔ
ＲＫと現在ライトモードでオープンしているファイル数
を考慮して、ライトモードのファイルオープンを許可す
るか否かを判断する（Ｓ５０５）。即ち、ＥＯＤのアド
レスをＥＯＤ＿ＴＲＫ，ＥＯＳのアドレスをＥＯＳ＿Ｔ
ＲＫ、ライトモードでオープンしているファイル数を
ｋ，ＥＯＤトラックの未記録トラックをｐ、ディレクト
リ領域の１トラック当りのセクタ数をｑとすると、ｑ（ＥＯＤ＿ＴＲＫ−ＥＯＳ＿ＴＲＫ−１−Ｎ−ＣＡＳ＿ＴＲＫ）＋ｐ＞Ｋ …（４）の演算処理を行い、（４）式の演算結果によってファイ
ルオープン要求を実行するか否かを判定する。

【００３８】ここで、（ＥＯＤ＿ＴＲＫ−ＥＯＳ＿ＴＲ
Ｋ−１）は光カード全体の残り容量を表わし、これから
（Ｎ−ＣＡＳ＿ＴＲＫ）を減算した値は、光カードのデ
ィレクトリ領域の記録可能なトラック数を表わす。従っ
て、このトラック数にディレクトリ領域のセクタ数ｑを
乗算すると、ディレクトリ領域の未記録トラックのセク
タ数が得られ、これにＥＯＤトラックの未記録セクタ数
ｐを加算すると、ディレクトリ領域全体の残りのセクタ
数が得られる。よって、Ｓ５０５において、もし（４）
式による判定結果がＮＯであれば、現在オープンしてい
るファイル数Ｋよりも光カードのディレクトリ領域の残
りセクタ数が少なく、ディレクトリ領域の容量が不足し
ているので、アプリケーションにライトモードのオープ
ンを不許可にする旨を通知する。一方、（４）式による
判定結果がＹＥＳであれば、現在オープンしているファ
イル数ｋよりもディレクトリ領域の残りセクタ数が大き
いので、アプリケーションにライトモードのファイルオ
ープンを許可する旨を通知する。

【００３９】ここで、ＣＡＳ＿ＴＲＫは算出する場合
は、バッファメモリに存在するデータを記録するために
必要なセクタ数をｎ、データ領域の１トラック当りのセ
クタ数をｒ、ＥＯＳトラックの未記録セクタ数をｗとす
ると、（ｎ−ｗ＋ｒ−１）／ｒ … （５）によってＣＡＳ＿ＴＲＫが得られる。但し、この計算は
整数域で行う。また、アプリケーションからファイルの
クローズ要求が発行されると、デバイスドライバーは図
４のクローズ処理を実行する。図４の処理については先
に詳しく述べたので、説明を省略する。

【００４０】本実施形態では、光カードの残り容量、バ
ッファメモリのデータを記録するのに必要な容量、オー
プンしているすべてのファイルをクローズしたときにデ
ィレクトリを記録するのに必要な容量に基づいてライト
モードのファイルオープンを実行するか否かを判定して
いるので、ライトモードでオープンしている複数のファ
イルをクローズするときに、ディレクトリ領域が不足す
ることはなく、すべてのファイルのディレクトリを確実
に記録することができる。

【００４１】次に、本発明の第３の実施形態を図６を参
照して説明する。本実施形態では、第１、第２の実施形
態と同様にアプリケーションからの記録要求のデータを
すべてバッファメモリに蓄え、バッファメモリの容量は
無限であるものとする。図６において、まず、本実施形
態では、アプリケーションから既存のファイルの消去命
令が発行されたものとする。ファイルの消去は前述のよ
うにファイルの消去を示すディレクトリを光カードに記
録することによってファイルを擬似的に消去するもので
ある。デバイスドライバーはファイルの消去命令が発行
されると、Ｓ６０１〜Ｓ６０４でＥＯＤとＥＯＳを検出
する処理を行う。ＥＯＤとＥＯＳの検出方法は第１、第
２の実施形態と同様である。

【００４２】ＥＯＤとＥＯＳを検出すると、デバイスド
ライバーは次にバッファメモリ上のデータを光カードに
記録するときに必要と予測されるトラック数ＣＡＳ＿Ｔ
ＲＫと現在オープンしているファイル数を考慮して、フ
ァイルの消去命令を実行するか否かを判断する（Ｓ６０
５）。即ち、図５のＳ５０５の（４）式の計算を行い、
その結果によって消去命令を実行するかどうかを判断す
る。（４）式については詳しい説明は省略するが、光カ
ードのディレクトリ領域の残りセクタ数を算出し、それ
と現在ライトモードでオープンしているファイル数ｋを
比較する。もしＳ６０５の判定結果がＮＯであれば、光
カードのディレクトリ領域の容量が不足し、現在オープ
ンしているファイルのディレクトリを記録できないの
で、アプリケーションにファイルの消去命令を実行でき
ない旨を通知してエラー終了する。一方、Ｓ６０５の判
定がＹＥＳであれば、光カードのディレクトリ領域の残
りセクタ数がオープンしているファイル数ｋよりも大き
いので、ドライブ３１を制御して光カードに該当するフ
ァイルの消去ディレクトリを記録する（Ｓ６０６）。ま
た、アプリケーションからファイルのクローズ要求が発
行されると、デバイスドライバーは同様に図４のクロー
ズ処理を実行する。

【００４３】本実施形態では、光カードの残り容量、バ
ッファメモリのデータを記録するのに必要な容量、現在
オープンしているすべてのファイルのクローズ時にディ
レクトリを記録するのに必要な容量に基づいてファイル
の消去命令を実行するか否かを判断しているので、消去
ディレクトリを記録してもライトモードでオープンして
いるすべてのファイルをクローズしたときに記録領域が
不足することはなく、バッファメモリのデータやすべて
のファイルのディレクトリを確実に記録することができ
る。

【００４４】次に、本発明の第４の実施形態を図７を参
照して説明する。本実施形態では、第１〜第３の実施形
態と同様にアプリケーションからの記録要求のデータは
すべてバッファメモリに蓄え、バッファメモリの容量は
無限であるものとする。図７において、まず、本実施形
態では、アプリケーションから既存のファイルのファイ
ル名の変更要求が発行されたものとする。ファイル名を
変更するには、前述のようにもとのファイルを消去する
消去ディレクトリと変更後のファイルを管理するための
ディレクトリ（ファイル名のみが異なり、先頭データト
ラック番号などは同じ）の２つのディレクトリを記録す
る必要がある。デイスドライバーではファイル名の変更
要求を受け取ると、Ｓ７０１〜Ｓ７０４でＥＯＤとＥＯ
Ｓを検出する処理を行う。ＥＯＤとＥＯＳの検出方法
は、第１〜第３の実施形態と同じである。

【００４５】ＥＯＤとＥＯＳを検出すると、デバイスド
ライバーはＳ７０５でファイル名の変更要求を実行する
か否かを判断する。本実施形態では、ＥＯＤのアドレス
をＥＯＤ＿ＴＲＫ、ＥＯＳのアドレスをＥＯＳ＿ＴＲ
Ｋ、バッファメモリ上のデータを記録するのに必要と予
測されるトラック数をＣＡＳ＿ＴＲＫ、ライトモードで
オープンしているファイル数をｋ、ＥＯＤトラックの未
記録トラック数をｐ、ディレクトリ領域の１トラック当
りのセクタ数をｑとして、ｑ（ＥＯＤ＿ＴＲＫ−ＥＯＳ＿ＴＲＫ−１−Ｎ−ＣＡＳ＿ＴＲＫ）＋ｐ＞Ｋ＋１ … （６）の演算処理を行い、（６）式の結果によってファイル名
の変更要求を実行するか否かを判断する。

【００４６】ここで、（６）式の左辺は（４）式の左辺
と全く同じで、光カードのディレクトリ領域の残りセク
タ数を表わす。また、右辺はＫ＋１としており、これは
ファイル名を変更するには２つのディレクトリを記録す
る必要があるので、現在オープンしているファイル数ｋ
に＋１している。もし、Ｓ７０５の判定結果がＮＯであ
れば、デバイスドライバーはオープンしているファイル
がクローズしたときにディレクトリ領域の容量が不足
し、すべてのディレクトリを記録できないので、アプリ
ケーションにエラーを通知して処理を終了する。一方、
Ｓ７０５の判定結果がＹＥＳであれば、アプリケーショ
ンからのファイル名の変更命令を受け付け、該当するフ
ァイルの消去ディレクトリを光カードに記録する（Ｓ７
０６）。次いで、変更後の新規ファイル名を含むディレ
クトリを記録して（Ｓ７０７）、処理を終了する。ま
た、アプリケーションからファイルのクローズ要求があ
った場合は、デバイスドライバーは図４のクローズ処理
を実行する。

【００４７】本実施形態においても、光カードの残り容
量、バッファメモリのデータを記録するのに必要な容
量、オープンしているすべてのファイルのクローズ時に
ディレクトリを記録するのに必要な容量に基づいてファ
イル名の変更要求を実行しているか否かを判断している
ので、ファイル名の変更要求を受け付けたとしても記録
領域が不足することはなく、バッファメモリのデータや
オープンしているすべてのファイルをクローズしたとき
にすべてのファイルのディレクトリを確実に記録するこ
とができる。

【００４８】なお、第４の実施形態では、アプリケーシ
ョンからのファイル名の変更要求を実行するか否かを判
断する場合を説明したが、本発明は、これに限ることな
く、例えばファイルの属性変更要求に対しても使用する
ことが可能である。また、アプリケーションからのファ
イル名の変更要求によって２つのディレクトリを記録す
るか否かを判断する場合を例としているが、本発明は、
１つの要求によって２つ以上のディレクトリを記録する
場合にも使用することができる。この場合は、図７のＳ
７０５で次式の判定を行うことによってアプリケーショ
ンからの要求を実行するか否かを判断するものとする。

【００４９】ｑ（ＥＯＤ＿ＴＲＫ−ＥＯＳ＿ＴＲＫ−１−Ｎ−ＣＡＳ＿ＴＲＫ）＋ｐ＞ｋ＋（ｍ−１） … （７）但し、ｍは１つの要求で記録しなければならないディレ
クトリの数である。またこの計算は整数域で行う。

【００５０】

【発明の効果】以上説明したように本発明によれば、ア
クセス要求を実行する前に、記録担体の残り容量、デー
タやディレクトリを記録するのに必要と予測される容量
に基づいてアクセス要求を実行するか否かを判定してい
るので、ファイルのクローズ時に記録担体の記録領域が
不足することはなく、データやディレクトリを確実に記
録することができる。

【図面の簡単な説明】

【図１】本発明の情報記録方法に係るホストコンピュー
タとドライブからなるシステムの例を示した構成図であ
る。

【図２】図１のホストコンピュータのソフトウェアの概
念図である。

【図３】本発明の情報記録方法の第１の実施形態を示し
たフローチャートである。

【図４】図１の実施形態のファイルのクローズ処理を示
したフローチャートである。

【図５】本発明の第２の実施形態のフローチャートであ
る。

【図６】本発明の第３の実施形態のフローチャートであ
る。

【図７】本発明の第４の実施形態のフローチャートであ
る。

【図８】光カードの平面図である。

【図９】ディレクトリの構成を示した図である。

【図１０】従来例の情報記録方法を示したフローチャー
トである。

【符号の説明】

１光カード１０データ部２０ディレクトリ部３１情報記録再生装置（ドライブ）３２ホストコンピュータＳＰ１アプリケーションＳＰ３デバイスドライバー

Claims

【特許請求の範囲】

【請求項１】ファイルへのアクセス要求を実行する前
に、データを記録する情報記録担体の残り容量、前記ア
クセス要求を実行したときにデータを記録するのに必要
と予測される容量、及びディレクトリを記録するのに必
要と予測される容量に基づいて前記アクセス要求を実行
するか否かを判断することを特徴とする情報記録方法。
【請求項２】ファイルごとに記録要求のデータを蓄積
するためのバッファメモリと、ファイルデータを管理す
るための管理情報を格納するメモリとを用い、複数のフ
ァイルを同時にオープンして各々のファイルのデータを
情報記録担体に記録し、且つファイルのクローズ時に前
記メモリの管理情報を前記記録担体にディレクトリとし
て記録する方法において、前記ファイルへのアクセス要
求を実行する前に、前記記録担体の残り容量、前記アク
セス要求を実行したときにデータを記録するのに必要と
予測される容量、及びオープンしているすべてのファイ
ルをクローズしたときにディレクトリを記録するのに必
要と予測される容量に基づいて前記アクセス要求を実行
するか否かを判断することを特徴とする情報記録方法。
【請求項３】前記アクセス要求はファイルの書き込み
要求であり、前記記録担体の最終ディレクトリのアドレ
スをＥＯＤ＿ＴＲＫ、次に記録するデータのアドレスを
ＷＤＫ＿ＴＲＫ、前記バッファメモリのデータと記録要
求のデータを記録するのに必要と予測されるトラック数
をＣＡＳ＿ＴＲＫ、ファイルをクローズしたときにディ
レクトリを記録するのに必要と予測されるトラック数を
ＣＡＤ＿ＴＲＫ、最小限必要な残りトラック数をＮとし
たときに、ＷＤＴ＿ＴＲＫ−ＥＯＤ＿ＴＲＫ−（ＣＡＤ
＿ＴＲＫ＋ＣＡＳ＿ＴＲＫ）≧Ｎによって書き込み要求を実行するか否かを判断すること
を特徴とする請求項２に記載の情報記録方法。
【請求項４】前記ＣＡＳ＿ＴＲＫは、前記バッファメモ
リ上のデータを記録するのに必要なセクタ数をｎ、記録
を要求されたデータを記録するのに必要なセクタ数を
Ｌ、前記ｎとＬのファイル上の領域でデータが重複する
セクタ数をｖ、記録担体のデータ領域の１トラック当り
のセクタ数をｒ，データが最後に記録されているトラッ
クの未記録セクタ数をｗとした場合、（Ｌ＋ｎ−ｖ−ｗ
＋ｒ−１）／ｒによって算出することを特徴とする請求
項３に記載の情報記録方法。
【請求項５】前記ＣＡＤ＿ＴＲＫは、ライトモードで
オープンしているファイル数をｋ、ディレクトリ領域の
最終トラックの未記録セクタ数をｐ、ディレクトリ領域
の１トラック当りのセクタ数をｑとした場合、（ｋ−ｐ＋ｑ−１）／ｑによって算出することを特徴と
する請求項３に記載の情報記録方法。
【請求項６】前記書き込み要求のデータと前記バッフ
ァメモリのデータがファイル内の領域において重複して
いる場合は、重複している領域について記録要求のデー
タをバッファメモリ上のデータに上書きし、残りの書き
込み要求のデータをバッファメモリに格納することを特
徴とする請求項３に記載の情報記録方法。
【請求項７】前記アクセス要求は、ライトモードのフ
ァイルオープン要求、消去ディレクトリを記録すること
によってファイルを消去するファイルの消去要求、ファ
イル名の変更要求、またはファイルの属性変更要求であ
り、前記記録担体の最終ディレクトリのアドレスをＥＯ
Ｄ＿ＴＲＫ、最終データのアドレスをＥＯＳ＿ＴＲＫ、
最小限必要な残りトラック数をＮ、前記バッファメモリ
のデータを記録するのに必要と予測されるトラック数を
ＣＡＳ＿ＴＲＫ、ライトモードでオープンしているファ
イル数をｋ、最終ディレクトリのトラックの未記録セク
タ数をｐ、ディレクトリ領域の１トラック当りのセクタ
数をｑ、１つの要求で記録しなければならないディレク
トリの数をｍとしたときに、ｑ（ＥＯＤ＿ＴＲＫ−ＥＯ
Ｓ＿ＴＲＫ−１−Ｎ−ＣＡＳ＿ＴＲＫ）＋ｐ＞ｋ＋（ｍ
−１）によって前記アクセス要求を実行するか否かを判断する
ことを特徴とする請求項２に記載の情報記録方法。
【請求項８】前記ＣＡＳ＿ＴＲＫは、前記バッファメ
モリのデータを記録するのに必要なセクタ数をｎ、前記
記録担体のデータ領域の１トラック当りのセクタ数を
ｒ，最終データのトラックの未記録セクタ数をｗとした
ときに、（ｎ−ｗ＋ｒ−１）／ｒによって算出するこ
とを特徴とする請求項７に記載の情報記録方法。