JP2005301853A - 情報処理装置および情報処理方法、並びにプログラムおよび記録媒体 - Google Patents

情報処理装置および情報処理方法、並びにプログラムおよび記録媒体 Download PDF

Info

Publication number
JP2005301853A
JP2005301853A JP2004119851A JP2004119851A JP2005301853A JP 2005301853 A JP2005301853 A JP 2005301853A JP 2004119851 A JP2004119851 A JP 2004119851A JP 2004119851 A JP2004119851 A JP 2004119851A JP 2005301853 A JP2005301853 A JP 2005301853A
Authority
JP
Japan
Prior art keywords
file
data
irp
drive
command
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.)
Granted
Application number
JP2004119851A
Other languages
English (en)
Other versions
JP4241485B2 (ja
Inventor
Makoto Kimura
真 木村
Kazuhisa Tsuchiya
和久 土谷
Nobuhiro Sakai
宣広 酒井
Kazuhiko Watanabe
一彦 渡辺
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.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Priority to JP2004119851A priority Critical patent/JP4241485B2/ja
Priority to EP05252292A priority patent/EP1586988A3/en
Priority to US11/105,650 priority patent/US7769920B2/en
Priority to KR1020050030599A priority patent/KR101116433B1/ko
Priority to CNB2005100788275A priority patent/CN100399310C/zh
Publication of JP2005301853A publication Critical patent/JP2005301853A/ja
Application granted granted Critical
Publication of JP4241485B2 publication Critical patent/JP4241485B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0613—Improving I/O performance in relation to throughput
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/0674—Disk device
    • G06F3/0677—Optical disk device, e.g. CD-ROM, DVD
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/11—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information not detectable on the record carrier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

【課題】内部にファイルシステムを有する記録又は再生装置を、容易に扱う。
【解決手段】 PC１のファイルシステムドライバであるPD_FS５４では、アプリケーションがファイル操作に関するAPI関数を呼び出すことにより供給されるIRP(I/O Request Packet)が、ドライブ２とのIEEE1394通信においてファイルシステムを扱うことが可能な、SBP2を拡張したPD-SBP2のコマンドに変換されるユーザ定義のIOCTLを発行する関数IoCallDriver()に変換される。そして、その関数IoCallDriverが呼び出されることにより、PDストレージ５５は、PD-SBP2のコマンドを、ドライブ２に出力する。これにより、PC１からは、ドライブ２の仮想ファイルシステム６２をそのまま利用することができる。本発明は、例えば、ファイルシステムドライバに適用できる。
【選択図】図６

Description

本発明は、情報処理装置および情報処理方法、並びにプログラムおよび記録媒体に関し、特に、例えば、内部にファイルシステムを有するディスクドライブなどの記録又は再生装置を、汎用のコンピュータで、容易に扱うことができるようにする情報処理装置および情報処理方法、並びにプログラムおよび記録媒体に関する。
近年、例えば、光ディスクに、高ビットレートのAV（Audio Visual）データを記録し、再生することが要請されている。
そこで、例えば、ビデオデータや、それに付随するオーディオデータなどの複数のデータ系列それぞれを、周期的に、かつ、その境界が光ディスクのセクタ等の境界に一致するように、光ディスクに記録するディスクドライブを本件出願人は先に提案している（例えば、特許文献１参照）。
このディスクドライブによれば、ビデオデータやオーディオデータが、ある程度まとめて、光ディスク上の連続した記録領域に記録されるので、そのまとまったデータを、シークなしで読み書きすることができる。
さらに、ビデオデータとオーディオデータとの境界が、光ディスクのセクタの境界に一致するので、１つのセクタに、ビデオデータとオーディオデータとが混在しない。このため、例えば、ビデオデータだけ、またはオーディオデータだけを読み出すことができる。即ち、例えば、ビデオデータだけを必要とするときに、光ディスクから、ビデオデータだけを読み出すことができ、１つのセクタに、ビデオデータとオーディオデータとが混在する場合に比較して、ビデオデータだけを効率良く（高速に）読み出すことができる。オーディオデータについても同様である。
特開2004-005895号公報。
本件出願人は、さらに、例えば、光ディスクの記録領域上の所定の大きさ以上の連続した空き領域のうち、直前にデータが記録された記録領域に最も近い位置の空き領域を予約し、その空き領域に、データを記録するディスクドライブも提案している。
この場合、理想的には、ある一連のデータは、光ディスク上の連続した記録領域に、いわば一筆書きされるように記録される。従って、データの記録再生時に、シークの発生を抑制することができ、高ビットレートのAVデータを、リアルタイムで光ディスクに記録し、また、光ディスクから高ビットレートのAVデータを、リアルタイムで再生することができる。
ここで、このように、光ディスクの記録領域上の所定の大きさ以上の連続した空き領域のうち、直前にデータが記録された記録領域に最も近い位置の空き領域を予約し、データを記録することによって、データの記録再生時に生じるシークの発生を抑制するディスクドライブを、以下、適宜、プロフェッショナルディスクドライブという。
また、プロフェッショナルディスクドライブによって、データが記録された光ディスクを、以下、適宜、プロフェッショナルディスクという。さらに、プロフェッショナルディスクを、以下、適宜、PD(Professional Disc)と略す。また、光ディスク上の連続した記録領域に一筆書きされるようなデータの記録を、以下、適宜、一筆書き記録という。
PDドライブでは、ファイルシステム(File System)として、例えば、UDF(Universal Disk Format)が採用され、さらに、AVデータをUDFの形式で一筆書き記録する制御が行われる。また、PDドライブでは、ファイルのアロケーション(File Allocation)管理や、光ディスク(PD)におけるディフェクト(Defect)に対するディフェクト処理、空き領域管理なども行われる。
ここで、PDドライブのファイルシステムは、上述したような一筆書き記録の制御や、ファイルのアロケーション管理、ディフェクト処理、空き領域管理などを行う機能を有しており、この機能の処理を行う部分を、以下、適宜、PDアロケーションマネージャという。
ところで、最近では、高速なCPU(Central Processing Unit)や、大容量のメモリの低価格化等に伴い、高機能で低価格のコンピュータが実現されている。さらに、そのようなコンピュータにおいて、大容量のAVデータの編集その他の処理を行うアプリケーション（プログラム）（以下、適宜、AVアプリケーションという）も実現されている。
そして、コンピュータに対して、例えば、内蔵する形で、または外付けの形で、PD ドライブを接続し、AVアプリケーションから、PDドライブにアクセスして、PDに対するAVデータの読み書きを行うことの要請が高まってきている。
コンピュータのAVアプリケーションから、PDドライブ（のPD）に対するAVデータの記録や再生を行うには、PDドライブを、コンピュータ（にインストールされているOS(Operating System)）にマウント(Mount)する必要がある。
PDドライブのマウントの方法としては、例えば、コンピュータにインストールされているOSで用意されている汎用のファイルシステムであるUDFや、NTFS(New Technology File System)、FAT(File Allocation Table)などで、PDドライブをマウントする方法がある。
しかしながら、PDドライブを、OSで用意されている汎用のファイルシステムでマウントすると、PDドライブにおいて、一筆書き記録の制御等が行われず、その結果、AVデータをリアルタイムで読み書きすることが保証されなくなる。即ち、一筆書き記録の制御が行われない場合には、AVデータが、いわば細切れの状態で離れた位置に記録されることが生じ、その結果、シークが多発して、高ビットレートのAVデータのリアルタイムで読み書きすることが困難となる。
また、PDドライブの内部のファイルシステムとして、上述したように、UDFが採用されている場合に、PDドライブを、UDFドライバでコンピュータにマウントすると、コンピュータ上のアプリケーションからは、PDドライブにおけるPD上のUDF形式のファイルが、いわば、そのまま見えることになる。
従って、PD上のAVデータのファイルが、例えば、MXF(Material eXchange Format) OP-Atom形式で、同一コンテンツのビデオデータとオーディオデータとが別ファイルとなっており、さらに、オーディオデータについては、チャンネルごとに別ファイルとなっている場合には、コンピュータ上のアプリケーションからは、あるコンテンツのAVデータが、ビデオデータのファイルと、各チャンネルのオーディオデータのファイルとして見えることとなり、取り扱いに不便となる。
一方、PDドライブが内部に有するファイルシステムは、上述したように、一筆書き記録の制御や、ファイルのアロケーション管理、ディフェクト処理、空き領域管理などを行うPDアロケーションマネージャを有している。従って、PDドライブのファイルシステムをそのまま利用することができれば、コンピュータ（のアプリケーション）から、PDドライブを、容易に扱うことができる。
本発明は、このような状況に鑑みてなされたものであり、内部にファイルシステムを有するディスクドライブなどの記録又は再生装置を、容易に扱うことができるようにするものである。
本発明の情報処理装置は、オペレーティングシステムが提供するコマンドを、記録又は再生装置との通信においてファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換手段を備えることを特徴とする。
記録又は再生装置が１のファイルハンドルだけを扱う場合には、情報処理装置には、記録又は再生装置の１つのファイルハンドルに対するアクセスの排他制御を行う排他制御手段をさらに設けることができる。
情報処理装置は、記録又は再生装置のファイルシステムによって行われるファイル管理を行わないファイルシステムドライバとすることができる。
記録又は再生装置においてファイルに読み書きされるデータは、AVデータを、少なくとも含むものとすることができる。
記録又は再生装置は、記録媒体の記録領域上の所定の大きさ以上の連続した空き領域のうち、直前にデータが記録された記録領域に最も近い位置の空き領域を予約し、データを記録するものとすることができる。
本発明の情報処理方法は、オペレーティングシステムが提供するコマンドを、記録又は再生装置との通信においてファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換ステップを含むことを特徴とする。
本発明のプログラムは、オペレーティングシステムが提供するコマンドを、記録又は再生装置との通信においてファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換ステップを含むことを特徴とする。
本発明の記録媒体に記録されているプログラムは、オペレーティングシステムが提供するコマンドを、記録又は再生装置との通信においてファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換ステップを含むことを特徴とする。
本発明においては、オペレーティングシステムが提供するコマンドが、記録又は再生装置との通信においてファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換される。
本発明によれば、内部にファイルシステムを有する記録又は再生装置を、容易に扱うことができる。
以下に本発明の実施の形態を説明するが、請求項に記載の構成要件と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、構成要件に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その構成要件に対応するものではないことを意味するものではない。逆に、具体例が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。
請求項１に記載の情報処理装置は、
ファイルシステム（例えば、図６の実ファイルシステム６１または仮想ファイルシステム６２）を有する記録又は再生装置（例えば、図６のドライブ２）と接続される情報処理装置（例えば、図６のPD_FS５４）において、
アプリケーションからのファイル操作に関する要求（例えば、API関数の呼び出し)に応じてオペレーティングシステムが提供するコマンド(例えば、IRP)を受信する受信手段（例えば、図１４のステップＳ１０１の処理を行う図６のPD_FS５４）と、
前記オペレーティングシステムが提供するコマンドを、前記記録又は再生装置との通信（例えば、IEEE1394の規格に準拠した通信）において前記ファイルシステムを扱うことが可能な通信プロトコル（例えば、SBP2）のコマンドに変換される要求（例えば、ユーザ定義のIOCTLを発行する関数IoCallDriver()）に変換する変換手段（例えば、図１４のステップＳ１０２の処理を行う図６のPD_FS５４）と
を備えることを特徴とする。
請求項２に記載の情報処理装置は、
前記記録又は再生装置が１のファイルハンドルだけを扱う場合において、
前記記録又は再生装置の１つのファイルハンドルに対するアクセスの排他制御を行う排他制御手段（例えば、図１５のファイルハンドルリソースマネージャ５４Ａ）をさらに備える
ことを特徴とする。
請求項６に記載の情報処理方法は、
ファイルシステムを有する記録又は再生装置と接続される情報処理装置の情報処理方法において、
アプリケーションからのファイル操作に関する要求に応じてオペレーティングシステムが提供するコマンドを受信する受信ステップ（例えば、図１４のステップＳ１０１）と、
前記オペレーティングシステムが提供するコマンドを、前記記録又は再生装置との通信において前記ファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換ステップ（例えば、図１４のステップＳ１０２）と
を含むことを特徴とする。
請求項７に記載のプログラムおよび請求項８に記載の記録媒体に記録されているプログラムは、
ファイルシステムを有する記録又は再生装置と接続されるコンピュータに行わせるプログラムにおいて、
アプリケーションからのファイル操作に関する要求に応じてオペレーティングシステムが提供するコマンドを受信する受信ステップ（例えば、図１４のステップＳ１０１）と、
前記オペレーティングシステムが提供するコマンドを、前記記録又は再生装置との通信において前記ファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換ステップ（例えば、図１４のステップＳ１０２）と
を含むことを特徴とする。
以下、図面を参照して、本発明の実施の形態について説明する。
図１は、本発明を適用した情報処理システムの一実施の形態の構成例を示している。
図１において、情報処理システムは、PC(Personal Computer)１とドライブ２とで構成されている。
PC１は、OS(Operating System)や、アプリケーション（プログラム）を記憶しており、OSの制御の下、アプリケーションを実行することで、各種の処理を行う。
ドライブ２は、例えば、上述したPD(Professional Disc)ドライブで、1394ケーブル４を介して、PC１と接続されている。ドライブ２は、PDである光ディスク３の着脱が可能となっており、PC１との間で、IEEE(Institute of Electronic and Electronics Engineers)1394の規格に準拠した通信を行うことにより、光ディスク３に対して、AVデータその他のデータの読み書きを行う。
なお、ドライブ２は、PDドライブである必要はなく、光ディスクもPDである必要はない。また、PC１とドライブ２との間では、IEEE1394以外の規格に準拠した通信を行うことが可能である。
次に、図２は、図１のPC１のハードウェア構成例を示している。
PC１は、CPU(Central Processing Unit)１２を内蔵している。CPU１２には、バス１１を介して、入出力インタフェース２０が接続されており、CPU１２は、入出力インタフェース２０を介して、ユーザによって、キーボードや、マウス、マイク等で構成される入力部１７が操作等されることにより指令が入力されると、それにしたがって、ROM(Read Only Memory)１３に格納されているプログラムを実行する。あるいは、また、CPU１２は、ハードディスク１５に格納されているプログラム、衛星若しくはネットワークから転送され、通信部１８で受信されてハードディスク１５にインストールされたプログラム、またはドライブ１９に装着されたリムーバブル記録媒体２１から読み出されてハードディスク１５にインストールされたプログラムを、RAM(Random Access Memory)１４にロードして実行する。これにより、CPU１２は、後述するフローチャートにしたがった処理、あるいは後述するブロック図の構成により行われる処理を行う。そして、CPU１２は、その処理結果を、必要に応じて、例えば、入出力インタフェース２０を介して、LCD(Liquid Crystal Display)やスピーカ等で構成される出力部１６から出力、あるいは、通信部１８から送信、さらには、ハードディスク１５に記録等させる。
また、PC１においては、入出力インタフェース２０に、IEEE1394の規格に準拠した通信制御を行うIEEE1394I/F(InterFace)２２が接続されている。IEEE1394I/F２２には、1394ケーブル４を介して、ドライブ２が接続されている。CPU１２は、バス１１、入出力インタフェース２０、IEEE1394I/F２２、および1394ケーブル４を介して、ドライブ２にアクセスし、そのドライブ２に装着されている光ディスク３に対して、データを読み書きすることができる。
ここで、CPU１２は、OSや各種のアプリケーションのプログラムを実行するが、これらのプログラムは、PC１に内蔵されている記録媒体としてのハードディスク１５やＲＯＭ１３に予め記録しておくことができる。
あるいはまた、プログラムは、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体２１に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体２１は、いわゆるパッケージソフトウエアとして提供することができる。
なお、プログラムは、上述したようなリムーバブル記録媒体２１からPC１にインストールする他、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、PC１に無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、PC１に有線で転送し、PC１では、そのようにして転送されてくるプログラムを、通信部１８で受信し、内蔵するハードディスク１５にインストールすることができる。
次に、図３は、図２のCPU１２が実行するプログラムを示す図である。
例えば、OS３０、およびアプリケーション３１（のプログラム）が、少なくとも、図２のハードディスク１５にインストールされており、CPU１２は、PC１の電源がオンにされると、ハードディスク１５からRAM１４に、OS３０をロードして実行する。さらに、例えば、ユーザが入力部１７を操作するなどして、アプリケーション３１の起動を要求すると、CPU１２は、ハードディスク１５からRAM１４に、アプリケーション３１をロードし、OS３０の制御の下で実行する。
そして、アプリケーション３１が、例えば、ドライブ２に装着された光ディスク３に対するファイル操作に関する要求であるアクセス要求を行うと、OS３０は、そのアクセス要求を処理する。これにより、ドライブ２において、アプリケーション３１からのアクセス要求によって記録が要求されたデータが、光ディスク３に記録される。あるいは、ドライブ２において、アプリケーション３１からのアクセス要求によって再生（読み出し）が要求されたデータが、光ディスク３から読み出され、OS３０を介して、アクセス要求を行ったアプリケーション３１に渡される。
なお、図２のハードディスク１５にインストールするアプリケーションは、アプリケーション３１の１つに限定されるものではなく、２以上であっても良い。
また、アプリケーション３１は、例えば、外部からのAVデータの取り込みや、AVデータの編集、記録、再生などを行うAVアプリケーションであるとする。但し、アプリケーション３１は、AVアプリケーションである必要はない。即ち、アプリケーション３１は、例えば、テキストデータの編集等を行うアプリケーションであっても良いし、ファイルの表示を行うアプリケーション（例えば、「エクスプローラ」や「ファイルマネージャ」などといったファイルユーティリティ）であっても良い。
次に、OS３０としては、例えば、Unix(R)や、Linux、さらには、マイクロソフト社のWindows(R)と呼ばれているもの、その他の任意のOSを採用することができるが、ここでは、例えば、Windows(R)のNT系のOSが採用されている。なお、Windows(R)のNT系のOSとしては、現在、"Windows(R) NT", "Windows(R) 2000", "Windows(R) XP"がある。
図４は、OS３０として、Windows(R)のNT系のOSが採用されている場合の、ドライブ２（の光ディスク３）へのアクセスに関する部分のOS３０の構成例を示している。
なお、図４では、特に、OS３０におけるデバイスドライバのレイヤ(layer)構成を、アプリケーション３１との関係が分かるように示してある。
Windows(R)のNT系のOSであるOS３０は、カーネル５８に、ハードウェア依存の処理等の必要最小限の処理を行う部分だけを残して、サービスを分離し、その分離したサービスを、サブシステムによって実装している。
Win32サブシステム(Win32 SubSystem)５１は、サブシステムの１つで、アプリケーション３１に対して、各種のAPI（関数）を提供し、例えば、メモリ管理、プロセス管理、グラフィックス描画などを行う。
即ち、Win32サブシステム５１は、アプリケーション３１（を実行しているプロセスまたはスレッド）から、例えば、I/O(Input/Output)関係のAPI関数が呼び出されると、そのAPI関数に応じたI/O要求を、NT入出力マネージャ(NT I/O Manager)５２に出力する。
なお、Win32サブシステム５１が提供するAPI関数としては、例えば、ファイルの生成を行う（ファイルをオープンする）CreateFile()、ファイル（ファイルに記録されたデータ）の読み出しを行うReadFile()、ファイル（ファイルへのデータ）の書き込みを行うWriteFile()、ファイルをクローズするCloseFile()、その他の各種の処理を行うDeviceIoControl()などがある。
NT入出力マネージャ５２は、レイヤ構造のデバイスドライバ(Device Driver)に対して、IRP(I/O Request Packet)を渡すためのサービスを提供する。
ここで、IRPは、デバイスドライバに対して要求する処理の情報を有するパケットで、IRPには、例えば、要求の内容を分類するコード(code)、データ（ファイル）の読み出し（再生）を要求するIRP_MJ_READ、データの書き込み（記録）を要求するIRP_MJ_WRITE、ファイルのオープンを要求するIRP_MJ_CREATE、ファイルのクローズを要求するIRP_MJ_CLOSE、その他の各種の処理を要求するIRP_MJ_DEVICE_CONTROLなどがある。IRP_MJ_DEVICE_CONTROLのIRPでは、サブコード(sub code)として、IOCTL(I/O Control)が指定されるが、このIOCTLは、ユーザ(User)定義が可能になっている。
NT入出力マネージャ５２では、Win32サブシステム５１による、例えば、CreateFile()に応じたI/O要求は、IRP_MJ_CREATEのIRPに変換される。また、例えば、ReadFile()とWriteFile()は、それぞれ、IRP_MJ_READとIRP_MJ_WRITEのIRPに変換され、DeviceIoControl()は、IRP_MJ_DEVICE_CONTROLのIRPに変換される。
ここで、Windows(R)のNT系のOSでは、IRPは、ストレージクラスドライバ(Storage Class Driver)のレイヤ以上のレイヤで使用される。
図４では、ストレージクラスドライバのレイヤ以上のレイヤのデバイスドライバとして、ストレージクラスドライバであるPDストレージ５５、ストレージクラスドライバの１つ上位のレイヤのファイルシステムドライバ(FileSystem Driver)であるPD_FS５４、およびファイルシステムドライバの１つ上位のレイヤのファイルシステムフィルタドライバ(FileSystem Filter Driver)であるFSフィルタドライバ５３の３つのデバイスドライバが存在する。
従って、本実施の形態では、NT入出力マネージャ５２は、これらのFSフィルタドライバ５３、PD_FS５４、PDストレージ５５に対して、IRPを渡すためのサービスを提供する。
具体的には、NT入出力マネージャ５２は、Win32サブシステム５１からのI/O要求を、IRPに変換し、例えば、FSフィルタドライバ５３に出力する。そして、FSフィルタドライバ５３が、NT入出力マネージャ５２からのIRPに応じた要求を、例えば、NT入出力マネージャ５２に出力し、NT入出力マネージャ５２は、FSフィルタドライバ５３からの要求を、IRPに変換して、その１つ下位のレイヤのPD_FS５４に出力する。さらに、PD_FS５４が、NT入出力マネージャ５２からのIRPに応じた要求を、例えば、NT入出力マネージャ５２に出力し、NT入出力マネージャ５２は、PD_FS５４からの要求を、IRPに変換して、その１つ下位のレイヤのPDストレージ５５に出力する。
FS(FileSystem)フィルタドライバ５３は、後述するPD_FS５４の上位のファイルシステムフィルタドライバである。FSフィルタドライバ５３は、アプリケーション３１から、Win32サブシステム５１およびNT入出力マネージャ５２を介して供給される、ファイルシステムに関連するファイルシステム要求その他の要求(request)のフィルタリングを行い、そのフィルタリングの結果、PD_FS５４に渡すべき要求を得て、NT入出力マネージャ５２を介して、PD_FS５４に出力する等の処理を行う。なお、FSフィルタドライバ５３としては、例えば、OS３０としてのWindows(R)のNT系のOSに標準のファイルシステムフィルタドライバを用いることができる。
PD_FS５４は、PDドライブであるドライブ２用の、ファイル管理を行うためのファイルシステムドライバで、FSフィルタドライバ５３からNT入出力マネージャ５２を介して要求されたファイルの書き込みや読み出しなどの要求を、NT入出力マネージャ５２を介して、PDストレージ５５に出力する。
なお、後述するように、論理ブロック単位でのデータの読み書き制御、ファイルのアロケーション管理、ディフェクト処理、空き領域管理などのファイル管理は、ドライブ２のファイルシステムで行われるため、PD_FS５４は、これらのファイル管理（ドライブ２のファイルシステムで行われるファイル管理）は行わない。但し、アプリケーション３１からは、ドライブ２のファイルシステムで行われるファイル管理が、PD_FS５４で行われているように見える。従って、PD_FS５４は、ドライブ２のファイルシステムを偽装しているということができ、かかる観点からは、偽装ファイルシステムということができる。
ここで、ファイルシステムドライバは、一般に、ファイルストリーム(File Stream)（ファイルに記録される（記録された）データのファイル）やファイルメタ(File Meta)情報のキャッシュ(Cache)機能を有し、このキャッシュ機能によれば、例えば、キャッシュされたファイルストリームやファイルメタ情報については、光ディスク３に実際にアクセスせずに、高速に得ることができる。
Windows(R)のNT系のOSでは、NTキャッシュマネージャ(NT Cache Manager)５９が、キャッシュ機能を有しており、PD_FS５４は、NTキャッシュマネージャ５９を利用して、キャッシュ機能を提供する。
なお、PD_FS５４は、ファイルハンドルリソースマネージャ５４Ａを有し、このファイルハンドルリソースマネージャ５４Ａは、後述する排他制御を行う。
PDストレージ５５は、PDドライブであるドライブ２の実際のデバイスドライバにあたるストレージクラスドライバで、上位のレイヤのデバイスドライバであるPD_FS５４から、NT入出力マネージャ５２を介して供給される要求としてのIRPを、例えば、SCSI(Small Computer System Interface)コード(SCSI Code)に変換し、SBP(Serial Bus Protocol)2ドライバ５６に出力する。
ここで、PDストレージ５５において、IRPをSCSIコードに変換するのは、SCSIコードが、後段のSBP2ドライバ５６で扱われるSBP2と、いわば親和性が良いからである。
SBP２ドライバ５６は、PDストレージ５５からのSCSIコードを、SBP2に準拠したデータであるSBP2データに変換し（SBP2プロトコルに変換し）、1394バスドライバ(IEEE1394 bus Driver)５７に供給する。
ここで、本実施の形態では、SBP２ドライバ５６の後段の1394バスドライバ５７により制御されるIEEE1394の規格に準拠した通信においてファイルシステムを扱うことができるプロトコルとして、SBP2を採用しているが、SBP2以外のプロトコルを採用することも可能である。
1394バスドライバ５７は、IEEE1394I/F２２（図２）を制御することにより、SBP2ドライバ５６からのSBP2データなどを、ドライブ２に送信し、また、ドライブ２から送信されてくる、光ディスク３から読み出されたデータを受信する。
ここで、本実施の形態では、PC１とドライブ２との間で、IEEE1394の規格に準拠した通信を行うこととしているが、PC１とドライブ２との間では、その他の通信を行うことが可能である。この場合、1394バスドライバ５７に代えて、PC１とドライブ２との間の通信に対応したバスドライバが用いられる。
なお、AVアプリケーションであるアプリケーション３１は、PDドライブであるドライブ２を使用するのに必要なPD_FS５４、およびPDストレージ５５とともに、例えば、リムーバブル記録媒体２１（図２）に記録して販売することができる。また、アプリケーション３１、PD_FS５４、およびPDストレージ５５が記録されたリムーバブル記録媒体２１は、単体で販売する他、例えば、ドライブ２に同梱し、ドライブ２の付属品として販売することができる。
ここで、図４において、アプリケーション３１と、Win32サブシステム５１とは、ユーザモード(User Mode)で動作し、NT入出力マネージャ５２、FSフィルタドライバ５３、PD_FS５４、PDストレージ５５、SBP2ドライバ５６、1394バスドライバ５７、カーネル５８およびNTキャッシュマネージャ５９は、カーネルモード(Kernel Mode)で動作する。
さらに、図４では、NT入出力マネージャ５２が、IRPを、ファイルシステムフィルタドライバであるFSフィルタドライバ５３や、ファイルシステムドライバであるPD_FS５４を渡すことによって、ファイルシステムフィルタドライバやファイルシステムドライバに対して、処理の要求を行うこととしたが、Windows(R)のNT系のOSのNT入出力マネージャ５２は、IRPの他、FastIOを、ファイルシステムフィルタドライバやファイルシステムドライバに渡すことにより、処理の要求を行うことが可能である。
即ち、NT入出力マネージャ５２は、ファイルシステムフィルタドライバやファイルシステムドライバに対して、IRPの他、FastIOを渡すためのサービスも提供し、これにより、ファイルシステムフィルタドライバやファイルシステムドライバに対して、処理の要求を行う。
従って、Windows(R)のNT系のOSのファイルシステムフィルタドライバやファイルシステムドライバは、一般に、IRPとFastIOの両方をサポートする。
但し、FastIOによれば、例えば、ファイルの読み出し(Read)や書き込み(Write)が、NTキャッシュマネージャ５９に対して直に行われる。
なお、以下では、IRPとFastIOのうちの、例えば、IRPを用いることとする。但し、以下、説明する機能は、FastIOによっても実現することができる。
次に、図５のフローチャートを参照して、アプリケーション３１から光ディスク３に対するアクセスが要求されたときに図４のOS３０で行われるFSフィルタドライバ５３，PD_FS５４，PDストレージ５５，SBP2ドライバ５６，1394バスドライバ５７の処理の概要について説明する。
なお、以下の説明と図５以降の図面においては、それぞれ、Win32サブシステム５１およびNT入出力マネージャ５２の説明と図示を、適宜省略する。
アプリケーション３１が、例えば、光ディスク３に対するアクセスを要求するAPI関数を呼び出すと、そのAPI関数に応じた要求が、Win32サブシステム５１からNT入出力マネージャ５２に供給され、NT入出力マネージャ５２は、Win32サブシステム５１からの要求に応じたIRPが、FSフィルタドライバ５３に供給される。
FSフィルタドライバ５３は、ステップＳ１において、NT入出力マネージャ５２からのIRPを受信し、ステップＳ２に進む。FSフィルタドライバ５３は、ステップＳ２において、NT入出力マネージャ５２からのIRPをフィルタリングして、ステップＳ３に進み、PD_FS５４に供給すべきIRPをキューイングする。即ち、FSフィルタドライバ５３は、図示せぬキューに、NT入出力マネージャ５２からのIRPを供給して記憶させる。
さらに、FSフィルタドライバ５３は、キューに記憶されたIRPを読み出し、NT入出力マネージャ５２を介して、PD_FS５４に供給して、ステップＳ４に進む。
なお、FSフィルタドライバ５３内の処理は、フィルタの性質によって違うため、ここではその一例を示しており、これに限定されるものではない。
ステップＳ４では、PD_FS５４は、FSフィルタドライバ５３からのIRPによって要求されているデータについて、NTキャッシュマネージャ５９のキャッシュ機能を利用するのに必要な処理としてのキャッシュ処理を行い、ステップＳ５に進み、例えば、FSフィルタドライバ５３からのIRPによって要求されているデータが、NTキャッシュマネージャ５９にキャッシュされているかどうかを判定する。
ステップＳ５において、FSフィルタドライバ５３からのIRPによって要求されているデータが、NTキャッシュマネージャ５９にキャッシュされていると判定された場合、ステップＳ６に進み、PD_FS５４は、FSフィルタドライバ５３からのIRPによって要求されているデータを、NTキャッシュマネージャ５９から受信する等し、そのIRPに対する応答を、FSフィルタドライバ５３およびWin３２サブシステムを介して、そのIRPに対応するAPI関数を呼び出したアプリケーションアプリケーション３１に返す。
一方、ステップＳ５において、FSフィルタドライバ５３からのIRPによって要求されているデータが、NTキャッシュマネージャ５９にキャッシュされていないと判定された場合、ステップＳ７に進み、PD_FS５４は、FSフィルタドライバ５３からのIRPを、後述するようにコマンド変換し、NT入出力マネージャ５２を介して、PDストレージ５５に供給して、ステップＳ８に進む。
ステップＳ８では、PDストレージ５５は、PD_FS５４からのIRPを、対応するSCSIコードに変換し、SBP2ドライバ５６に供給して、ステップＳ９に進む。ステップＳ９では、SBP2ドライバ５６は、PDストレージ５５からのSCSIコードを、SBP2データに変換し、1394バスドライバ５７に供給して、ステップＳ１０に進む。
ステップＳ１０では、1394バスドライバ５７は、IEEE1394I/F２２（図２）を制御することにより、SBP2ドライバ５６からのSBP2データを、ドライブ２に送信する。
そして、1394バスドライバ５７は、ドライブ２から、ステップＳ１０で送信したSBP2データに対する応答が送信されてくるのを待って、ステップＳ１１において、その応答を受信し、SBP2ドライバ５６、PDストレージ５５、PD_FS５４、FSフィルタドライバ５３、およびWin32サブシステム５１を介して、ステップＳ１で受信されたIRPを送信してきたアプリケーション３１に返す。
次に、図６を参照して、ドライブ２が内部に有する専用のファイルシステムと、ドライブ２で採用されているプロトコルについて説明する。
ドライブ２は、前述したように、高ビットレートのAVデータのリアルタイムでの記録又は再生が可能なPDドライブであり、専用のファイルシステムとして、実ファイルシステム６１と仮想ファイルシステム６２を有する。なお、ドライブ２は、記録のみ、または再生のみ行うドライブであっても良いが、ここでは、記録と再生の両方が可能なドライブであるとする。
実ファイルシステム６１は、光ディスク３上の実ファイル（実際のファイル）を、例えばUDFにしたがって管理し、光ディスク３に対する、論理ブロック単位でのデータの読み書きを制御する。また、実ファイルシステム６１は、前述したPDファイルアロケーションマネージャ（図示せず）を有しており、PDファイルアロケーションマネージャは、一筆書き記録の制御や、光ディスク３上のファイルのアロケーション管理、ディフェクト処理、空き領域管理などを行う。
仮想ファイルシステム６２は、実ファイルシステム６１の実ファイルをフィルタリングする等の処理を行い、その結果得られる、後述するようなファイル（仮想ファイル）を、ドライブ２の外部に提供する。従って、ドライブ２の外部には、仮想ファイルシステム６２が提供される。このため、ドライブ２は、実ファイルシステム６１で管理される実ファイルを、仮想ファイルシステム６２で管理される仮想ファイルとして外部に提供することができるプロトコルによる通信機能を有している。
ここで、ドライブ２においては、AVデータや、テキストデータ、その他の任意のデータを、仮想ファイルシステム６２を介して読み書きすることができる。
ドライブ２では、仮想ファイルシステム６２（で管理される仮想ファイル）を外部に提供することができるプロトコルとして、例えば、IEEE1394通信（IEEE1394の規格に準拠した通信）において周辺装置を制御することができるプロトコルであるSBP2(IEEE1394 SBP2 Protocol)をコマンド拡張したプロトコルが採用されている。
いま、このSBP2をコマンド拡張したプロトコルを、PD-SBP2というものとすると、PD-SBP2は、PC１上のアプリケーションのレイヤのアプリケーション３１などがファイルにアクセスするときにOS３０のWin32サブシステム５１（図４）が提供するインタフェース(API)と同様の機能を提供する。従って、PD-SBP2によれば、例えば、ファイル名を指定して、そのファイル名のファイルに対して、ファイルストリームの読み書き(Read/Write)を行うことができ、また、ファイルのメタ情報を、そのファイルのファイル名およびパス名を元に取得することができる。
PD-SBP2は、上述したように、IEEE1394通信で用いられるSBP2(IEEE1394 SBP2 Protocol)をコマンド拡張したプロトコルであるため、そのようなプロトコルを採用するドライブ２は、PC１側においてIEEE1394通信を制御する1394バスドライバ５７に接続され、さらに、1394バスドライバ５７は、SBP2を実装するSBP2ドライバ５６に接続される。
なお、OS３０がWindows(R)のNT系のOSである場合には、SBP2ドライバ５６と1394バスドライバ５７としては、いずれも、そのOSに付属のものを使用することができる。
次に、図７を参照して、図６の仮想ファイルシステム６２の処理について説明する。
図７の右側は、実ファイルシステム６１により管理されている実ファイルを示しており、図７の左側は、仮想ファイルシステム６２からドライブ２の外部に提供される仮想ファイルを示している。
まず、図７の右側の実ファイルシステム６２の実ファイルについて説明する。
なお、以下において、「ディレクトリ」の後に続く英字等は、そのディレクトリのディレクトリ名を表す。同様に、「ファイル」の後に続く英字等は、そのファイルのファイル名を表す。また、ファイル名のうちの、ピリオド(.)に続く英字等は、ファイルの拡張子である。例えば、拡張子"XML"は、XML(eXtensible Markup Language)のファイルであることを表す。また、例えば、拡張子"MXF"は、MXFのファイルであることを表す。
ルートディレクトリROOTには、ビデオデータやオーディオデータ等の素材データに関する情報や、素材データの編集結果を示すエディットリスト等が格納されるディレクトリ、その他のAVデータに関連するファイル（ディレクトリ）が配置されるディレクトリPROAVと、AVデータに関連するファイル以外の任意のデータのファイルである、例えば、ファイルDocument.txtや、Infomation.doc，EditData.xlsが格納されるゼネラルディレクトリGeneralとが設けられている。
なお、ここでは、AVデータに関連するファイルとして、例えば、MXFのファイル(MXF File)を採用することとする。また、実ファイルシステム６１により管理されている実ファイルとしてのMXFのファイルは、例えば、ビデオデータとオーディオデータとが別のファイルとされるMXF OP-Atomのファイルであるとし、仮想ファイルシステム６２により管理され、外部に提供される仮想ファイルは、例えば、ビデオデータとオーディオデータとがインタリーブされて１つのファイルとされるMXF OP-1aのファイルであるとする。
ディレクトリPROAVには、インデックスファイルINDEX.XMLおよびINDEX.BUP、ディスクインフォメーションファイルDISCINFO.XMLおよびDISKINFO.BUP、並びにディスクメタファイルDISCMETA.XMLが設けられている。
インデックスファイルINDEX.XMLおよびINDEX.BUPは、光ディスク３に記録されている全てのクリップおよびエディットリストを管理するための管理情報等を含む。
なお、クリップは、例えば、１回の記録で光ディスク３に記録されたビデオデータ等のまとまったビデオデータと、そのビデオデータに対応するオーディオデータとのセットである。また、エディットリストは、いわゆるノンリニア編集が行われたときの編集手順のリストで、例えば、ノンリニア編集において、あるファイルのAVデータがカット編集された場合には、そのファイルを特定する情報としてのファイル名や、イン点およびアウト点などの情報が、エディットリストに記録される。
ディスクインフォメーションファイルDISCINFO.XMLおよびDISKINFO.BUPは、光ディスク３に記録されているデータ全体に対するメタデータであり、例えば、ディスク属性や、再生開始位置等の情報を含むファイルである。
なお、ディスクインフォメーションファイルDISKINFO.BUPは、ディスクインフォメーションファイルDISCINFO.XMLのバックアップファイル（コピー）である。同様に、上述のインデックスファイルINDEX.BUPも、インデックスファイルINDEX.XMLのバックアップファイルである。
ディスクメタファイルDISCMETA.XMLは、光ディスク３に記録されている全ての素材データに対するタイトルやコメント、さらに、光ディスク３に記録されている全てのビデオデータの代表となるフレームである代表画に対応するビデオデータのパス等の情報を含むファイルである。
また、ディレクトリPROAVには、上述したファイル以外に、クリップのデータが下位のディレクトリに設けられるクリップルートディレクトリCLPR、エディットリストのデータが下位のディレクトリに設けられるエディットリストルートディレクトリEDTRが設けられている。
クリップルートディレクトリCLPRには、光ディスク３に記録されているクリップのデータが、クリップ毎に異なるディレクトリに分けて管理されており、例えば、図７の右側では、３つのクリップのデータが、クリップディレクトリC0001，C0002，C0003の３つのディレクトリに分けられて管理されている。
すなわち、光ディスク３に記録された最初のクリップ＃１の各データは、クリップディレクトリC0001のファイルとして管理され、２番目に光ディスク３に記録されたクリップ＃２の各データは、クリップディレクトリC0002のファイルとして管理され、３番目に光ディスク３に記録されたクリップ＃３の各データは、クリップディレクトリC0003のファイルとして管理されている。
クリップディレクトリC0001には、最初に光ディスク３に記録されたクリップ＃１の各データのファイルが配置されている。
図７の右側では、クリップディレクトリC0001には、クリップ＃１を管理するファイルであるクリップインフォメーションファイルC0001C01.SMI、クリップ＃１のビデオデータを含むファイルであるビデオデータファイルC0001V01.MXF、クリップ＃１の８チャンネルのオーディオデータそれぞれのファイルである８つのオーディオデータファイルC0001A01.MXF乃至C0001A08.MXF、クリップ＃１の低ビットレートのビデオデータを含むファイルであるローレゾデータファイルC0001S01.MXF、クリップ＃１の素材データに対応する、例えば、LTC(Longitudinal Time Code)とフレーム番号を対応させる変換テーブル等の、リアルタイム性を要求されないメタデータであるクリップメタデータを含むファイルであるクリップメタデータファイルC0001M01.XML、およびクリップ＃１の素材データに対応する、例えばLTC等の、リアルタイム性を要求されるメタデータであるフレームメタデータを含むファイルであるフレームメタデータファイルC0001R01.BIMが配置されている。
なお、図７の右側の他のクリップディレクトリC0002とC0003にも、クリップ＃２と＃３について、それぞれ、クリップディレクトリC0001と同様のファイルが配置されている。
ディレクトリPROAVの下のエディットリストルートディレクトリEDTRには、光ディスク３に記録されているエディットリストが、その編集処理毎に異なるディレクトリに分けて管理されており、図７の右側では、４つのエディットリストが、エディットリストディレクトリE0001，E0002，E0003、およびE0004の４つのディレクトリに分けて管理されている。すなわち、光ディスク３に記録されたクリップの１回目の編集結果を示すエディットリスト＃１は、エディットリストディレクトリE0001のファイルとして管理され、２回目の編集結果を示すエディットリスト＃２は、エディットリストディレクトリE0002のファイルとして管理され、３回目の編集結果を示すエディットリスト＃３は、エディットリストディレクトリE0003のファイルとして管理され、４回目の編集結果を示すエディットリスト＃４は、エディットリストディレクトリE0004のディレクトリのファイルとして管理されている。
図７の右側では、エディットリストディレクトリE0001には、エディットリスト＃１のファイルであるエディットリストファイルE0001E01.SMIと、エディットリスト＃１にしたがった編集の編集後の素材データ（編集に用いられた全クリップの素材データの内、編集後のデータとして抽出された部分）に対応するクリップメタデータ、または、そのクリップメタデータに基づいて新たに生成されたクリップメタデータを含むファイルであるエディットリスト用クリップメタデータファイルE0001M01.XMLとが配置されている。
ここで、エディットリスト用クリップメタデータファイルE0001M01.XMLは、編集に使用されたクリップのクリップメタデータ（クリップルートディレクトリCLPRの下位のディレクトリに存在するクリップメタデータファイル（図７の右側では、例えば、ディレクトリC0001のクリップメタデータファイルC0001M01.XML））に基づいて生成された新たなクリップメタデータを含むファイルである。例えば、クリップ＃１を対象とした編集が行われると、クリップメタデータファイルC0001M01.XMLに含まれるクリップメタデータから、編集後の素材データに対応する部分が抽出され、それらを用いて、編集後の素材データを１クリップとする新たなクリップメタデータが再構成され、エディットリスト用クリップメタデータファイルとして管理される。すなわち、編集後の素材データには、編集後の素材データを１クリップとする新たなクリップメタデータが付加され、そのクリップメタデータが１つのエディットリスト用クリップメタデータファイルとして管理される。従って、エディットリスト用クリップメタデータファイルは、編集毎に生成される。
なお、図７の右側の他のエディットリストディレクトリE0002乃至E0004にも、エディットリスト＃２乃至＃４について、それぞれ、エディットリストディレクトリE0001と同様のファイルが配置されている。
以上のような図７の右側に示した、実ファイルシステム６１により管理されている実ファイルは、仮想ファイルシステム６２において、図７の左側に示す形で、ドライブ２の外部に提供される。
即ち、仮想ファイルシステム６２では、ルートディレクトリROOTには、インデックスファイルINDEX.XMLとディスクメタファイルDISCMETA.XMLが配置されるとともに、ディレクトリClip，Edit，Sub、およびGeneralが設けられる。
仮想ファイルシステム６２において、ルートディレクトリROOTに配置されるインデックスファイルINDEX.XMLとディスクメタファイルDISCMETA.XMLは、それぞれ、実ファイルシステム６１で管理されているディレクトリPROAVのインデックスファイルINDEX.XMLとディスクメタファイルDISCMETA.XMLである。
また、仮想ファイルシステム６２では、ディレクトリClipに、実ファイルシステム６１で管理されているディレクトリCLPRの下位ディレクトリにあるクリップのデータのファイルが配置される。
即ち、図７の左側では、ディレクトリClipに、図７の右側のディレクトリC0001，C0002，C0003にあるクリップのデータのファイルとして、それぞれ、ファイルC0001.MXF，C0002.MXF，C0003.MXFが設けられている。
ここで、実ファイルシステム６１では、クリップのデータは、上述したように、ビデオデータとオーディオデータとが別のファイルであるMXF OP-Atomのファイルとされる。
即ち、図７の右側のディレクトリC0001では（ディレクトリC0002，C0003についても同様）、クリップ＃１のデータが、そのクリップ＃１のビデオデータを含むビデオデータファイルC0001V01.MXFと、クリップ＃１の８チャンネルのオーディオデータそれぞれのオーディオデータファイルC0001A01.MXF乃至C0001A08.MXFに分けられている。
一方、仮想ファイルシステム６２では、クリップのデータは、上述したように、ビデオデータとオーディオデータとがインタリーブされて１つのファイルとなっているMXF OP-1aのファイルとされる。
図７の左側のディレクトリClipにあるファイルC0001.MXFは、図７の右側のディレクトリC0001にあるクリップ＃１のビデオデータとオーディオデータとがインタリーブされた１つのファイルである。
即ち、ファイルC0001.MXFは、ディレクトリC0001のビデオデータファイルC0001V01.MXFのビデオデータと、オーディオデータファイルC0001A01.MXF乃至C0001A08.MXFそれぞれの８チャンネルのオーディオデータとをインタリーブして配置したファイルである。
同様に、ディレクトリClipにあるファイルC0002.MXFは、ディレクトリC0002にあるクリップ＃２のビデオデータとオーディオデータとがインタリーブされた１つのファイルであり、ファイルC0003.MXFは、ディレクトリC0003にあるクリップ＃３のビデオデータとオーディオデータとがインタリーブされた１つのファイルである。
図７の左側のディレクトリClipには、さらに、各クリップのクリップメタデータファイルも配置される。
ここで、図７の左側のディレクトリClipには、クリップメタデータファイルC0001M01.XML，C0002M01.XML，C0003M01.XMLが配置されている。ディレクトリClipのクリップメタデータファイルC0001M01.XMLは、クリップ＃１のクリップメタデータファイルで、図７の右側のディレクトリC0001にあるクリップメタデータファイルC0001M01.XMLである。
同様に、ディレクトリClipのクリップメタデータファイルC0002M01.XMLは、クリップ＃２のクリップメタデータファイルで、図７の右側のディレクトリC0002にあるクリップメタデータファイルである。さらに、同様に、ディレクトリClipのクリップメタデータファイルC0003M01.XMLは、クリップ＃３のクリップメタデータファイルで、図７の右側のディレクトリC0003にあるクリップメタデータファイルである。
図７の左側のルートディレクトリROOTの中のディレクトリEditには、図７の右側のディレクトリEDTRの下位ディレクトリにあるファイルが配置される。
ここで、ディレクトリEditには、ファイルE0001E01.SMIとE0001M01.XML、ファイルE0002E01.SMIとE0002M01.XML、ファイルE0003E01.SMIとE0003M01.XML、およびファイルE0004E01.SMIとE0004M01.XMLが配置されている。
図７の左側のディレクトリEditの中のファイルE0001E01.SMIとE0001M01.XMLは、それぞれ、図７の右側のエディットリスト＃１のディレクトリE0001の中のファイルE0001E01.SMIとE0001M01.XMLである。
同様に、ディレクトリEditの中のファイルE0002E01.SMIとE0002M01.XMLは、エディットリスト＃２のディレクトリE0002の中のファイルであり、ディレクトリEditの中のファイルE0003E01.SMIとE0003M01.XMLは、エディットリスト＃３のディレクトリE0003の中のファイルであり、ディレクトリEditの中のファイルE0004E01.SMIとE0004M01.XMLは、エディットリスト＃４のディレクトリE0004の中のファイルである。
図７の左側のディレクトリSubには、各クリップのローレゾデータファイルが配置される。
ここで、図７の左側のディレクトリSubには、ローレゾデータファイルC0001S01.MXF，C0002S01.MXF，C0003S01.MXFが配置されている。ディレクトリSubのローレゾデータファイルC0001S01.MXFは、クリップ＃１のローレゾデータファイルで、図７の右側のディレクトリC0001にあるローレゾデータファイルC0001S01.MXFである。
同様に、ディレクトリSubのローレゾデータファイルC0002S01.MXFは、クリップ＃２のローレゾデータファイルで、図７の右側のディレクトリC0002にあるローレゾデータファイルである。さらに、同様に、ディレクトリSubのローレゾデータファイルC0003S01.MXFは、クリップ＃３のローレゾデータファイルで、図７の右側のディレクトリC0003にあるローレゾデータファイルである。
図７の左側のディレクトリGeneralには、図７の右側のディレクトリGeneralSubにあるファイルDocument.txt，Infomation.doc，EditData.xlsが配置される。
仮想ファイルシステム６２（図６）は、実ファイルシステム６１で管理されている別ファイルのクリップのビデオデータとオーディオデータを、１つのファイル（仮想ファイル）として、外部に提供する。
さらに、仮想ファイルシステム６２は、実ファイルシステム６１で管理されているファイルのうちの、ドライブ２の内部だけで使用するファイルなどの、外部（アプリケーション、あるいはユーザなど）に提供する必要がないファイルをフィルタリングし、そのようなファイルを、外部に見せないようになっている。
ここで、図７では、仮想ファイルシステム６２のフィルタリングによって、バックアップのファイルINDEX.BUPおよびDISCINFO.BUPや、ディスクインフォメーションファイルDISCINFO.XML、クリップインフォメーションファイルC0001C01.SMI、フレームメタデータファイルC0001R01.BIMなどが、外部から見えないようになっている。
以上のように、仮想ファイルシステム６２によれば、実ファイルシステム６１で管理され、別ファイルとなっているビデオデータとオーディオデータのMXF OP-Atomのファイルが、ビデオデータとオーディオデータとがインタリーブされて１つのファイルとなっているMXF OP-1aのファイルとして、外部に提供されるので、ユーザやアプリケーション３１における取り扱いが容易になる。
即ち、実ファイルシステム６１で管理され、別ファイルとなっているビデオデータとオーディオデータのMXF OP-Atomのファイルが、外部に提供される場合、例えば、ユーザが、例えば、クリップ＃１を再生対象として指定して、アプリケーション３１に再生させるためには、ユーザは、例えば、クリップ＃１のビデオデータのファイルC0001V01.MXFと、クリップ＃１のオーディオデータの８チャンネル分のファイルC0001A01.MXF乃至C0001A08.MXFを指定しなければならない。さらに、アプリケーション３１は、ユーザによって指定されたファイルC0001V01.MXFとファイルC0001A01.MXF乃至C0001A08.MXFの合計で９のファイルをオープンし、そのファイルハンドルを取得して、ビデオデータやオーディオデータの読み出しを行わなければならない。
これに対して、仮想ファイルシステム６２によれば、クリップ＃１のファイルC0001V01.MXFのビデオデータと、クリップ＃１のファイルC0001A01.MXF乃至C0001A08.MXFの８チャンネル分のオーディオデータとが、１つのファイルC0001.MXFとして提供されるので、ユーザは、再生対象として、１つのファイルC0001.MXFを指定すれば済み、さらに、アプリケーションは、そのファイルC0001.MXFのファイルハンドルを取得して、データの読み出しを行うだけで済む。
また、仮想ファイルシステム６２によれば、実ファイルシステム６１で管理されているファイルを対象として、フィルタリングが行われるので、例えば、ディスクインフォメーションファイルDISCINFO.XMLなどの、ドライブ２の内部だけで使用するファイルなどが、外部から、いわば隠蔽される。
従って、ドライブ２の内部だけで使用するファイルなどが、ユーザの誤操作等によって削除され、または書き換えられることを防止することができる。さらに、ユーザに必要のないファイルが見えることにより、ユーザが必要なファイルを探すときの妨げとなることを防止することができる。
次に、ドライブ２では、図６で説明したように、IEEE1394通信で用いられるSBP2(IEEE1394 SBP2 Protocol)をコマンド拡張したプロトコルであるPD-SBP2を、仮想ファイルシステム６２を外部に提供するためのプロトコルとして採用する。
ここで、SBP2では、イニシエータ(Initiator)と呼ばれる装置が、ターゲット(Target)と呼ばれる装置に対して、コマンドを送信し、ターゲットが、イニシエータからのコマンドに対して、レスポンスを返す。
図８は、イニシエータからターゲットに対してコマンドを送信するときのSBP2データであるSCSI command block ORB(Operation Request Blocks)のフォーマットを示している。なお、SBP2において、SCSI command block ORBは、データ転送やデバイス制御に使用される。
図８において、next_ORBフィールドには、次のORBのアドレス(address)、またはNULLがセットされる。
data_descriptorフィールドは、data_sizeフィールドが0以外のとき有効で、データバッファ(data buffer)のアドレス、またはページテーブル(page table)のアドレスがセットされる
n(notify bit)フィールドには、ターゲットによる完了の通知が必要か否かの情報がセットされる。
rq_fmtフィールドには、ORBフォーマット(format)の情報がセットされる。
r(reserved)フィールドは、いわゆる予約領域である。
d(direction bit)フィールドには、データ(Data)転送の方向がセットされる。即ち、dフィールドが0である場合は、ターゲットからのデータの読み出し(target read transactions)を表し、dフィールドが1である場合は、ターゲットへのデータの書き込み(target write transactions)を表す。
spd(speed)フィールドには、ターゲットのデータ転送処理スピード(Speed)がセットされる。
max_payloadフィールドには、最大データ転送量(length)がセットされる。なお、最大データ転送量は、2の(max_payload + 2)乗となる。
p(page_table_present bit)フィールドには、0または1がセットされる。即ち、data_descriptorフィールドにおいて、データバッファのアドレスがセットされている場合には、pフィールドに0がセットされる。また、data_descriptorフィールドにおいて、ページテーブルのアドレスがセットされている場合には、pフィールドに1がセットされる。
page_sizeフィールドには、pフィールドが1である場合に、データバッファとしてのメモリ(memory)のページサイズ(page size)がセットされる。なお、ページサイズは、2の(page_size + 8)乗となる。
data_sizeフィールドには、pフィールドが0である場合に、データバッファのサイズ(size)がセットされる。
cdb(SCSI command descriptor blocks)フィールド、即ち、１２のcdb[0]乃至cdb[11]フィールドには、SCSIコマンド（コード）(SCSI command)がセットされる。
SBP2では、CDB[0]フィールドにセットすることができる値のうちの、C0h乃至FFh（hは、その前の英数字が１６進数であることを表す）が、ベンダスペシフィック(Vender Specific)エリアとされている。
そこで、PD-SBP2では、ベンダスペシフィックエリアの値を用いて、コマンド拡張（新たなコマンドの定義）がされている。
即ち、PD-SBP2では、CDB[0]フィールドに、拡張コマンド（のオペコード）がセットされる。また、PD-SBP2では、CDB[1]乃至CDB[11]フィールドに、コマンド（拡張コマンド）の引数（オペランド）が、必要に応じてセットされる。
次に、図９は、ターゲットが、イニシエータからのコマンドに対して返すレスポンスとしてのSBP2データであるSBP2ステータスブロック(SBP2 status block)のフォーマットを示している。なお、SBP2において、SBP2ステータスブロックは、SCSI sense dataのためのステータスブロックで、ターゲットが要求の完了や、ステータス(status)の変化を返すときに使用される。
図９において、srcフィールドには、SBP2ステータスブロックのoriginを示すフラグ(flag)がセットされる。
resp(respose status)フィールドには、応答状態を示す情報がセットされる。
d(dead bit)には、フェッチエージェント(fetch agent)がエラー(error)によりdead stateに変わったことを示すフラグがセットされる。
lenフィールドには、SBP2ステータスブロックのサイズがセットされる。SBP2ステータスブロックのサイズは、lenフィールドにセットされた値に、1quadlets（３２ビット）を加算した値である。
sbp_statusフィールドには、respに伴う追加的情報がセットされる。
ORB_offset_hiフィールドとORB_offset_loフィールドには、SBP2ステータスブロックの元となるORBの情報がセットされる。
r(reserved)フィールドは、予約領域である。
sfmtフィールドには、SBP2ステータスブロックのフォーマットの情報がセットされる。
statusフィールドには、SCSIステータス(SCSI status)がセットされる。
v(valid bit)には、後述するinfomationフィールドの内容(content)の有効または無効を表すフラグがセットされる。
mフィールドには、SCSIマークビット(SCSI mark bit)がセットされ、eフィールドには、SCSI eom bitがセットされる。iフィールドには、SCSI illegal_length_indicator bitがセットされ、sense_keyフィールドには、SCSI sense keyがセットされる。sense_codeフィールドには、SCSI additional sense codeがセットされ、sense_qualifierフィールドには、SCSI additional sense code qualifierがセットされる。
infomationフィールド、CDB-dependentフィールド、fruフィールド、sense_key_dependentフィールド、およびvender-dependentフィールドには、いずれもデバイスタイプ(device type)やコマンド(command)などに依存した情報がセットされる。
PD-SBP2では、informationフィールドに、拡張コマンドに対する返り値がセットされる。
次に、図１０は、PD-SBP2のコマンド（拡張コマンド）の一覧を示している。
図１０において、コマンドFILE OPENは、ファイル名とファイルオープンモード(File Open Mode)を引数とし、引数のファイル名によって特定されるファイルを、引数のフィルオープンモードでオープン(Open)する。コマンドFILE OPENに対しては、オープンされたファイルのファイルハンドル(File Handle)が返される。
コマンドFILE CLOSEは、ファイルハンドルを引数とし、そのファイルハンドルで特定されるファイルをクローズ(Close)する。
コマンドFILE READは、ファイルハンドルとリードサイズ(Size)を引数とし、引数のファイルハンドルによって特定されるファイルのデータ(File Stream data)を、引数のリードサイズ分だけ読み出す（Readする）。
コマンドFILE WRITEは、ファイルハンドルとライトサイズ(Size)を引数とし、引数のファイルハンドルによって特定されるファイルに対して、データ(File Stream data)を、引数のライトサイズ分だけ書き込む（Writeする）。
コマンドFILE LOGICAL SEEKは、ファイルハンドルと、論理的な位置を引数とし、引数のファイルハンドルによって特定されるファイルのファイルポインタ(Current File Pointer)を、引数の論理的な位置に変更する。
コマンドSET EOFは、ファイルハンドルを引数とし、引数のファイルハンドルによって特定されるファイルのファイルポインタが表す位置に、EOF(End Of File)を変更する。
コマンドDELETEは、ファイル名を引数とし、そのファイル名のファイルを削除(Delete)する。
コマンドRENAMEは、変更前のファイル名（またはディレクトリ名）と、変更後のファイル名（またはディレクトリ名）を引数とし、変更前のファイル名を、変更後のファイル名に変更する。
コマンドMAKE DIRECTORYは、ディレクトリ名を引数とし、そのディレクトリ名のディレクトリを生成（作成）する。
コマンドREMOVE DIRECTORYは、ディレクトリ名を引数とし、そのディレクトリ名のディレクトリを削除する。
コマンドLIST OPENは、ファイル名（またはディレクトリ名）を引数とし、そのファイル名のファイルリスト(File List)とファイルメタ(File Meta)情報を得るためのハンドル(Handle)を返す。
コマンドLIST READは、コマンドLIST OPENが返すハンドルを引数とし、そのハンドルによって特定されるファイルリストとファイルメタ情報を読み出す。
コマンドFORMATは、ドライブ２に装着されている光ディスク３をフォーマット(Format)する。
コマンドEJECTは、ドライブ２に装着されている光ディスク３をイジェクト(Eject)する。
コマンドDISC INFOは、ドライブ２に装着されている光ディスク３に関する情報、即ち、例えば、光ディスク３の空き容量などを返す。
コマンドSYSTEMは、ドライブ２に関する情報（Sytem情報）を返す。
コマンドSETUPは、ドライブ２によるPD-SBP2のコマンドの受信を可能にする。即ち、ドライブ２は、コマンドSETUPを受信することにより、図１０の他のコマンドの受け付けが可能となる。
次に、図１１を参照して、PD-SBP2によるファイルの読み出しシーケンス(PD-SBP2 Protocol File Read Sequence)を説明する。
PC１のアプリケーション３１（図４）において、ドライブ２の光ディスク３からデータを読み出す場合、PC１のSBP2ドライバ５６がイニシエータとなり、ドライブ２がターゲットとなる。
そして、イニシエータであるPC１（のSBP2ドライバ５６）は、ステップＳ２１において、コマンドFILE OPENを、ターゲットであるドライブ２に送信し、ドライブ２は、ステップＳ４１において、そのコマンドFILE OPENを受信して、ステップＳ４２に進む。
ステップＳ４２では、ドライブ２は、PC１からのコマンドFILE OPENによって指定されたファイルをオープンし、そのファイルハンドルを、PC１に返す。ここで、コマンドFILE OPENによって指定されたファイルは、ドライブ２が仮想ファイルシステム６２を介して外部に提供するファイルであり、ドライブ２が返すファイルハンドルも、ドライブ２が仮想ファイルシステム６２を介して外部に提供するファイルのファイルハンドルである。
PC１は、ステップＳ２２において、ドライブ２からのファイルハンドルを受信して、ステップＳ２３に進み、そのファイルハンドルによって特定されるファイルのファイルポインタを、読み出そうとするデータの先頭位置に移動することを要求するコマンドFILE LOGICAL SEEKを、ドライブ２に送信する。
ドライブ２は、ステップＳ４３において、PC１からのコマンドFILE LOGICAL SEEKを受信する。さらに、ドライブ２は、ステップＳ４２でオープンしたファイルのファイルポインタを、PC１からのコマンドFILE LOGICAL SEEKによって指定されている位置に移動する。
そして、ドライブ２は、ステップＳ４３からＳ４４に進み、ファイルポインタの移動に成功した場合には、その旨を表すレスポンスGOODを、PC１に返し、ファイルポインタの移動に失敗した場合には、その旨を表すレスポンスERRORを、PC１に返す。
PC１は、ステップＳ２４において、ドライブ２からのレスポンスを受信する。そして、PC１は、ドライブ２からのレスポンスが、ファイルポインタの移動に失敗した旨を表すERRORである場合には、例えば、処理を終了する。
また、PC１は、ドライブ２からのレスポンスが、ファイルポインタの移動に成功した旨を表すGOODである場合には、ステップＳ２４からＳ２５に進み、データの読み出しを要求するコマンドFILE READを、ドライブ２に送信する。
ドライブ２は、ステップＳ４５において、PC１からのコマンドFILE READを受信し、ステップＳ４３で移動したファイルポインタの位置からデータを読み出す。
そして、ステップＳ４６1乃至Ｓ４６Nに順次進み、ドライブ２は、ステップＳ４５で読み出したデータを、PC１に送信する。
即ち、ドライブ２からPC１に対して、１度に送信することのできるデータの最大サイズは制限されており、PC１からのコマンドFILE READによって読み出しが要求されたデータのサイズが、ドライブ２が１度に送信することのできるデータの最大サイズより大の場合には、ドライブ２は、PC１からのコマンドFILE READによって読み出しが要求されたデータを、例えば、１度に送信することのできるデータの最大サイズに分けて送信する。図１１の実施の形態では、ドライブ２からPC１に対して、ステップＳ４６1乃至Ｓ４６NのＮ回に分けて、データが送信されている。
PC１は、ステップＳ２６1乃至Ｓ２６Nにおいて、ドライブ２がステップＳ４６1乃至Ｓ４６Nで送信してくるデータをそれぞれ受信し、これにより、コマンドFILE READによって要求したデータすべての受信が完了すると、ステップＳ２７に進み、ステップＳ２１で送信したコマンドFILE OPENによってオープンを要求したファイルのクローズを要求するコマンドFILE CLOSEを、ドライブ２に送信する。
ドライブ２は、ステップＳ４７において、PC１からのコマンドFILE CLOSEを受信し、そのコマンドFILE CLOSEによって指定されたファイルをクローズする。
さらに、ドライブ２は、ステップＳ４７からＳ４８に進み、ファイルのクローズに成功した場合には、その旨を表すレスポンスGOODを、PC１に返し、ファイルのクローズに失敗した場合には、その旨を表すレスポンスERRORを、PC１に返す。
次に、図１２を参照して、PD-SBP2によるファイルの書き込みシーケンス(PD-SBP2 Protocol File Write Sequence)を説明する。
PC１のアプリケーション３１（図４）において、ドライブ２の光ディスク３にデータを書き込む場合、PC１のSBP2ドライバ５６がイニシエータとなり、ドライブ２がターゲットとなる。
そして、イニシエータであるPC１（のSBP2ドライバ５６）は、ステップＳ６１において、コマンドFILE OPENを、ターゲットであるドライブ２に送信し、ドライブ２は、ステップＳ８１において、そのコマンドFILE OPENを受信して、ステップＳ８２に進む。
ステップＳ８２では、ドライブ２は、PC１からのコマンドFILE OPENによって指定されたファイルをオープンし、そのファイルハンドルを、PC１に返す。
PC１は、ステップＳ６２において、ドライブ２からのファイルハンドルを受信して、ステップＳ６３に進み、そのファイルハンドルによって特定されるファイルのファイルポインタを、データを書き込む先頭位置に移動することを要求するコマンドFILE LOGICAL SEEKを、ドライブ２に送信する。
ドライブ２は、ステップＳ８３において、PC１からのコマンドFILE LOGICAL SEEKを受信する。さらに、ドライブ２は、ステップＳ８２でオープンしたファイルのファイルポインタを、PC１からのコマンドFILE LOGICAL SEEKによって指定されている位置に移動する。
そして、ドライブ２は、ステップＳ８３からＳ８４に進み、ファイルポインタの移動に成功した場合には、その旨を表すレスポンスGOODを、PC１に返し、ファイルポインタの移動に失敗した場合には、その旨を表すレスポンスERRORを、PC１に返す。
PC１は、ステップＳ６４において、ドライブ２からのレスポンスを受信する。そして、PC１は、ドライブ２からのレスポンスが、ファイルポインタの移動に失敗した旨を表すERRORである場合には、例えば、処理を終了する。
また、PC１は、ドライブ２からのレスポンスが、ファイルポインタの移動に成功した旨を表すGOODである場合には、ステップＳ６４からＳ６５に進み、データの書き込みを要求するコマンドFILE WRITEを、ドライブ２に送信する。
さらに、PC１は、ステップＳ６６1乃至Ｓ６６Nに順次進み、書き込み対象のデータを、ドライブ２に送信する。
即ち、PC１からドライブ２に対して、１度に送信することのできるデータの最大サイズは制限されており、PC１が書き込もうとしているデータ（書き込み対象のデータ）のサイズが、PC１が１度に送信することのできるデータの最大サイズより大の場合には、PC１は、書き込み対象のデータを、例えば、１度に送信することのできるデータの最大サイズに分けて送信する。図１２の実施の形態では、PC１からドライブ２に対して、ステップＳ６６1乃至Ｓ６６NのＮ回に分けて、データが送信されている。
ドライブ２は、ステップＳ８５において、PC１からのコマンドFILE WRITEを受信して、ステップＳ８６1乃至Ｓ８６Nに順次進み、ステップＳ６６1乃至Ｓ６６NでPC１から送信されてくるデータを受信し、ステップＳ８３で移動したファイルポインタの位置から、順次、データを書き込む。
その後、PC１は、ステップＳ６７に進み、ステップＳ６１で送信したコマンドFILE OPENによってオープンを要求したファイルのクローズを要求するコマンドFILE CLOSEを、ドライブ２に送信する。
ドライブ２は、ステップＳ８７において、PC１からのコマンドFILE CLOSEを受信し、そのコマンドFILE CLOSEによって指定されたファイルをクローズする。
さらに、ドライブ２は、ステップＳ８７からＳ８８に進み、ファイルのクローズに成功した場合には、その旨を表すレスポンスGOODを、PC１に返し、ファイルのクローズに失敗した場合には、その旨を表すレスポンスERRORを、PC１に返す。
ところで、SBP2ドライバ５６（図４、図６）は、上述したように、PDストレージ５５からのSCSIコード(SCSIコマンド)を、図１０に示したPD-SBP2のコマンド（拡張コマンド）がcbd[0]フィールドに配置される図８のSCSI command block ORB（SBP2データ）に変換する。
また、PDストレージ５５は、上述したように、その上位のレイヤのデバイスドライバであるPD_FS５４から、NT入出力マネージャ５２を介して供給されるIRPを、SCSIコードに変換して、SBP2ドライバ５６に出力する。
従って、PD_FS５４が出力するIRPは、PDストレージ５５においてSCSIコードに変換され、SBP2ドライバ５６に出力される。さらに、SBP2ドライバ５６では、PDストレージ５５からのSCSIコードがSBP2データ（SCSI command block ORB）に変換される。
即ち、SBP2ドライバ５６は、PDストレージ５５が出力するSCSIコードを、図８のSCSI command block ORBのcbd[0]フィールドに配置したSBP2データに変換する。
PD-SBP2では、図８のSCSI command block ORBのcbd[0]フィールドに、図１０の拡張コマンドが配置される。従って、PDストレージ５５が出力するSCSIコードは、図１０の拡張コマンドのうちのいずれかであり、いわば特別なSCSIコードである。このため、PD_FS５４がNT入出力マネージャ５２を介して出力するIRPは、PDストレージ５５において特別なSCSIコードに変換される特別なIRPでなければならない。
一方、Win32サブシステム５１（図４）がアプリケーション３１に対して提供する、ファイル操作のためのAPI関数の呼び出しがあった場合に、Win32サブシステム５１が、NT入出力マネージャ５２、FSフィルタドライバ５３、およびNT入出力マネージャ５２を介して、PD_FS５４に供給するIRPは、あらかじめ決まっている。
即ち、Win32サブシステム５１は、例えば、ファイルをオープンするAPI関数CreateFile()、ファイルからデータを読み出すAPI関数ReadFile()、ファイルにデータ書き込むAPI関数WriteFile()などを、アプリケーション３１に提供する。
そして、アプリケーション３１が、例えば、API関数CreateFile()を呼び出した場合、NT入出力マネージャ５２からPD_FS５４には、API関数CreateFile()に対してあらかじめ決まっているIRP_MJ_CREATEのIRPが供給される。
同様に、アプリケーション３１が、例えば、API関数ReadFile()、またはWriteFile()を呼び出した場合、NT入出力マネージャ５２からPD_FS５４には、API関数ReadFile()に対してあらかじめ決まっているIRP_MJ_READ、またはAPI関数WriteFile()に対してあらかじめ決まっているIRP_MJ_WRITEのIRPが、それぞれ供給される。
この場合、PD_FS５４が、NT入出力マネージャ５２を介して供給されるIRPを、NT入出力マネージャ５２を介して、PDストレージ５５に供給してしまうと、NT入出力マネージャ５２を介して供給されるIRP、即ち、例えば、IRP_MJ_CREATEや、IRP_MJ_READ，IRP_MJ_WRITEなどのIRPは、あらかじめ決まっている、いわば標準のIRPであるから、PDストレージ５５では、そのIRPが、そのIRPに対応するSCSIコード、拡張コマンドではないSCSIコード（特別なSCSIコードでないSCSIコード）に変換されることになる。
そこで、PD_FS５４は、NT入出力マネージャ５２を介して供給されるIRPを変換し、これにより、NT入出力マネージャ５２を介してPDストレージ５５に対し、拡張コマンドであるSCSIコード（特別なSCSIコード）に変換される特別なIRPを供給する。
特別なIRPとしては、ユーザ定義のIOCTLが指定されるIRP_MJ_DEVICE_CONTROLのIRPが用いられる。
図１３は、PD_FS５４が、NT入出力マネージャ５２を介してPDストレージ５５に出力する特別なIRPとしてのIRP_MJ_DEVICE_CONTROLのIRPで指定されるユーザ定義のIOCTLを示している。
図１３のIOCTLは、図１０に示したPD-SBP2のコマンド（拡張コマンド）のうちのSETUPを除いたものと１対１の関係になっている。
即ち、図１３において、IOCTL_PD_FILE_OPEN, IOCTL_PD_FILE_CLOSE, IOCTL_PD_FILE_READ, IOCTL_PD_FILE_WRITE, IOCTL_PD_FILE_LOGICAL_SEEK, IOCTL_PD_SET_EOF, IOCTL_PD_DELETE, IOCTL_PD_RENAME, IOCTL_PD_MAKE_DIRECTORY, IOCTL_REMOVE_DIRECTORY, IOCTL_PD_LIST_OPEN, IOCTL_PD_LIST_READ, IOCTL_PD_FORMAT, IOCTL_PD_EJECT, IOCTL_PD_DISC_INFO, IOCTL_PD_SYSTEMは、図１０のコマンドFILE OPEN, FILE CLOSE, FILE READ, FILE WRITE, FILE LOGICAL SEEK, SET EOF, DELETE, RENAME, MAKE DIRECTORY, REMOVE DIRECTORY, LIST OPEN, LIST READ, FORMAT, EJECT, DISC INFO, SYSTEMに、それぞれ対応している。
PDストレージ５５は、PD_FS５２からNT入出力マネージャ５２を介して供給されるIRPが、図１３のIOCTLが指定されているIRP（IRP_MJ_DEVICE_CONTROLのIRP）である場合、そのIOCTLに対応する拡張コマンド（特別のSCSIコード）を、SBP2ドライバ５６に出力する。
そして、SBP2ドライバ５６は、PDストレージ５５からの、IOCTLに対応する拡張コマンドを、その拡張コマンドがcbd[0]フィールドに配置された図８のSCSI command block ORB（SBP2データ）に変換する。
次に、図１４のフローチャートを参照して、図６（図４）のPD_FS５４によるIRPの処理について、さらに説明する。なお、ここでは、説明を簡単にするため、NTキャッシュマネージャ５９（図４）が提供するキャッシュ機能の利用は、考えないものとする。
例えば、アプリケーション３１が、Win32サブシステム５１が提供するファイル操作に関するAPI関数を呼び出すことにより、そのAPI関数に対応するIRPが、図４のWin32サブシステム５１、NT入出力マネージャ５２、FSフィルタドライバ５３、およびNT入出力マネージャ５２を介して、PD_FS５４に送信されてくると、ステップＳ１０１において、PD_FS５４は、そのIRPを受信し、ステップＳ１０２に進む。
ステップＳ１０２では、PD_FS５４は、ステップＳ１０１で受信したIRPを、ドライブ２とのIEEE1394通信においてファイルシステムを扱うことが可能なPD-SBP2のコマンド（図１０の拡張コマンド）に変換される図１３のIOCTLを発行する関数IoCallDriver()に変換する。
ここで、関数IoCallDriver()は、ユーザモードで動作するWin32サブシステム５１が提供するAPI関数DeviceIoControl()と同様の機能の関数で、カーネルモードで使用される。
その後、PD_FS５４は、ステップＳ１０３において、ステップＳ１０２で得た関数IoCallDriver()を呼び出し、次のIRPが送信されてくるのを待って、ステップＳ１０１に戻り、以下、同様の処理を繰り返す。
以上のように、ステップＳ１０３において、PD_FS５４が、関数IoCallDriver()を呼び出すと、NT入出力マネージャ５２は、その関数IoCallDriver()によって発行されるIOCTLが指定されたIRP（IRP_MJ_DEVICE_CONTROLのIRP）を、PDストレージ５５に出力する。PDストレージ５５は、そのIRPで指定されているIOCTL（図１３）に対応する特別のSCSIコードとしての拡張コマンド（図１０）を、SBP2ドライバ５６に出力する。
SBP2ドライバ５６では、PDストレージ５５からの、IOCTLに対応する拡張コマンドが、その拡張コマンドをcbd[0]フィールドに配置した図８のSCSI command block ORB（SBP2データ）に変換され、1394バスドライバ５７を介して、ドライブ２に送信される。
以上のように、PD_FS５４では、アプリケーション３１がファイル操作に関するAPI関数を呼び出すことにより供給されるIRPが、ドライブ２とのIEEE1394通信においてファイルシステムを扱うことが可能なPD-SBP2のコマンド（図１０の拡張コマンド）に変換される図１３のIOCTLを発行する関数IoCallDriver()に変換されるので、ドライブ２の実ファイルシステム６１および仮想ファイルシステム６２をそのまま利用して、ドライブ２を、容易に扱うことができる。
即ち、例えば、OS３０や、アプリケーション３１において、一筆書き記録の制御を行わなくても、ドライブ２において、一筆書き記録の制御が行われるので、AVデータのリアルタイムでの記録や再生が可能となる。
さらに、アプリケーション３１からは、ドライブ２の仮想ファイルシステム６２がPC１にマウントされているように見えるので、その仮想ファイルシステム６２により管理されるファイルを、例えば、NTFSやFATなどの汎用のファイルシステムにより管理されるファイルと同様に扱うことができる。
ところで、PDドライブであるドライブ２は、高ビットレートのAVデータのリアルタイムでの読み書きを、その主目的としており、かかる目的の用途では、読み書きの対象とされるのは、一般に、１つのストリームだけである。
即ち、PDドライブにおいては、複数のストリームを同時に読み書きすることも可能であるが、一筆書き記録の性質上、複数のストリームを同時に（時分割で）読み書きする場合には、読み書き対象のストリームの変更時に、シークが生じ、そのシークによって、リアルタイム性が妨げられる。従って、リアルタイム性を確保するには、シークに要する時間だけ、AVデータ（ストリーム）のビットレートを抑える必要がある。
また、読み書き対象を１つのストリームだけとした場合に、ある高ビットレートでのAVデータのリアルタイムでの読み書きが可能であるとすると、読み書き対象を、複数であるＭ個のストリームとした場合、単純には、読み書き対象のストリームが１つだけの場合の１／Ｍ以下のビットレートのストリームでないと、リアルタイムで読み書きすることができず、従って、読み書きすることができるストリームが、低画質または低音質のAVデータとなる。
以上から、高ビットレートのAVデータのリアルタイムでの読み書きをするには、光ディスク２に対して読み書きするAVデータのストリームは、１つに制限するのが望ましい。そして、この制限は、例えば、ドライブ２において１つのファイルハンドルしか扱わないこととすることで実現することができる。
一方、コンピュータの汎用のOSでは、一般に、ファイルのオープンは、複数行うことができる。
従って、PC１にドライブ２を接続した場合には、アプリケーション３１からは、ドライブ２に装着された光ディスク３上のファイルのオープンを、複数行い、そのオープンされたファイルに対する操作を行うことができるのが望ましい。
そこで、PD_FS５４には、ドライブ２が１つのファイルハンドルだけを扱う場合であっても、アプリケーション３１が、見かけ上、ファイルのオープンを複数同時に行うことができるようにする機能（以下、適宜、複数同時オープン機能という）を持たせることができる。
図１５は、複数同時オープン機能を説明するための図である。
即ち、図１５は、アプリケーション３１が、ファイルのオープンを複数回行った場合の、カーネル５８の状態を、模式的に示している。
アプリケーション３１がファイルをオープンすると、カーネル５８の内部には、そのファイルのオープンに対応して、ファイルオブジェクト(File Object)が作成される。
図１５では、３つのファイルオブジェクト８１，８２，８３が、カーネル５８の内部に作成されている。
ここで、ファイルオブジェクト８１は、アプリケーション３１が、API関数CreateFile()を呼び出し、例えば、図７の左側に示した仮想ファイルシステム６２が管理するファイルC0001.MXFをオープンすることにより作成されたファイルオブジェクトである。
ファイルオブジェクト８２も、ファイルオブジェクト８１と同様に、アプリケーション３１が、API関数CreateFile()を呼び出し、ファイルC0001.MXFをオープンすることにより作成されたファイルオブジェクトである。
ファイルオブジェクト８３は、アプリケーション３１が、API関数CreateFile()を呼び出し、例えば、図７の左側に示した仮想ファイルシステム６２が管理するファイルC0002.MXFをオープンすることにより作成されたファイルオブジェクトである。
従って、図１５では、アプリケーション３１が、ファイルC0001.MXFをオープンするAPI関数CreateFileを２回呼び出すとともに、ファイルC0002.MXFをオープンするAPI関数CreateFileを１回呼び出すことにより、３つのファイルオブジェクト８１乃至８３が、カーネル５８の内部に作成されている。
なお、ファイルオブジェクト８１乃至８３それぞれは、対応するファイルのファイル名(File Name)、ファイルハンドル(File System File Handle)、およびファイルポインタ(File Pointer)を有する。
複数同時オープン機能は、PD_FS５４が内蔵するファイルハンドルリソースマネージャ(PD-SBP2 File Handle Resource Manager)５４Ａが提供する。
即ち、ドライブ２からPD-SBP2で返されるファイルハンドルは、いわばリソース(Resource)的な特徴、つまり、複数が同時に有効になりえない（複数を同時に使用し得ない）性質を有するものである。
そこで、ファイルハンドルリソースマネージャ５４Ａは、ドライブ２からPD-SBP2で返されるファイルハンドルに対する、カーネル８１の内部に作成された複数のファイルオブジェクトからのアクセスの排他制御を行う。なお、排他制御は、セマフォ(semaphore)その他の任意の方法で行うことができる。
即ち、ファイルハンドルリソースマネージャ５４Ａは、ドライブ２からPD-SBP2で返されるファイルハンドル（以下、適宜、PD-SBP2ファイルハンドルという）と、そのPD-SBP2ファイルハンドルを使用するファイルオブジェクトへのポインタとを記憶する。
そして、ファイルハンドルリソースマネージャ５４Ａは、現在記憶しているPD-SBP2ファイルハンドルによって特定されるファイルと異なるファイルのオープンを要求するAPI関数FileCreate()、データの読み出しを要求するAPI関数ReadFile()、またはデータの書き込みを要求するAPI関数WriteFile()が、アプリケーション３１によって呼び出されると、現在記憶しているPD-SBP2ファイルハンドルによって特定されるファイルをクローズする。
さらに、ファイルハンドルリソースマネージャ５４Ａは、アプリケーション３１によるAPI関数の呼び出しによって、オープン、データの読み出し、またはデータの書き込みが要求されたファイルのオープンを、ドライブ２に要求し、その要求に応じてドライブ２が返すPD-SBP2ファイルハンドルを、いままで記憶していたPD-SBP2ファイルハンドルに代えて新たに記憶する。また、ファイルハンドルリソースマネージャ５４Ａは、新たに記憶したPD-SBP2ファイルハンドルを使用するファイルオブジェクトへのポインタを、いままで記憶していたポインタに代えて新たに記憶する。
以上のような、PD_FS５４（のファイルハンドルリソースマネージャ５４Ａ）による複数同時オープン機能により、アプリケーション３１は、ファイルのオープンを、（見かけ上）複数同時に行うことができる。
次に、図１６のフローチャートを参照して、複数同時オープン機能について、さらに説明する。なお、ここでも、説明を簡単にするため、NTキャッシュマネージャ５９（図４）が提供するキャッシュ機能の利用は、考えないものとする。
例えば、アプリケーション３１が、ステップＳ１１１において、ファイルＡ(File "A")のオープンを要求するAPI関数CreateFile()を呼び出すと、Win32サブシステム５１（図４）が、その呼び出しに応じた要求を、NT入出力マネージャ５２に出力し、NT入出力マネージャ５２が、Win32サブシステム５１からの要求に応じて、ファイルＡのオープンを要求するAPI関数CreateFile()に対応するIRP_MJ_CREATE（のIRP）を、PD_FS５４に出力する。
PD_FS５４（のファイルハンドルリソースマネージャ５４Ａ）は、ステップＳ１３１において、アプリケーション３１がステップＳ１１１でAPI関数を呼び出すことにより供給される、ファイルＡのオープンを要求するIRP_MJ_CREATEを受信して、ステップＳ１３２に進み、そのIRP_MJ_CREATEに応じて、ファイルＡのオープンを要求するIOCTLであるIOCTL_PD_FILE_OPEN（図１３）を発行する関数IoCallDriver()を呼び出す。
NT入出力マネージャ５２は、PD_FS５４による、ステップＳ１３２での関数IoCallDriver()の呼び出しに応じて、IOCTL_PD_FILE_OPENが指定されているIRP_MJ_DEVICE_CONTROL（のIRP）を、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１７１において、PD_FS５４がステップＳ１３２で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_OPENが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE OPEN（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＡ（仮想ファイルシステム６２が外部に見せるファイルＡ）がオープンされる。
その後、例えば、アプリケーション３１が、ステップＳ１１２において、ファイルＡからのデータの読み出しを要求するAPI関数ReadFile()を呼び出すと、Win32サブシステム５１が、その呼び出しに応じた要求を、NT入出力マネージャ５２に出力し、NT入出力マネージャ５２が、Win32サブシステム５１からの要求に応じて、ファイルＡからのデータの読み出しを要求するAPI関数ReadFile()に対応するIRP_MJ_READ（のIRP）を、PD_FS５４に出力する。
PD_FS５４は、ステップＳ１３３において、アプリケーション３１がステップＳ１１２でAPI関数を呼び出すことにより供給される、ファイルＡからのデータの読み出しを要求するIRP_MJ_READを受信して、ステップＳ１３４に進み、そのIRP_MJ_READに応じて、ファイルＡからのデータの読み出しを要求するIOCTLであるIOCTL_PD_FILE_READ（図１３）を発行する関数IoCallDriver()を呼び出す。
NT入出力マネージャ５２は、PD_FS５４による、ステップＳ１３４での関数IoCallDriver()の呼び出しに応じて、IOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROL（のIRP）を、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１７２において、PD_FS５４がステップＳ１３４で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE READ（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＡからデータが読み出される。ドライブ２において読み出されたデータは、1394バスドライバ５７、SBP2ドライバ５６、PDストレージ５５、PD_FS５４、およびFSフィルタドライバ５３を介して、アプリケーション３１に供給される。
ここで、PDストレージ５５には、データの読み書きのための図示せぬリードライトバッファ(Read/Write Buffer)が用意されている。リードライトバッファのサイズは、例えば、ページング時のページサイズ(Page Size)（例えば、4KB(kilo byte)）に等しくなっており、一度に読み書きすることができるデータの最大サイズは、このリードライトバッファのサイズに制限される。
このため、PD_FS５４は、アプリケーション３１からのIRP_MJ_READ（アプリケーション３１がAPI関数ReadFile()を呼び出すことによって供給されるIRP_MJ_READ）によって読み出しが要求されるデータのサイズが、リードライトバッファのサイズを越えている場合には、アプリケーション３１からのIRP_MJ_READを、リードライトバッファのサイズ以内のデータの読み出しを要求する複数のIRP_MJ_DEVICE_CONTROLに分割し、PDストレージ５５に出力する。即ち、PD_FS５４は、アプリケーション３１からのIRP_MJ_READに応じて、リードライトバッファのサイズ以内のデータの読み出しを要求するIOCTL_PD_FILE_READを発行する関数IoCallDriver()を、複数回呼び出し、これにより、PDストレージ５５には、複数の、IOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROLが供給される。
なお、このことは、アプリケーション３１からの、ファイルへのデータの書き込みを要求するIRP_MJ_WRITEについても、同様である。
図１６では、PD_FS５４が、ステップＳ１３３で受信したIRP_MJ_READに応じ、ステップＳ１３４乃至Ｓ１３６それぞれにおいて、ファイルＡからのデータの読み出しを要求するIOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROLが、PDストレージ５５に出力されている。即ち、IOCTL_PD_FILE_READが、３回に分けて、PD_FS５４からPDストレージ５５に出力されている。
PDストレージ５５は、ステップＳ１７２乃至Ｓ１７４それぞれにおいて、PD_FS５４がステップＳ１３４乃至Ｓ１３６で出力する、IOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE READを、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力することで、３回に分けて、ファイルＡからデータを読み出す。
その後、ステップＳ１１３において、アプリケーション３１が、ドライブ２において現在オープンされているファイルＡと異なるファイルＢ(FILE "B")のオープンを要求するAPI関数CreateFile()を呼び出すと、ステップＳ１１１における場合と同様にして、ファイルＢのオープンを要求するAPI関数CreateFile()に対応するIRP_MJ_CREATEが、PD_FS５４に供給される。
PD_FS５４は、ステップＳ１３７において、アプリケーション３１からのIRP_MJ_CREATE（アプリケーション３１がAPI関数CreateFile()を呼び出すことにより供給される、ファイルＢのオープンを要求するIRP_MJ_CREATE）を受信して、ステップＳ１３８に進み、そのIRP_MJ_CREATEに応じて、ファイルＡのクローズを要求するIOCTLであるIOCTL_PD_FILE_CLOSE（図１３）を発行する関数IoCallDriver()を呼び出す。
即ち、上述したように、ドライブ２が扱うことができるファイルハンドルは、１つだけなので、PD_FS５４は、ファイルＢのオープンを要求する前に、現在オープンされているファイルＡのクローズを要求する。
PD_FS５４による、ステップＳ１３８での関数IoCallDriver()の呼び出しに応じて、NT入出力マネージャ５２は、ファイルＡのクローズを要求するIOCTL_PD_FILE_CLOSEが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１７５において、PD_FS５４がステップＳ１３８で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_CLOSEが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE CLOSE（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＡがクローズされる。
PD_FS５４は、ステップＳ１３８の処理後、ステップＳ１３９に進み、ステップＳ１３７で受信した、ファイルＢのオープンを要求するIRP_MJ_CREATEに応じて、ファイルＢのオープンを要求するIOCTLであるIOCTL_PD_FILE_OPEN（図１３）を発行する関数IoCallDriver()を呼び出すことにより、そのIOCTL_PD_FILE_OPENが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１７６において、PD_FS５４からのIRP_MJ_DEVICE_CONTROL、即ち、PD_FS５４が関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_OPENが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE OPEN（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＢ（仮想ファイルシステム６２が外部に見せるファイルＢ）がオープンされる。
その後、例えば、アプリケーション３１が、ステップＳ１１４において、ファイルＢへのデータの書き込みを要求するAPI関数WriteFile()を呼び出すと、Win32サブシステム５１が、その呼び出しに応じた要求を、NT入出力マネージャ５２に出力し、NT入出力マネージャ５２が、Win32サブシステム５１からの要求に応じて、ファイルＢへのデータの書き込みを要求するAPI関数WriteFile()に対応するIRP_MJ_WRITEを、PD_FS５４に出力する。
PD_FS５４は、ステップＳ１４０において、アプリケーション３１がステップＳ１１４でAPI関数を呼び出すことにより供給される、ファイルＢへのデータの書き込みを要求するIRP_MJ_WRITEを受信して、ステップＳ１４１に進み、そのIRP_MJ_WRITEに応じて、ファイルＢへのデータの書き込みを要求するIOCTLであるIOCTL_PD_FILE_WRITE（図１３）を発行する関数IoCallDriver()を呼び出す。
NT入出力マネージャ５２は、PD_FS５４による、ステップＳ１４１での関数IoCallDriver()の呼び出しに応じて、IOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１７７において、PD_FS５４がステップＳ１４１で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE WRITE（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＢにデータが書き込まれる。
ここで、上述したように、一度に読み書きすることができるデータの最大サイズは、PDストレージ５５におけるリードライトバッファのサイズに制限される。
このため、PD_FS５４は、アプリケーション３１からのIRP_MJ_WRITE（アプリケーション３１がAPI関数WriteFile()を呼び出すことによって供給されるIRP_MJ_WRITE）によって書き込みが要求されるデータのサイズが、リードライトバッファのサイズを越えている場合には、アプリケーション３１からのIRP_MJ_WRITEを、リードライトバッファのサイズ以内のデータの書き込みを要求する複数のIRP_MJ_DEVICE_CONTROLに分割し、PDストレージ５５に出力する。即ち、PD_FS５４は、アプリケーション３１からのIRP_MJ_WRITEに応じて、リードライトバッファのサイズ以内のデータの書き込みを要求するIOCTL_PD_FILE_WRITEを発行する関数IoCallDriver()を、複数回呼び出し、これにより、PDストレージ５５には、複数の、IOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLが供給される。
図１６では、PD_FS５４が、ステップＳ１４０で受信したIRP_MJ_WRITEに応じ、ステップＳ１４１乃至Ｓ１４３それぞれにおいて、ファイルＢへのデータの書き込みを要求するIOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLが、PDストレージ５５に出力されている。即ち、IOCTL_PD_FILE_WRITEが、３回に分けて、PD_FS５４からPDストレージ５５に出力されている。
PDストレージ５５は、ステップＳ１７７乃至Ｓ１７９それぞれにおいて、PD_FS５４がステップＳ１４１乃至Ｓ１４３で出力する、IOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE WRITEを、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力することで、３回に分けて、ファイルＢにデータを書き込む
その後、ステップＳ１１５において、アプリケーション３１が、ドライブ２において現在オープンされているファイルＢと異なるファイルＡからのデータの読み出しを要求するAPI関数ReadFile()を呼び出すと、ステップＳ１１２における場合と同様にして、ファイルＡからのデータの読み出しを要求するAPI関数ReadFile()に対応するIRP_MJ_READが、PD_FS５４に供給される。
PD_FS５４は、ステップＳ１４４において、アプリケーション３１からのIRP_MJ_READ（アプリケーション３１がAPI関数ReadFile()を呼び出すことにより供給される、ファイルＡからのデータの読み出しを要求するIRP_MJ_READ）を受信して、ステップＳ１４５に進み、そのIRP_MJ_READに応じて、ファイルＢのクローズを要求するIOCTLであるIOCTL_PD_FILE_CLOSE（図１３）を発行する関数IoCallDriver()を呼び出す。
即ち、上述したように、ドライブ２が扱うことができるファイルハンドルは、１つだけなので、PD_FS５４は、ファイルＡからのデータの読み出しを要求する前に、現在オープンされているファイルＢのクローズを要求する。
PD_FS５４による、ステップＳ１４５での関数IoCallDriver()の呼び出しに応じて、NT入出力マネージャ５２は、ファイルＢのクローズを要求するIOCTL_PD_FILE_CLOSEが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１８０において、PD_FS５４がステップＳ１４５で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_CLOSEが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE CLOSE（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＢがクローズされる。
PD_FS５４は、ステップＳ１４５の処理後、ステップＳ１４６に進み、ステップＳ１４４で受信した、ファイルＡからのデータの読み出しを要求するIRP_MJ_READに応じて、さらに、ファイルＡのオープンを要求するIOCTLであるIOCTL_PD_FILE_OPEN（図１３）を発行する関数IoCallDriver()を呼び出す。
即ち、上述したステップＳ１７５において、PDストレージ５５が、ファイルＡのクローズを要求する拡張コマンドFILE CLOSE（図１０）を、ドライブ２に出力することにより、ファイルＡは、現在クローズされているので、ファイルＡからのデータの読み出しを行うために、PD_FS５４は、ファイルＡのオープンを要求するIOCTLであるIOCTL_PD_FILE_OPENを発行する関数IoCallDriver()を呼び出す。
PD_FS５４による、ステップＳ１４６での関数IoCallDriver()の呼び出しに応じて、NT入出力マネージャ５２は、ファイルＡのオープンを要求するIOCTL_PD_FILE_OPENが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１８１において、PD_FS５４がステップＳ１４６で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_OPENが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE OPEN（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＡがオープンされる。
PD_FS５４は、ステップＳ１４６の処理後、ステップＳ１４７に進み、ステップＳ１４４で受信した、ファイルＡからのデータの読み出しを要求するIRP_MJ_READに応じて、ファイルＡからのデータの読み出しを要求するIOCTLであるIOCTL_PD_FILE_READ（図１３）を発行する関数IoCallDriver()を呼び出すことにより、そのIOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１８２において、PD_FS５４から供給される、IOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE READ（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＡからデータが読み出される。ドライブ２において読み出されたデータは、1394バスドライバ５７、SBP2ドライバ５６、PDストレージ５５、PD_FS５４、およびFSフィルタドライバ５３を介して、アプリケーション３１に供給される。
なお、上述したPDストレージ５５におけるリードライトバッファのサイズによる読み書きの制限によって、図１６では、PD_FS５４が、ステップＳ１４４で受信したIRP_MJ_READに応じ、ステップＳ１４７乃至Ｓ１４９それぞれにおいて、ファイルＡからのデータの読み出しを要求するIOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROLが、PDストレージ５５に出力されている。即ち、IOCTL_PD_FILE_READが、３回に分けて、PD_FS５４からPDストレージ５５に出力されている。
PDストレージ５５は、ステップＳ１８２乃至Ｓ１８４それぞれにおいて、PD_FS５４がステップＳ１４７乃至Ｓ１４９で出力する、IOCTL_PD_FILE_READが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE READを、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力することで、３回に分けて、ファイルＡからデータを読み出す。
その後、ステップＳ１１６において、アプリケーション３１が、ドライブ２において現在オープンされているファイルＡと異なるファイルＢへのデータの書き込みを要求するAPI関数WriteFile()を呼び出すと、ステップＳ１１４における場合と同様にして、ファイルＢへのデータの書き込みを要求するAPI関数WriteFile()に対応するIRP_MJ_WRITEが、PD_FS５４に供給される。
PD_FS５４は、ステップＳ１５０において、アプリケーション３１からのIRP_MJ_WRITE（アプリケーション３１がAPI関数WriteFile()を呼び出すことにより供給される、ファイルＢへのデータの書き込みを要求するIRP_MJ_WRITE）を受信して、ステップＳ１５１に進み、そのIRP_MJ_WRITEに応じて、ファイルＡのクローズを要求するIOCTLであるIOCTL_PD_FILE_CLOSE（図１３）を発行する関数IoCallDriver()を呼び出す。
即ち、上述したように、ドライブ２が扱うことができるファイルハンドルは、１つだけなので、PD_FS５４は、ファイルＢへのデータの書き込みを要求する前に、現在オープンされているファイルＡのクローズを要求する。
PD_FS５４による、ステップＳ１５１での関数IoCallDriver()の呼び出しに応じて、NT入出力マネージャ５２は、ファイルＡのクローズを要求するIOCTL_PD_FILE_CLOSEが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１８５において、PD_FS５４がステップＳ１５１で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_CLOSEが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE CLOSE（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＡがクローズされる。
PD_FS５４は、ステップＳ１５１の処理後、ステップＳ１５２に進み、ステップＳ１５０で受信した、ファイルＢへのデータの書き込みを要求するIRP_MJ_WRITEに応じて、さらに、ファイルＢのオープンを要求するIOCTLであるIOCTL_PD_FILE_OPEN（図１３）を発行する関数IoCallDriver()を呼び出す。
即ち、上述したステップＳ１８０において、PDストレージ５５が、ファイルＢのクローズを要求する拡張コマンドFILE CLOSE（図１０）を、ドライブ２に出力することにより、ファイルＢは、現在クローズされているので、ファイルＢへのデータの書き込みを行うために、PD_FS５４は、ファイルＢのオープンを要求するIOCTLであるIOCTL_PD_FILE_OPENを発行する関数IoCallDriver()を呼び出す。
PD_FS５４による、ステップＳ１５２での関数IoCallDriver()の呼び出しに応じて、NT入出力マネージャ５２は、ファイルＢのオープンを要求するIOCTL_PD_FILE_OPENが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１８６において、PD_FS５４がステップＳ１５２で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_OPENが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE OPEN（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＢがオープンされる。
PD_FS５４は、ステップＳ１５２の処理後、ステップＳ１５３に進み、ステップＳ１５０で受信した、ファイルＢへのデータの書き込みを要求するIRP_MJ_WRITEに応じて、ファイルＢへのデータの書き込みを要求するIOCTLであるIOCTL_PD_FILE_WRITE（図１３）を発行する関数IoCallDriver()を呼び出すことにより、そのIOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１８７において、PD_FS５４から供給される、IOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE WRITE（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＢにデータが書き込まれる。
なお、上述したPDストレージ５５におけるリードライトバッファのサイズによる読み書きの制限によって、図１６では、PD_FS５４が、ステップＳ１５０で受信したIRP_MJ_WRITEに応じ、ステップＳ１５３乃至Ｓ１５５それぞれにおいて、ファイルＢへのデータの書き込みを要求するIOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLが、PDストレージ５５に出力されている。即ち、IOCTL_PD_FILE_WRITEが、３回に分けて、PD_FS５４からPDストレージ５５に出力されている。
PDストレージ５５は、ステップＳ１８７乃至Ｓ１８９それぞれにおいて、PD_FS５４がステップＳ１５３乃至Ｓ１５５で出力する、IOCTL_PD_FILE_WRITEが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE WRITEを、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力することで、３回に分けて、ファイルＢにデータを書き込む。
その後、ステップＳ１１７において、アプリケーション３１が、ファイルＡのクローズを要求するAPI関数CloseFile()を呼び出すと、Win32サブシステム５１（図４）が、その呼び出しに応じた要求を、NT入出力マネージャ５２に出力し、NT入出力マネージャ５２が、Win32サブシステム５１からの要求に応じて、ファイルＡに関するクリーンアップを要求するIRP_MJ_CLEANUPと、ファイルＡのクローズを要求するAPI関数CloseFile()に対応するIRP_MJ_CLOSEとを、PD_FS５４に出力する。
PD_FS５４は、ステップＳ１５６とＳ１５７において、アプリケーション３１がステップＳ１１７でAPI関数を呼び出すことにより供給される、ファイルＡに関するクリーンアップを要求するIRP_MJ_CLEANUPと、ファイルＡのクローズを要求するIRP_MJ_CLOSEとを、それぞれ受信する。
そして、PD_FS５４は、ファイルＡに関するクリーンアップを要求するIRP_MJ_CLEANUPに応じ、例えば、NTキャッシュマネージャ５９（図４）が提供するキャッシュ機能によりキャッシュされたデータをフラッシュ(Flush)する等のクリーンアップ処理を行う。さらに、PD_FS５４は、IRP_MJ_CLOSEによってクローズが要求されたファイルＡがオープンされているかどうかを判定する（例えば、図１５で説明したPD-SBP2ファイルハンドルを使用するファイルオブジェクトが、ファイルＡのファイルオブジェクトとなっているかどうかを判定する）。
図１６では、上述したステップＳ１８５において、PDストレージ５５が、ファイルＡのクローズを要求する拡張コマンドFILE CLOSE（図１０）を、ドライブ２に出力することにより、ファイルＡは、現在クローズされているので、PD_FS５４では、IRP_MJ_CLOSEによってクローズが要求されたファイルＡが、既にクローズされていると判定される。この場合、PD_FS５４は、ファイルＡのクローズを要求するIRP_MJ_CLOSEに対して、特に処理を行わない。
そして、ステップＳ１１８において、アプリケーション３１が、ファイルＢのクローズを要求するAPI関数CloseFile()を呼び出すと、Win32サブシステム５１（図４）が、その呼び出しに応じた要求を、NT入出力マネージャ５２に出力し、NT入出力マネージャ５２が、Win32サブシステム５１からの要求に応じて、ファイルＢに関するクリーンアップを要求するIRP_MJ_CLEANUPと、ファイルＢのクローズを要求するAPI関数CloseFile()に対応するIRP_MJ_CLOSEとを、PD_FS５４に出力する。
PD_FS５４は、ステップＳ１５８とＳ１５９において、アプリケーション３１がステップＳ１１８でAPI関数を呼び出すことにより供給される、ファイルＢに関するクリーンアップを要求するIRP_MJ_CLEANUPと、ファイルＢのクローズを要求するIRP_MJ_CLOSEとを、それぞれ受信する。
そして、PD_FS５４は、ファイルＢに関するクリーンアップを要求するIRP_MJ_CLEANUPに応じ、例えば、上述したようなクリーンアップ処理を行う。さらに、PD_FS５４は、IRP_MJ_CLOSEによってクローズが要求されたファイルＢがオープンされているかどうかを判定する。
図１６では、上述したステップＳ１８６において、PDストレージ５５が、ファイルＢのオープンを要求する拡張コマンドFILE OPEN（図１０）を、ドライブ２に出力することにより、ファイルＢは、現在オープンされているので、PD_FS５４では、IRP_MJ_CLOSEによってクローズが要求されたファイルＢが、現在オープンされていると判定される。
この場合、PD_FS５４は、ステップＳ１５９で受信したファイルＢのクローズを要求するIRP_MJ_CLOSEに応じて、ステップＳ１６０に進み、そのIRP_MJ_CLOSEに応じて、ファイルＢのクローズを要求するIOCTLであるIOCTL_PD_FILE_CLOSE（図１３）を発行する関数IoCallDriver()を呼び出す。
PD_FS５４による、ステップＳ１６０での関数IoCallDriver()の呼び出しに応じて、NT入出力マネージャ５２は、ファイルＢのクローズを要求するIOCTL_PD_FILE_CLOSEが指定されているIRP_MJ_DEVICE_CONTROLを、PDストレージ５５に供給する。
PDストレージ５５は、ステップＳ１９０において、PD_FS５４がステップＳ１６０で関数IoCallDriver()を呼び出すことにより供給される、IOCTL_PD_FILE_CLOSEが指定されているIRP_MJ_DEVICE_CONTROLを受信し、そのIRP_MJ_DEVICE_CONTROLに対応する拡張コマンドFILE CLOSE（図１０）を、SBP2ドライバ５６および1394バスドライバ５７を介して、ドライブ２に出力する。
これにより、ドライブ２では、光ディスク３上のファイルＢがクローズされる。
以上のように、複数同時オープン機能によれば、ドライブ２において現在オープンされているファイルと異なるファイルにアクセスするアクセス要求があった場合に、PD_FS５４（のファイルハンドルリソースマネージャ５４Ａ）において、現在オープンされているファイルをクローズし、アクセス要求があったファイルをオープンすることで、ドライブ２が扱う１つのファイルハンドルに対するアクセスの排他制御を行うようにしたので、アプリケーション３１では、ドライブ２が１つのファイルハンドルしか扱うことができないことを特に考慮せずに、複数のファイルに対する操作を行うことができる。
なお、本実施の形態では、データの記録や再生が行われる記録媒体として、光ディスクを採用することとしたが、本発明は、その他、例えば、ハードディスクその他の記録媒体などに対してデータの記録や再生を行う場合に適用可能である。
また、本明細書において、PC１に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。
本発明を適用した情報処理システムの一実施の形態の構成例を示すブロック図である。 PC１のハードウェア構成例を示すブロック図である。 CPU１２が実行するプログラムを示す図である。 OS３０の内部構成例（ファイルシステム）を示すブロック図である。 OS３０が行う処理の概要を説明するフローチャートである。 ドライブ２のファイルシステムと、ドライブ２で採用されているプロトコルについて説明するための図である。 仮想ファイルシステム６２を説明するための図である。 SCSI command block ORBのフォーマットを示す図である。 SBP2 status blockのフォーマットを示す図である。 拡張コマンドを示す図である。 PD-SBP2によるファイルの読み出しシーケンスを説明するフローチャートである。 PD-SBP2によるファイルの書き込みシーケンスを説明するフローチャートである。 ユーザ定義のIOCTLを示す図である。 PD_FS５４の処理を説明するフローチャートである。 複数同時オープン機能を説明するための図である。 複数同時オープン機能の処理を説明するフローチャートである。
符号の説明
１ PC， ２ ドライブ， ３ 光ディスク， ４ 1394ケーブル， １１ バス， １２ CPU， １３ ROM， １４ RAM， １５ ハードディスク， １６ 出力部， １７ 入力部， １８ 通信部， １９ ドライブ， ２０ 入出力インタフェース， ２１ リムーバブル記録媒体， ２２ IEEE1394I/F， ３０ OS， ３１ アプリケーション， ５１ Win32サブシステム， ５２ NT入出力マネージャ， ５３ FSフィルタドライバ， ５４ PD_FS， ５４Ａ ファイルハンドルリソースマネージャ， ５５ PDストレージ， ５６ SBP2ドライバ， ５７ 1394バスドライバ， ５８ レジストリ， ５９ NTキャッシュマネージャ， ６１ 実ファイルシステム， ６２ 仮想ファイルシステム

Claims (8)

  1. ファイルシステムを有する記録又は再生装置と接続される情報処理装置において、
    アプリケーションからのファイル操作に関する要求に応じてオペレーティングシステムが提供するコマンドを受信する受信手段と、
    前記オペレーティングシステムが提供するコマンドを、前記記録又は再生装置との通信において前記ファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換手段と
    を備えることを特徴とする情報処理装置。
  2. 前記記録又は再生装置が１のファイルハンドルだけを扱う場合において、
    前記記録又は再生装置の１つのファイルハンドルに対するアクセスの排他制御を行う排他制御手段をさらに備える
    ことを特徴とする請求項１に記載の情報処理装置。
  3. 前記記録又は再生装置のファイルシステムによって行われるファイル管理を行わないファイルシステムドライバである
    ことを特徴とする請求項１に記載の情報処理装置。
  4. 前記記録又は再生装置においてファイルに読み書きされるデータは、AV(Audio Visual)データを、少なくとも含む
    ことを特徴とする請求項１に記載の情報処理装置。
  5. 前記記録又は再生装置は、記録媒体の記録領域上の所定の大きさ以上の連続した空き領域のうち、直前にデータが記録された記録領域に最も近い位置の空き領域を予約し、データを記録する
    ことを特徴とする請求項１に記載の情報処理装置。
  6. ファイルシステムを有する記録又は再生装置と接続される情報処理装置の情報処理方法において、
    アプリケーションからのファイル操作に関する要求に応じてオペレーティングシステムが提供するコマンドを受信する受信ステップと、
    前記オペレーティングシステムが提供するコマンドを、前記記録又は再生装置との通信において前記ファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換ステップと
    を含むことを特徴とする情報処理方法。
  7. ファイルシステムを有する記録又は再生装置と接続されるコンピュータに行わせるプログラムにおいて、
    アプリケーションからのファイル操作に関する要求に応じてオペレーティングシステムが提供するコマンドを受信する受信ステップと、
    前記オペレーティングシステムが提供するコマンドを、前記記録又は再生装置との通信において前記ファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換ステップと
    を含むことを特徴とするプログラム。
  8. ファイルシステムを有する記録又は再生装置と接続されるコンピュータに行わせるプログラムが記録されている記録媒体において、
    アプリケーションからのファイル操作に関する要求に応じてオペレーティングシステムが提供するコマンドを受信する受信ステップと、
    前記オペレーティングシステムが提供するコマンドを、前記記録又は再生装置との通信において前記ファイルシステムを扱うことが可能な通信プロトコルのコマンドに変換される要求に変換する変換ステップと
    を含むことを特徴とするプログラムが記録されている記録媒体。
JP2004119851A 2004-04-15 2004-04-15 情報処理装置および情報処理方法、並びにプログラムおよび記録媒体 Expired - Fee Related JP4241485B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2004119851A JP4241485B2 (ja) 2004-04-15 2004-04-15 情報処理装置および情報処理方法、並びにプログラムおよび記録媒体
EP05252292A EP1586988A3 (en) 2004-04-15 2005-04-13 Information processing apparatus, information processing method, program and recording medium used therewith
US11/105,650 US7769920B2 (en) 2004-04-15 2005-04-13 Information processing apparatus, information processing method, and program and recording medium used therewith
KR1020050030599A KR101116433B1 (ko) 2004-04-15 2005-04-13 정보 처리 장치, 정보 처리 방법 및 기록 매체
CNB2005100788275A CN100399310C (zh) 2004-04-15 2005-04-15 信息处理装置、信息处理方法及随其使用的程序和记录介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004119851A JP4241485B2 (ja) 2004-04-15 2004-04-15 情報処理装置および情報処理方法、並びにプログラムおよび記録媒体

Publications (2)

Publication Number Publication Date
JP2005301853A true JP2005301853A (ja) 2005-10-27
JP4241485B2 JP4241485B2 (ja) 2009-03-18

Family

ID=34940794

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004119851A Expired - Fee Related JP4241485B2 (ja) 2004-04-15 2004-04-15 情報処理装置および情報処理方法、並びにプログラムおよび記録媒体

Country Status (5)

Country Link
US (1) US7769920B2 (ja)
EP (1) EP1586988A3 (ja)
JP (1) JP4241485B2 (ja)
KR (1) KR101116433B1 (ja)
CN (1) CN100399310C (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007257494A (ja) * 2006-03-24 2007-10-04 Sony Corp データ記録装置、接続装置、情報処理システム、及び情報処理方法
US7647455B2 (en) 2004-04-15 2010-01-12 Sony Corporation Information processing apparatus and method, program, and program recording medium
JP2013513863A (ja) * 2009-12-09 2013-04-22 サンディスク アイエル リミティド プライベートメモリ領域内の複数の保護ファイルにアクセスするためにパブリックメモリ領域内の仮想ファイルを用いる記憶装置および方法
KR20160033497A (ko) * 2014-09-18 2016-03-28 삼성전자주식회사 호스트 및 이를 포함하는 컴퓨터 시스템

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5013477B2 (ja) 2004-11-09 2012-08-29 トムソン ライセンシング 別個の記憶媒体上のコンテンツの結合
EP1669855A1 (en) 2004-12-02 2006-06-14 Deutsche Thomson-Brandt Gmbh Method for generating multi-language menus
JP2008107965A (ja) * 2006-10-24 2008-05-08 Sony Corp 情報処理装置、情報処理方法、プログラム、プログラム記録媒体
JP4349441B2 (ja) * 2007-06-12 2009-10-21 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP5034921B2 (ja) 2007-12-14 2012-09-26 ソニー株式会社 情報処理装置、ディスク、および情報処理方法、並びにプログラム
US20100169395A1 (en) * 2008-12-26 2010-07-01 Sandisk Il Ltd. Device and method for filtering a file system
US8239395B2 (en) * 2008-12-26 2012-08-07 Sandisk Il Ltd. Storage device presenting to hosts only files compatible with a defined host capability
US8166067B2 (en) 2008-12-26 2012-04-24 Sandisk Il Ltd. Method and apparatus for providing access to files based on user identity
US8943409B2 (en) 2008-12-26 2015-01-27 Sandisk Il Ltd. Storage device managing playable content
JP2011203977A (ja) * 2010-03-25 2011-10-13 Hitachi-Lg Data Storage Inc ストレージ装置、及びストレージ装置におけるファイルシステムの生成方法
US9424271B2 (en) * 2012-08-30 2016-08-23 International Business Machines Corporation Atomic incremental load for map-reduce systems on append-only file systems
CN104750605B (zh) * 2013-12-30 2018-08-14 伊姆西公司 将内核对象信息包括在用户转储中
JP6767319B2 (ja) * 2017-07-31 2020-10-14 株式会社ソニー・インタラクティブエンタテインメント 情報処理装置およびファイルコピー方法
US11513691B2 (en) * 2021-01-09 2022-11-29 Western Digital Technologies, Inc. Systems and methods for power and performance improvement through dynamic parallel data transfer between device and host

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH025150A (ja) 1988-06-24 1990-01-10 Nec Corp 磁気ディスクボリューム空き領域管理方式
US5463772A (en) * 1993-04-23 1995-10-31 Hewlett-Packard Company Transparent peripheral file systems with on-board compression, decompression, and space management
US5961582A (en) * 1994-10-25 1999-10-05 Acorn Technologies, Inc. Distributed and portable execution environment
EP0803815A1 (en) * 1995-11-10 1997-10-29 Sony Corporation Information processing apparatus and method
DE69720550T2 (de) * 1996-09-30 2004-04-29 Matsushita Electric Industrial Co., Ltd., Kadoma Wiedergabeverfahren zur Wiedergabe Audiovisueller Daten von einer Platte und Informationsverarbeitungssystem
JP2000148651A (ja) 1998-11-10 2000-05-30 Hitachi Ltd 共有ディスク装置
JP3511935B2 (ja) 1999-03-05 2004-03-29 日本電気株式会社 マルチスレッド・プログラムにおけるファイル書込方式
JP4501197B2 (ja) * 2000-01-07 2010-07-14 ソニー株式会社 情報携帯処理システム、情報携帯装置のアクセス装置及び情報携帯装置
US6823398B1 (en) 2000-03-31 2004-11-23 Dphi Acquisitions, Inc. File system management embedded in a storage device
JP4419282B2 (ja) * 2000-06-14 2010-02-24 ソニー株式会社 情報処理装置、情報処理方法、および情報管理システム、並びにプログラム格納媒体
JP2002175286A (ja) 2000-12-05 2002-06-21 Hitachi Ltd 記憶装置、情報処理システムおよび排他制御方法
JP3629216B2 (ja) 2001-03-08 2005-03-16 株式会社東芝 デフラグメンテーション機能を有するディスク記憶システム、及び同システムにおけるデフラグメンテーション方法
US7266538B1 (en) * 2002-03-29 2007-09-04 Emc Corporation Methods and apparatus for controlling access to data in a data storage system
JP4045940B2 (ja) * 2002-04-05 2008-02-13 ソニー株式会社 記録制御装置および記録制御方法、プログラム、並びに記録媒体
US7493404B2 (en) * 2002-05-30 2009-02-17 Lsi Corporation Apparatus and method for providing transparent sharing of channel resources by multiple host machines utilizing mixed mode block and file protocols
JP2004030254A (ja) 2002-06-26 2004-01-29 Hitachi Ltd リモートｓｉ制御方式

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7647455B2 (en) 2004-04-15 2010-01-12 Sony Corporation Information processing apparatus and method, program, and program recording medium
JP2007257494A (ja) * 2006-03-24 2007-10-04 Sony Corp データ記録装置、接続装置、情報処理システム、及び情報処理方法
JP2013513863A (ja) * 2009-12-09 2013-04-22 サンディスク アイエル リミティド プライベートメモリ領域内の複数の保護ファイルにアクセスするためにパブリックメモリ領域内の仮想ファイルを用いる記憶装置および方法
US9092597B2 (en) 2009-12-09 2015-07-28 Sandisk Technologies Inc. Storage device and method for using a virtual file in a public memory area to access a plurality of protected files in a private memory area
KR20160033497A (ko) * 2014-09-18 2016-03-28 삼성전자주식회사 호스트 및 이를 포함하는 컴퓨터 시스템
KR101996266B1 (ko) 2014-09-18 2019-10-01 삼성전자주식회사 호스트 및 이를 포함하는 컴퓨터 시스템

Also Published As

Publication number Publication date
KR20060045646A (ko) 2006-05-17
EP1586988A3 (en) 2008-12-24
KR101116433B1 (ko) 2012-03-07
CN1690993A (zh) 2005-11-02
CN100399310C (zh) 2008-07-02
EP1586988A2 (en) 2005-10-19
US7769920B2 (en) 2010-08-03
JP4241485B2 (ja) 2009-03-18
US20050232589A1 (en) 2005-10-20

Similar Documents

Publication Publication Date Title
KR101116433B1 (ko) 정보 처리 장치, 정보 처리 방법 및 기록 매체
KR100942894B1 (ko) 물리적 기억 장치의 소프트웨어-이용 기억 장치 에뮬레이션
JP4406224B2 (ja) イメージファイル管理方法及びその記録媒体
KR101506578B1 (ko) 데이터 보안을 위한 파일 시스템 구성 방법 및 장치, 그에의해 만들어진 데이터 보안 영역에 접근하는 방법 및 장치,그에 따른 데이터 저장 장치
JP4359448B2 (ja) ファイルシステムフィルタドライバのためのファイルネームを管理するシステム及び方法
TWI450110B (zh) 用於直接大量儲存裝置檔案索引之方法、電腦可讀取媒體及系統
US8024363B2 (en) Information processing apparatus, information processing method, program and program recording medium
JP5782364B2 (ja) 複数のファイルを列挙した情報を生成する装置及び方法
JP2006048641A (ja) 長期間データアーカイブ用ファイルサーバ
US9449007B1 (en) Controlling access to XAM metadata
KR20030001392A (ko) 기억 장치 내의 디지털 기억 매체에 대한 정보에액세스하기 위한 파일 시스템 및 방법
JP2009187544A (ja) 取り外し可能ディスクドライブ格納システム上の追記型モードの実装のための装置
JP2005115948A (ja) ファイルをアーカイブするための方法、システム、およびプログラム
JP2007079774A (ja) ファイルシステムの構築方法
EP1769395A2 (en) Object-based storage
JP2002055995A (ja) 情報処理方法及び装置
KR101125929B1 (ko) 정보 처리 장치, 정보 처리 방법 및 프로그램 기록 매체
JP2005302233A (ja) 情報記憶装置、情報格納方法及び情報記憶処理プログラム
JP2005346706A (ja) メディアファイルの移動方法及び装置、並びにその方法を行うためのプログラムが保存された保存媒体
JP2007527572A (ja) インスタントボリュームの復旧を支援するエミュレーティッドストレージシステム
JP2007108853A (ja) 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP4232678B2 (ja) 情報処理装置および情報処理方法、並びにプログラムおよびプログラム記録媒体
JP4345559B2 (ja) 情報処理装置および情報処理方法、並びにプログラムおよびプログラム記録媒体
JP4378342B2 (ja) マルチパートファイルに変換を適用する機構
JP2008287675A (ja) ストレージインタフェース変換装置、情報処理システムおよびコンピュータプログラム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080624

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080822

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080918

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081113

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20081209

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20081222

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

Free format text: PAYMENT UNTIL: 20120109

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20120109

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20130109

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees