JP3624647B2 - 記憶装置、データ管理装置、データ管理システム、データ管理方法、ファイル管理装置、記録媒体及びファイル管理システム - Google Patents
記憶装置、データ管理装置、データ管理システム、データ管理方法、ファイル管理装置、記録媒体及びファイル管理システム Download PDFInfo
- Publication number
- JP3624647B2 JP3624647B2 JP26717497A JP26717497A JP3624647B2 JP 3624647 B2 JP3624647 B2 JP 3624647B2 JP 26717497 A JP26717497 A JP 26717497A JP 26717497 A JP26717497 A JP 26717497A JP 3624647 B2 JP3624647 B2 JP 3624647B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- directory
- data
- type
- entry
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ディレクトリの階層構造によってファイルを管理するファイル管理装置、ファイル管理方法、記録媒体及びファイル管理システムに関する。
【０００２】
【従来の技術】
従来より、例えばパーソナルコンピュータ等（以下、「ＰＣ」という。）では、ディレクトリの階層構造を形成してファイルを管理することが行われている。
【０００３】
この場合、ＰＣは、単にディレクトリの構造だけを管理して、ディレクトリ内のファイルの種別や用途については何も管理していなかった。
【０００４】
【発明が解決しようとする課題】
すなわち、ＰＣは、一のディレクトリ内に数種類のファイルが含まれることが多く、ファイルの種別や用途毎に管理する場合には全てのファイルに対してその種別等を調べる必要があり、ファイルの管理をするには時間がかかることがあった。また、このようなディレクトリにはファイルを管理するための情報が多く記憶されているため、これらのディレクトリが破壊されたときはファイルを管理することが全くできなくなる問題も生じた。
【０００５】
また、ＰＣは、アプリケーションにかかわる部分をファイルから排除しているため、アプリケーションを作る側で個別の情報を保持・管理する必要性もあった。
【０００６】
本発明は、このような実情に鑑みて提案されたものであり、ファイルの管理を容易かつ高速に行うことができるファイル管理装置、ファイル管理方法、記録媒体及びファイル管理システムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
上述の課題を解決するために、本発明に係るファイル管理装置は、ファイル番号を有するファイルと、ファイル番号とこのファイル番号が示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶する記憶手段と、記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理する管理手段とを備え、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、上記管理手段は、上記記憶手段から読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とする。
【０００８】
また、本発明に係るファイル管理方法は、ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶し、記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理し、一のディレクトリの各対象フラグ情報を読み出し、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示しており、読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とする。
【０００９】
更に、本発明に係る記録媒体は、ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶し、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、上記記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルは、上記一のディレクトリの下の階層になるように管理され、上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するか否かが判定されることを特徴とする。
【００１０】
更に、本発明に係るファイル管理システムは、ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶する記録媒体と、上記記録媒体から読み出されたファイルとディレクトリとを記憶する記憶手段と、記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理する管理手段とを有するファイル管理装置とを備え、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、上記ファイル管理装置の管理手段は、上記記憶手段から読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とする。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００１２】
本発明は、図１に示す構成のメモリカードシステム１に適用される。メモリカードシステム１は、ホストコンピュータ１０とメモリカード２０により構成される。
【００１３】
上記ホストコンピュータ１は、具体的には図１に示すように、静止画像や音声等の様々なファイルデータやディレクトリデータ等を記憶するハードディスク１１と、ハードディスク１１等からのファイルデータ等を一旦記憶して読み出すＲＡＭ（Random Access Memory）１２と、３本のラインを介してメモリカード２０とのデータの送受信を行う第１のシリアルインターフェース（以下、「第１のシリアルＩ／Ｆ」という。）１３と、各回路を制御するＣＰＵ（Central Processing Unit）１４とを備え、例えばハードディスク１１に記憶されている画像や音声等のファイルデータをディレクトリを用いた階層構造によって管理することができる。
【００１４】
ＲＡＭ１２は、例えばハードディスク１１に記憶されているファイルデータを一旦記憶し、必要に応じてこのファイルデータをバスを介して第１のシリアルＩ／Ｆ１３に供給する。
【００１５】
第１のシリアルＩ／Ｆ１３は、３本のラインを介して、メモリカード２０にデータを送信したり、メモリカード２０に記憶されているデータを受信する。具体的には、第１のシリアルＩ／Ｆ１３は、第１のラインを介して、上記制御データやファイルデータの送信の際のシリアルクロックＳＣＫを送信する。第１のシリアルＩ／Ｆ１３は、第２のラインを介して、第１のラインでのファイルデータ又は制御データ等のシリアルデータの切り換えに応じて、そのときの状態を示すチップセレクト信号ＣＳを出力する。さらに、第１のシリアルＩ／Ｆ１３は、第３のラインを介して、メモリカード２０に書き込むためのファイルデータや制御データを送信したり、メモリカード２０から読み出されたファイルデータを受信する。
【００１６】
ＣＰＵ１４は、ＲＡＭ１２やハードディスク１１のファイルデータを読み出したり、ＲＡＭ１２等にファイルデータを書き込むことを制御したり、メモリカード２０とファイルデータ等の送受信の制御も行う。例えば、ＣＰＵ１４は、メモリカード２０の図示しない誤消去防止スイッチのライトプロテクトがオンになっているかを判定するためのレジスタ命令を発行したり、メモリカード２０に対してアドレスを指定して所定のファイルデータの書込み命令を発行する。
【００１７】
ここで、メモリカード２０は、図１に示すように、上記ホストコンピュータ１からのファイルデータや制御データをシリアルで送受信する第２のシリアルＩ／Ｆ２１と、ファイルデータを記憶するフラッシュメモリ２２と、フラッシュメモリ２２に記憶されているファイルデータの読出し又は書込みを制御するコントローラ２３とを備える。
【００１８】
上記フラッシュメモリ２２は、例えばＮＡＮＤ型のものであり、図２に示すように、ホストコンピュータ１から送信されたファイルデータが消去単位となるブロック毎に分割して記憶される。各ブロック０，１，２，・・・，ｎは、ファイルデータ等を５１２バイト記憶するデータエリアと１６バイトの冗長エリアとによってなる１ページ（＝５１２バイト＋１６バイト）が集合して構成される。上記冗長エリアには、当該ブロックのデータエリアにあるデータを管理する分散管理情報が記憶されている。なお、これらの分散管理情報が集合すると集合管理情報（集合管理ファイル）が構成される。集合管理ファイルは、数ブロックで構成されて、全てのブロックのデータの状態を一括して管理するものである。
【００１９】
各ページの分散管理情報は、図３に示すように、「ブロック可／不可情報」（１バイト），「ブロックフラグ」（１バイト），「ブロック最終フラグ」（４ビット），「参照フラグ」（４ビット），「管理フラグ」（１バイト），「論理アドレス」（２バイト），「連結アドレス」（２バイト），「フォーマットリザーブ」（３バイト），「分散情報ＥＣＣ」（２バイト），「データＥＣＣ」（３バイト）を有する。
【００２０】
「ブロック可／不可情報」は、当該ブロックが使用可能な状態か使用不可能な状態かを識別するための情報である。例えば、ブロックが破損して使用不可能になった場合、「ブロック可／不可情報」は、オーバーライトされることによって、そのブロックが使用不可能であることを示すものである。「ブロックフラグ」は、当該ブロックにデータが書き込まれておらずまだ使用されていない状態を示したり、ファイルの先頭で使用されているブロックであることを示したり、ファイルの先頭以外で当該ブロックが使用されていることを示したり、消去や書換等でこのブロックが不要となった場合に使用済みにしておいて後から消去することを示したりするものである。「ブロック最終フラグ」は、ブロックが連続して１ファイルを構成する場合において、当該ブロックが最終ブロックであるかを示す。なお、「ブロック最終フラグ」で当該ブロックが最終ブロックであることが示されているときは、「連結アドレス」は指定されていても無効となる。「参照フラグ」は、後述の追加情報の参照を指定するフラグである。この追加情報は、ブロックの最終ページに存在する。「管理フラグ」は、１バイトの情報である。このうち３ビット（ｂｉｔ２〜０）は、集合管理ファイルに格納される。また、残りの５ビットは、集合管理ファイルに格納されないが、エラー訂正処理等に用いられる。「論理アドレス」は、当該ブロックの論理アドレスを示す。なお、ルートディレクトリとなるディレクトリファイルのブロックでは、論理アドレス０である。「連結アドレス」は、当該ブロックと連結するブロックの論理アドレスを示す。なお、当該ブロックが最終ブロックであることが予め分かっているときは、「ブロック最終フラグ」を立てて、「連結アドレス」に「０ｘｆｆｆｆ」がセットされる。当該ブロックが最終ブロックか分からないときは、論理アドレスを確保して、「連結アドレス」に設定する。当該ブロックが最終ブロックとなるときは、オーバーライトして「ブロック最終フラグ」を立てる。「フォーマットリザーブ」は、３バイトの情報であり、リザーブエリアである。「分散情報ＥＣＣ」は、「管理フラグ」，「論理アドレス」，「連結アドレス」，「フォーマットリザーブ」の誤り訂正に用いられる。「データＥＣＣ」は、分散管理情報以外のデータの誤り訂正を行うときに用いられる。
【００２１】
ここで、ファイルデータは、画像や音声等のユーザファイル形式のものと、システム管理のためのシステムファイル形式のものとがあり、フラッシュメモリ２２の１以上のブロックのデータエリアにおいて記憶される。
【００２２】
ユーザファイル形式のファイルデータは、図４に示すように、属性情報である５１２バイトのヘッダ部と主情報であるデータ部によって構成される。ヘッダ部は、当該ファイルデータをメモリカード２０内で管理するための情報である１２８バイトのＯＳヘッダと、汎用的で必要不可欠な管理情報である２４０バイトのファイルヘッダと、１４４バイトのエントリエリアとからなる。
【００２３】
上記ＯＳヘッダは、具体的には図５に示すように、ファイルＩＤ，ファイルバージョン，ファイルサイズ，使用ブロック数，リンク数，日付，メーカー／機種コード，初期登録ディレクトリ番号，検索キーワード，ファイル名，個別データを有する。
【００２４】
ファイルＩＤは、ファイルの種別（用途）を表すものであり、ファイルヘッダにも同様のものがある。ファイルバージョンは、いわゆるバージョンナンバーを示すものであり、ホストコンピュータ１０やメモリカード２０においてこのファイルデータを処理することができるかを判定するために用いられる。ファイルサイズは、ヘッダ部及びデータ部からなる当該ファイルデータの全体の大きさをバイト数で示すものである。使用ブロック数は、フラッシュメモリ２２で当該ファイルデータを使用しているブロック数を示すものである。リンク数は、ファイルデータと他のファイルデータ等が参照関係にある（リンクされている）ときのリンク数を示すものである。日付は、ファイルデータを作成した日付又は更新した日付を示すものである。メーカー／種別コードは、メモリカード２０にファイルデータを書き込んだ機器のメーカー名及びその機種を示すものである。初期登録ディレクトリ番号は、最初に登録したディレクトリ番号を示すものであり、ファイルデータが別のディレクトリに移った場合でも更新されるものではない。キーワード登録数は、登録されたキーワードの数を示すものである。キーワード文字コードは、キーワードの文字コードを示したものである。キーワード文字列は、キーワード，セパレータを決めて複数指定をすることもできるものである。ファイル名は、ＰＣ１０でファイルデータを管理するときに用いられるファイル名であり、メモリカード２０内では特に使用されない。０リセットリザーブは、書換えの際に必ず０にしておくものである。個別データは、ファイルＩＤ毎に管理するためのもので、例えばファイルＩＤによって決められる用途で用いられるデータであり、利用者が自由に用いることができる。
【００２５】
上記ファイルヘッダは、具体的には図６に示すように、「規格識別データ」，「ファイル規格識別データ」，「ファイルＩＤ」，「ファイルバージョン」，「アプリケーション作成日付」，「アプリケーション更新日付」，「作成メーカー／機種コード」，「更新メーカー／機種コード」，「０リセットリザーブ」，「データエントリ数」，「テーブル数」，「文字コード」，「タイトル文字列」を有する。
【００２６】
「規格識別データ」は、当該フラッシュメモリ２２が所定の規格に沿ってファイルデータを記憶していることを示すものである。「ファイル規格識別データ」は、当該ファイルデータが上記所定の規格に沿って作成されたことを示すものである。「ファイルＩＤ」は、ファイルの種別を表すものであり、ＯＳヘッダにも同様のものがある。「ファイルバージョン」は、バージョンナンバーを示すものである。「アプリケーション作成日付」は、アプリケーションを作成した日付を示すものであり、「アプリケーション更新日付」は、それを更新した日付を示すものである。「作成メーカー／種別コード」は、ファイルデータを作成したメーカー及びその機種名を示すものであり、「更新メーカー／種別コード」は、そのファイルデータを更新したメーカー及びその機種名を示すものである。「データエントリ数」は、後述のエントリデータの数を示すものである。「テーブル数」は、テーブルデータ領域のデータ数を示すものである。「文字コード」は、入力文字を所定のコード番号で示したものである。「タイトル文字列」は、タイトル文字を示したものである。
【００２７】
エントリエリアは、データ部において記憶された主となるデータ（エントリデータ）を管理するためのデータが記憶される。なお、データ部は、４つまでのエントリデータを格納することができる。すなわち、ヘッダ部とデータ部とからなるファイルデータは、最大で４つのエントリデータから構成される。なお、図４では、エントリデータとして、インデックス，画像データ，２つの補助データを例に挙げたが、特に限定されるものではなく、その他音声データ等であってもよい。したがって、エントリエリアは、上記４つのエントリデータを管理するために各エントリデータ毎に、開始アドレスと、サイズと、種別ＩＤと、個別データとが記憶される。
【００２８】
また、システムファイル形式のファイルデータは、例えばディレクトリファイルが該当し、ユーザファイル形式のものと比べて、ヘッダ部の構成が異なる。
【００２９】
上記ディレクトリファイルのヘッダ部は、図７に示すように、ＯＳヘッダと、ファイルヘッダと、システムエントリリストと、システムインフォメーションとを有する。なお、ＯＳヘッダとファイルヘッダは、上述したユーザファイル形式のものと同様である。
【００３０】
また、上記ディレクトリファイルのデータ部は、９６バイトのディレクトリインフォメーションと、グループインフォメーションと、ディレクトリエントリのリストとを有する。
【００３１】
ディレクトリインフォメーションは、図８に示すように、２バイトの「ディレクトリＩＤ」，１バイトの「対象ファイルＩＤ」，１バイトの「グループ数」，２バイトの「親ディレクトリ」，２バイトの「ディレクトリ数」，２バイトの「ファイル数（全ファイル）」，２バイトの「対象ファイル数」，２バイトの「アクセスポイント」，２バイトの「ディレクトリエントリ数」，２バイトの「システム用ディレクトリエントリ数」，２バイトの「使用システムディレクトリエントリ数」，２バイトの「確保ブロック数」，２バイトの「使用ブロック数」のデータがあり、さらに７２バイトの未使用領域とを有する。
【００３２】
このとき、「ディレクトリＩＤ」はディレクトリの種別を表し、「対象ファイル」は対象とするファイルのＩＤを示すものである。「グループ数」は登録されたグループの数であり、「親ディレクトリ」は親ディレクトリのファイル番号を示すものである。「ディレクトリ数」は含まれるディレクトリの総数を示し、「ファイル数（全ファイル）」は当該ディレクトリに含まれる全ファイルの数を示す。「対象ファイル数」は含まれる対象ファイル数を示し、「アクセスポイント」はアクセス開始ディレクトリエントリを示すものである。「ディレクトリエントリ数」は使用ユーザディレクトリエントリ数を示し、「システム用ディレクトリエントリ数」は確保システム用のディレクトリエントリ数を示す。「使用システムディレクトリエントリ数」システム用のディレクトリエントリ数を示し、「確保ブロック数」はアプリケーションで確保したいフラッシュメモリ２２のブロック数を示し、「使用ブロック数」はアプリケーションで使用したブロック数を示す。
【００３３】
グループインフォメーションは、図９に示すように、１バイトの「グループ番号」，１バイトの「グループインフォメーションサイズ」，２バイトの「ディレクトリＩＤ」，１バイトの「０リセットリザーブ」，３バイトの「リザーブ」，８バイトの「日付」，８バイトの「個別データ」，任意のバイト数の「タイトル」とを有する。「グループインフォメーションサイズ」は、グループインフォメーションの大きさを示すものであり、固定長２４バイト＋「タイトル」の任意バイト数の大きさになる。「ディレクトリＩＤ」はディレクトリ種別毎に付けられるＩＤであり、「０リセットリザーブ」は修正する場合は必ず０に設定するものである。「リザーブ」は当該ファイル作成時に０に設定するものである。「日付」は当該ファイルの作成日付を示し、これは使用者により変更可能である。「個別データ」は特に定められたものでなく、「タイトル」はディレクトリファイルのタイトルを示すものである。
【００３４】
ディレクトリエントリのリストは、ユーザファイル形式のファイルデータの一部の属性情報を管理するディレクトリエントリが複数集合して構成される。なお、１つのディレクトリエントリは４バイトである。
【００３５】
１ディレクトリエントリは、図１０に示すように、２バイトの「ファイル番号」と、「属性情報」と、「グループ番号」とで構成される。
【００３６】
ファイル番号は、図１１に示すように、２バイト中の最初のビットには「０」があり、残りの１５ビットにおいてファイル又はディレクトリの先頭論理アドレスが示されている。なお、「０ｘｆｆｆｆ」が示されている時は、未使用を意味する。
【００３７】
属性情報は、図１２に示すように、「ディレクトリ／ファイル」と、「対象フラグ」と、「マーク１」と、「マーク２」と、「連続記録」の情報を有する。「ディレクトリ／ファイル」では、１のときは当該ディレクトリの下にさらにディレクトリがあることを示し、０のときはファイルがあることを示す。「対象フラグ」では、１のときは上述のディレクトリインフォメーションで指定した対象ファイルＩＤのファイルであることを示し、０のときはそれ以外のファイルデータであることを示す。「マーク１」では、１のときはマーク１指定のがあることを示し、０のときはかかる指定がないことを示す。「マーク２」については、「マーク１」と同様である。なお、「マーク１」及び「マーク２」は、利用者が指定できるマーキングフラグである。「連続記録」では、００のときは通常のファイル，１１のときは先頭の連続ファイル，１０のときは連続指定されたファイルであることを示す。
【００３８】
「グループ番号」は、図１３に示すように、８ビットで示され、１階層の疑似階層を示すグループ番号である。
【００３９】
以上のように構成されたメモリカードシステム１において、ホストコンピュータ１０のＣＰＵ１４は、図１４に示すステップＳ１〜ステップＳ７の処理を行うことによって、ディレクトリの管理を行うことができる。
【００４０】
ステップＳ１において、ＣＰＵ１４は、フラッシュメモリ２２からルートディレクトリ用のディレクトリファイルを読み込んでＲＡＭ１２に格納して、ステップＳ２に進む。
【００４１】
ステップＳ２において、ＣＰＵ１４は、上記ディレクトリファイルから目的のディレクトリインフォメーションを読み込んでステップＳ３に進み、上記グループインフォメーション内のディレクトリＩＤをチェックして、ステップＳ４に進む。
【００４２】
ステップＳ４において、ＣＰＵ１４は、このディレクトリＩＤが示すデータに対応することができるか、すなわち、このディレクトリを取り扱うことができるかを判定し、対応できると判定したときはステップＳ５に進み、対応できないと判定したときはステップＳ７に進む。
【００４３】
ステップＳ５において、ＣＰＵ１４は、ディレクトリＩＤ別に定義されたフォーマットに従って個別データを読み込みを行ってステップＳ６に進み、そして、この個別データをアプリケーションの情報として利用する。
【００４４】
これにより、例えば論理アドレス０５のディレクトリはカメラ専用、論理アドレス１０のディレクトリは音楽専用のものにするように、予めディレクトリの用途を規定しておけば、全てのディレクトリの内容を調べないで、ディレクトリの用途を容易に管理することができる。すなわち、ホストコンピュータ１０では、ある用途毎に利用できるディレクトリを設けているため、アプリケーションで専用管理ファイルを準備する必要がなくなり、別管理をする手間を省くことができる。
【００４５】
また、個別データにアプリケーションの利用を想定したデータを入れておくことによって、ホストコンピュータ１０がサポートしていないディレクトリに対しても基本処理を実行することができる。
【００４６】
例えば、グループインフォメーションの個別データを利用して、グループ分類に使用するアイコンデータとのリンクを定義することができる。カメラ専用ディレクトリの個別データを用いることによって、一覧表示を行う際のＢＧＭとなるオーディオデータを有するディレクトリともリンクすることができる。音楽ディレクトリの個別データを用いて、アルバムのジャケットや歌詞カードのデータにリンクしたり、総演奏時間の管理を行うこともできる。また、ディレクトリＩＤによってターゲットとして扱う対象ファイルＩＤが決められているため、指定されたＩＤのファイル数を管理することによって、例えばカメラならば撮影枚数、音楽ならば曲数等を管理することができる。
【００４７】
一方、ステップＳ４において対応できないと判定したときのステップＳ７において、ＣＰＵ１４は、対応可能なアプリケーションの情報はないものとしてこのディレクトリを取り扱う。なお、このディレクトリをコピーしたり、他の機器に送信すること等は可能である。
【００４８】
また、ホストコンピュータ１０のＣＰＵ１４は、図１５に示すステップＳ１１〜ステップＳ１７の処理を行うことによって、ファイルの管理も行うことができる。
【００４９】
ステップＳ１１において、ＣＰＵ１４は、フラッシュメモリ２２から所定のファイルを読み出してＲＡＭ１２に格納し、そのファイルのファイルヘッダの読み込みを行ってステップＳ１２に進み、ファイルＩＤをチェックして、ステップＳ３に進む。
【００５０】
ステップＳ１３において、ＣＰＵ１４は、このファイルＩＤが示すデータに対応することができるか、すなわち、そのファイルを取り扱うことができるかを判定して、対応できると判定したときはステップＳ１４に進み、対応できないと判定したときはステップＳ１７に進む。
【００５１】
ステップＳ１４において、ＣＰＵ１４は、ファイルＩＤ別に定義されたフォーマットに従って個別データを読み込んでステップＳ１５に進み、この個別データをアプリケーションの情報として利用して、ステップＳ１６に進む。
【００５２】
ステップＳ１６において、ＣＰＵ１４は、エントリリストのデータ種別ＩＤを調べて、個別データエリアを含めて必要なデータ処理を実行する。
【００５３】
これにより、全てのファイルの内容を調べることなくファイルの用途を容易に管理することができる。すなわち、ホストコンピュータ１０では、ある用途毎に利用できるディレクトリ及びファイルを設けているため、アプリケーションで専用管理ファイルを準備する必要がなくなり、別管理をする手間を省くことができる。
【００５４】
一方、ステップＳ１３でファイルＩＤに示すデータに対応することができないと判定したときのステップＳ１７において、ＣＰＵ１４は、対応可能なアプリケーションの情報はないものとしてこのファイルを取り扱う。なお、このディレクトリをコピーしたり、他の機器に送信すること等は可能である。また、データ種別ＩＤによって取り扱うことができるデータがあれば、そのデータ処理を実行することはできる。
【００５５】
つぎに、ディレクトリが破壊されたときのディレクトリ復活処理について図１６を用いて説明する。すなわち、ＣＰＵ１４は、ディレクトリが破壊されたときは、ステップＳ２１以降の処理を行うことによってディレクトリを作成し、ファイルの管理を行うことができる。
【００５６】
ステップＳ２１において、ＣＰＵ１４は、ルートディレクトリがあるかを判定し、ルートディレクトリがあるときはステップＳ２３に進み、ルートディレクトリがないときはステップＳ２２に進む。
【００５７】
ステップＳ２２において、ＣＰＵ１４は、空きのルートディレクトリを作成してステップＳ２３に進む。
【００５８】
ステップＳ２３において、未処理のディレクトリがあるか、換言すると、ルートディレクトリに登録されていないディレクトリがあるかを判定する。そして、未処理のディレクトリがあるときはステップＳ２４に進み、未処理のディレクトリがないときはステップＳ２５に進む。
【００５９】
ステップＳ２４において、ＣＰＵ１４は、未処理のディレクトリＩＤを調べて、このディレクトリＩＤを上記ルートディレクトリに登録する。例えば、図８に示す「ディレクトリ数」を更新したり、ディレクトリエントリリスト内の図１０に示す１ディレクトリエントリとして、未処理のディレクトリファイルの先頭論理アドレスを登録したりして、ステップＳ２３に戻る。なお、ルートディレクトリに限らず、他のディレクトリに未処理のディレクトリが登録されることもある。これにより、ルートディレクトリを幹としたディレクトリの階層構造が決定される。
【００６０】
ステップＳ２５において、ＣＰＵ１４は、未処理のファイルがあるか、すなわちディレクトリに登録されていないファイルがあるかを判定し、未処理のファイルがあるときはステップＳ２６に進む。なお、未処理のファイルがないときは、各ディレクトリと各ファイルとの階層構造の構築は完成されているため、処理を終了する。
【００６１】
ステップＳ２６において、ＣＰＵ１４は、当該未処理ファイルのファイルＩＤと同じものがあるかを、全てのディレクトリのディレクトリＩＤを調べて、ステップＳ２７に進む。
【００６２】
ステップＳ２７において、ＣＰＵ１４は、未処理ファイルのファイルＩＤと一致するディレクトリＩＤがあるかを判定し、一致するディレクトリＩＤがあるとき、すなわち上記ファイルに対応するディレクトリがあるときはステップＳ２９に進む。また、一致するディレクトリＩＤがないとき、すなわち上記ファイルに対応するディレクトリがないときはステップＳ２８に進む。
【００６３】
ステップＳ２８において、ＣＰＵ１４は、上記未処理のファイルを登録するために必要なディレクトリを新たに作成し、このディレクトリをルートディレクトリに登録して、ステップＳ２９に進む。
【００６４】
ステップＳ２９において、ＣＰＵ１４は、新たに作成されたディレクトリに上記未処理ファイルを登録して、ステップＳ２５に戻る。ここでは、例えば図８に示す「ファイル数」を更新したり、ディレクトリエントリリスト内の図１０に示す１ディレクトリエントリとして、未処理のファイルの先頭論理アドレスを登録したりする。そして、未処理のファイルが無くなるまでステップＳ２５からステップＳ２９の処理を実行することによって、全てのファイルをディレクトリに登録して、階層構造を構築することができる。
【００６５】
したがって、ディレクトリが破壊されることによって遊離するディレクトリやファイルがあったとしても、そのディレクトリやファイルのＩＤによって元のディレクトリを作成することができるので、ディレクトリやファイルの管理の信頼性を高めることができる。
【００６６】
なお、本実施の形態では、フラッシュメモリ２２に記憶されたファイルやディレクトリの管理方法について説明したが、本発明はこれに限定されるものではなく、通常のコンピュータ等におけるデータの管理にも適用することができるのは勿論である。
【００６７】
【発明の効果】
本発明に係るファイル管理装置、ファイル管理方法、記録媒体及びファイル管理システムによれば、読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することによって、所定のファイルに対して高速にアクセスすることができる。
【図面の簡単な説明】
【図１】本発明を適用したメモリカードシステムの構成を示すブロック図である。
【図２】上記メモリカードシステムのメモリカード内のフラッシュメモリに格納される
データの構成を説明するための図である。
【図３】上記フラッシュメモリに格納されるデータの分散管理情報の構成を説明するための図である。
【図４】上記フラッシュメモリに格納されるファイルデータの構成を説明するための図である。
【図５】上記ファイルデータのＯＳヘッダの構成を説明するための図である。
【図６】上記ファイルデータのファイルヘッダ及びエントリエリアの構成を説明するための図である。
【図７】ディレクトリファイルの構成を説明するための図である。
【図８】上記ディレクトリファイルのディレクトリインフォメーションの構成を説明するための図である。
【図９】上記ディレクトリファイルのグループインフォメーションの構成を説明するための図である。
【図１０】上記ディレクトリファイルのディレクトリエントリの構成を説明するための図である。
【図１１】上記ディレクトリエントリのファイル番号を説明するための図である。
【図１２】上記ディレクトリエントリの属性情報を説明するための図である。
【図１３】上記ディレクトリエントリのグループ番号を説明するための図である。
【図１４】ディレクトリを管理するときのＣＰＵの動作を説明するフローチャートである。
【図１５】ファイルを管理するときのＣＰＵの動作を説明するフローチャートである。
【図１６】ディレクトリが破壊された場合にディレクトリを復活させるときの動作を説明するフローチャートである。
【符号の説明】
１ メモリカードシステム、１０ ホストコンピュータ、１２ ＲＡＭ、１４ ＣＰＵ、２０ メモリカード、２２ フラッシュメモリ、２３ コントローラ
【発明の属する技術分野】
本発明は、ディレクトリの階層構造によってファイルを管理するファイル管理装置、ファイル管理方法、記録媒体及びファイル管理システムに関する。
【０００２】
【従来の技術】
従来より、例えばパーソナルコンピュータ等（以下、「ＰＣ」という。）では、ディレクトリの階層構造を形成してファイルを管理することが行われている。
【０００３】
この場合、ＰＣは、単にディレクトリの構造だけを管理して、ディレクトリ内のファイルの種別や用途については何も管理していなかった。
【０００４】
【発明が解決しようとする課題】
すなわち、ＰＣは、一のディレクトリ内に数種類のファイルが含まれることが多く、ファイルの種別や用途毎に管理する場合には全てのファイルに対してその種別等を調べる必要があり、ファイルの管理をするには時間がかかることがあった。また、このようなディレクトリにはファイルを管理するための情報が多く記憶されているため、これらのディレクトリが破壊されたときはファイルを管理することが全くできなくなる問題も生じた。
【０００５】
また、ＰＣは、アプリケーションにかかわる部分をファイルから排除しているため、アプリケーションを作る側で個別の情報を保持・管理する必要性もあった。
【０００６】
本発明は、このような実情に鑑みて提案されたものであり、ファイルの管理を容易かつ高速に行うことができるファイル管理装置、ファイル管理方法、記録媒体及びファイル管理システムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
上述の課題を解決するために、本発明に係るファイル管理装置は、ファイル番号を有するファイルと、ファイル番号とこのファイル番号が示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶する記憶手段と、記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理する管理手段とを備え、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、上記管理手段は、上記記憶手段から読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とする。
【０００８】
また、本発明に係るファイル管理方法は、ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶し、記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理し、一のディレクトリの各対象フラグ情報を読み出し、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示しており、読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とする。
【０００９】
更に、本発明に係る記録媒体は、ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶し、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、上記記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルは、上記一のディレクトリの下の階層になるように管理され、上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するか否かが判定されることを特徴とする。
【００１０】
更に、本発明に係るファイル管理システムは、ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶する記録媒体と、上記記録媒体から読み出されたファイルとディレクトリとを記憶する記憶手段と、記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理する管理手段とを有するファイル管理装置とを備え、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、上記ファイル管理装置の管理手段は、上記記憶手段から読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とする。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００１２】
本発明は、図１に示す構成のメモリカードシステム１に適用される。メモリカードシステム１は、ホストコンピュータ１０とメモリカード２０により構成される。
【００１３】
上記ホストコンピュータ１は、具体的には図１に示すように、静止画像や音声等の様々なファイルデータやディレクトリデータ等を記憶するハードディスク１１と、ハードディスク１１等からのファイルデータ等を一旦記憶して読み出すＲＡＭ（Random Access Memory）１２と、３本のラインを介してメモリカード２０とのデータの送受信を行う第１のシリアルインターフェース（以下、「第１のシリアルＩ／Ｆ」という。）１３と、各回路を制御するＣＰＵ（Central Processing Unit）１４とを備え、例えばハードディスク１１に記憶されている画像や音声等のファイルデータをディレクトリを用いた階層構造によって管理することができる。
【００１４】
ＲＡＭ１２は、例えばハードディスク１１に記憶されているファイルデータを一旦記憶し、必要に応じてこのファイルデータをバスを介して第１のシリアルＩ／Ｆ１３に供給する。
【００１５】
第１のシリアルＩ／Ｆ１３は、３本のラインを介して、メモリカード２０にデータを送信したり、メモリカード２０に記憶されているデータを受信する。具体的には、第１のシリアルＩ／Ｆ１３は、第１のラインを介して、上記制御データやファイルデータの送信の際のシリアルクロックＳＣＫを送信する。第１のシリアルＩ／Ｆ１３は、第２のラインを介して、第１のラインでのファイルデータ又は制御データ等のシリアルデータの切り換えに応じて、そのときの状態を示すチップセレクト信号ＣＳを出力する。さらに、第１のシリアルＩ／Ｆ１３は、第３のラインを介して、メモリカード２０に書き込むためのファイルデータや制御データを送信したり、メモリカード２０から読み出されたファイルデータを受信する。
【００１６】
ＣＰＵ１４は、ＲＡＭ１２やハードディスク１１のファイルデータを読み出したり、ＲＡＭ１２等にファイルデータを書き込むことを制御したり、メモリカード２０とファイルデータ等の送受信の制御も行う。例えば、ＣＰＵ１４は、メモリカード２０の図示しない誤消去防止スイッチのライトプロテクトがオンになっているかを判定するためのレジスタ命令を発行したり、メモリカード２０に対してアドレスを指定して所定のファイルデータの書込み命令を発行する。
【００１７】
ここで、メモリカード２０は、図１に示すように、上記ホストコンピュータ１からのファイルデータや制御データをシリアルで送受信する第２のシリアルＩ／Ｆ２１と、ファイルデータを記憶するフラッシュメモリ２２と、フラッシュメモリ２２に記憶されているファイルデータの読出し又は書込みを制御するコントローラ２３とを備える。
【００１８】
上記フラッシュメモリ２２は、例えばＮＡＮＤ型のものであり、図２に示すように、ホストコンピュータ１から送信されたファイルデータが消去単位となるブロック毎に分割して記憶される。各ブロック０，１，２，・・・，ｎは、ファイルデータ等を５１２バイト記憶するデータエリアと１６バイトの冗長エリアとによってなる１ページ（＝５１２バイト＋１６バイト）が集合して構成される。上記冗長エリアには、当該ブロックのデータエリアにあるデータを管理する分散管理情報が記憶されている。なお、これらの分散管理情報が集合すると集合管理情報（集合管理ファイル）が構成される。集合管理ファイルは、数ブロックで構成されて、全てのブロックのデータの状態を一括して管理するものである。
【００１９】
各ページの分散管理情報は、図３に示すように、「ブロック可／不可情報」（１バイト），「ブロックフラグ」（１バイト），「ブロック最終フラグ」（４ビット），「参照フラグ」（４ビット），「管理フラグ」（１バイト），「論理アドレス」（２バイト），「連結アドレス」（２バイト），「フォーマットリザーブ」（３バイト），「分散情報ＥＣＣ」（２バイト），「データＥＣＣ」（３バイト）を有する。
【００２０】
「ブロック可／不可情報」は、当該ブロックが使用可能な状態か使用不可能な状態かを識別するための情報である。例えば、ブロックが破損して使用不可能になった場合、「ブロック可／不可情報」は、オーバーライトされることによって、そのブロックが使用不可能であることを示すものである。「ブロックフラグ」は、当該ブロックにデータが書き込まれておらずまだ使用されていない状態を示したり、ファイルの先頭で使用されているブロックであることを示したり、ファイルの先頭以外で当該ブロックが使用されていることを示したり、消去や書換等でこのブロックが不要となった場合に使用済みにしておいて後から消去することを示したりするものである。「ブロック最終フラグ」は、ブロックが連続して１ファイルを構成する場合において、当該ブロックが最終ブロックであるかを示す。なお、「ブロック最終フラグ」で当該ブロックが最終ブロックであることが示されているときは、「連結アドレス」は指定されていても無効となる。「参照フラグ」は、後述の追加情報の参照を指定するフラグである。この追加情報は、ブロックの最終ページに存在する。「管理フラグ」は、１バイトの情報である。このうち３ビット（ｂｉｔ２〜０）は、集合管理ファイルに格納される。また、残りの５ビットは、集合管理ファイルに格納されないが、エラー訂正処理等に用いられる。「論理アドレス」は、当該ブロックの論理アドレスを示す。なお、ルートディレクトリとなるディレクトリファイルのブロックでは、論理アドレス０である。「連結アドレス」は、当該ブロックと連結するブロックの論理アドレスを示す。なお、当該ブロックが最終ブロックであることが予め分かっているときは、「ブロック最終フラグ」を立てて、「連結アドレス」に「０ｘｆｆｆｆ」がセットされる。当該ブロックが最終ブロックか分からないときは、論理アドレスを確保して、「連結アドレス」に設定する。当該ブロックが最終ブロックとなるときは、オーバーライトして「ブロック最終フラグ」を立てる。「フォーマットリザーブ」は、３バイトの情報であり、リザーブエリアである。「分散情報ＥＣＣ」は、「管理フラグ」，「論理アドレス」，「連結アドレス」，「フォーマットリザーブ」の誤り訂正に用いられる。「データＥＣＣ」は、分散管理情報以外のデータの誤り訂正を行うときに用いられる。
【００２１】
ここで、ファイルデータは、画像や音声等のユーザファイル形式のものと、システム管理のためのシステムファイル形式のものとがあり、フラッシュメモリ２２の１以上のブロックのデータエリアにおいて記憶される。
【００２２】
ユーザファイル形式のファイルデータは、図４に示すように、属性情報である５１２バイトのヘッダ部と主情報であるデータ部によって構成される。ヘッダ部は、当該ファイルデータをメモリカード２０内で管理するための情報である１２８バイトのＯＳヘッダと、汎用的で必要不可欠な管理情報である２４０バイトのファイルヘッダと、１４４バイトのエントリエリアとからなる。
【００２３】
上記ＯＳヘッダは、具体的には図５に示すように、ファイルＩＤ，ファイルバージョン，ファイルサイズ，使用ブロック数，リンク数，日付，メーカー／機種コード，初期登録ディレクトリ番号，検索キーワード，ファイル名，個別データを有する。
【００２４】
ファイルＩＤは、ファイルの種別（用途）を表すものであり、ファイルヘッダにも同様のものがある。ファイルバージョンは、いわゆるバージョンナンバーを示すものであり、ホストコンピュータ１０やメモリカード２０においてこのファイルデータを処理することができるかを判定するために用いられる。ファイルサイズは、ヘッダ部及びデータ部からなる当該ファイルデータの全体の大きさをバイト数で示すものである。使用ブロック数は、フラッシュメモリ２２で当該ファイルデータを使用しているブロック数を示すものである。リンク数は、ファイルデータと他のファイルデータ等が参照関係にある（リンクされている）ときのリンク数を示すものである。日付は、ファイルデータを作成した日付又は更新した日付を示すものである。メーカー／種別コードは、メモリカード２０にファイルデータを書き込んだ機器のメーカー名及びその機種を示すものである。初期登録ディレクトリ番号は、最初に登録したディレクトリ番号を示すものであり、ファイルデータが別のディレクトリに移った場合でも更新されるものではない。キーワード登録数は、登録されたキーワードの数を示すものである。キーワード文字コードは、キーワードの文字コードを示したものである。キーワード文字列は、キーワード，セパレータを決めて複数指定をすることもできるものである。ファイル名は、ＰＣ１０でファイルデータを管理するときに用いられるファイル名であり、メモリカード２０内では特に使用されない。０リセットリザーブは、書換えの際に必ず０にしておくものである。個別データは、ファイルＩＤ毎に管理するためのもので、例えばファイルＩＤによって決められる用途で用いられるデータであり、利用者が自由に用いることができる。
【００２５】
上記ファイルヘッダは、具体的には図６に示すように、「規格識別データ」，「ファイル規格識別データ」，「ファイルＩＤ」，「ファイルバージョン」，「アプリケーション作成日付」，「アプリケーション更新日付」，「作成メーカー／機種コード」，「更新メーカー／機種コード」，「０リセットリザーブ」，「データエントリ数」，「テーブル数」，「文字コード」，「タイトル文字列」を有する。
【００２６】
「規格識別データ」は、当該フラッシュメモリ２２が所定の規格に沿ってファイルデータを記憶していることを示すものである。「ファイル規格識別データ」は、当該ファイルデータが上記所定の規格に沿って作成されたことを示すものである。「ファイルＩＤ」は、ファイルの種別を表すものであり、ＯＳヘッダにも同様のものがある。「ファイルバージョン」は、バージョンナンバーを示すものである。「アプリケーション作成日付」は、アプリケーションを作成した日付を示すものであり、「アプリケーション更新日付」は、それを更新した日付を示すものである。「作成メーカー／種別コード」は、ファイルデータを作成したメーカー及びその機種名を示すものであり、「更新メーカー／種別コード」は、そのファイルデータを更新したメーカー及びその機種名を示すものである。「データエントリ数」は、後述のエントリデータの数を示すものである。「テーブル数」は、テーブルデータ領域のデータ数を示すものである。「文字コード」は、入力文字を所定のコード番号で示したものである。「タイトル文字列」は、タイトル文字を示したものである。
【００２７】
エントリエリアは、データ部において記憶された主となるデータ（エントリデータ）を管理するためのデータが記憶される。なお、データ部は、４つまでのエントリデータを格納することができる。すなわち、ヘッダ部とデータ部とからなるファイルデータは、最大で４つのエントリデータから構成される。なお、図４では、エントリデータとして、インデックス，画像データ，２つの補助データを例に挙げたが、特に限定されるものではなく、その他音声データ等であってもよい。したがって、エントリエリアは、上記４つのエントリデータを管理するために各エントリデータ毎に、開始アドレスと、サイズと、種別ＩＤと、個別データとが記憶される。
【００２８】
また、システムファイル形式のファイルデータは、例えばディレクトリファイルが該当し、ユーザファイル形式のものと比べて、ヘッダ部の構成が異なる。
【００２９】
上記ディレクトリファイルのヘッダ部は、図７に示すように、ＯＳヘッダと、ファイルヘッダと、システムエントリリストと、システムインフォメーションとを有する。なお、ＯＳヘッダとファイルヘッダは、上述したユーザファイル形式のものと同様である。
【００３０】
また、上記ディレクトリファイルのデータ部は、９６バイトのディレクトリインフォメーションと、グループインフォメーションと、ディレクトリエントリのリストとを有する。
【００３１】
ディレクトリインフォメーションは、図８に示すように、２バイトの「ディレクトリＩＤ」，１バイトの「対象ファイルＩＤ」，１バイトの「グループ数」，２バイトの「親ディレクトリ」，２バイトの「ディレクトリ数」，２バイトの「ファイル数（全ファイル）」，２バイトの「対象ファイル数」，２バイトの「アクセスポイント」，２バイトの「ディレクトリエントリ数」，２バイトの「システム用ディレクトリエントリ数」，２バイトの「使用システムディレクトリエントリ数」，２バイトの「確保ブロック数」，２バイトの「使用ブロック数」のデータがあり、さらに７２バイトの未使用領域とを有する。
【００３２】
このとき、「ディレクトリＩＤ」はディレクトリの種別を表し、「対象ファイル」は対象とするファイルのＩＤを示すものである。「グループ数」は登録されたグループの数であり、「親ディレクトリ」は親ディレクトリのファイル番号を示すものである。「ディレクトリ数」は含まれるディレクトリの総数を示し、「ファイル数（全ファイル）」は当該ディレクトリに含まれる全ファイルの数を示す。「対象ファイル数」は含まれる対象ファイル数を示し、「アクセスポイント」はアクセス開始ディレクトリエントリを示すものである。「ディレクトリエントリ数」は使用ユーザディレクトリエントリ数を示し、「システム用ディレクトリエントリ数」は確保システム用のディレクトリエントリ数を示す。「使用システムディレクトリエントリ数」システム用のディレクトリエントリ数を示し、「確保ブロック数」はアプリケーションで確保したいフラッシュメモリ２２のブロック数を示し、「使用ブロック数」はアプリケーションで使用したブロック数を示す。
【００３３】
グループインフォメーションは、図９に示すように、１バイトの「グループ番号」，１バイトの「グループインフォメーションサイズ」，２バイトの「ディレクトリＩＤ」，１バイトの「０リセットリザーブ」，３バイトの「リザーブ」，８バイトの「日付」，８バイトの「個別データ」，任意のバイト数の「タイトル」とを有する。「グループインフォメーションサイズ」は、グループインフォメーションの大きさを示すものであり、固定長２４バイト＋「タイトル」の任意バイト数の大きさになる。「ディレクトリＩＤ」はディレクトリ種別毎に付けられるＩＤであり、「０リセットリザーブ」は修正する場合は必ず０に設定するものである。「リザーブ」は当該ファイル作成時に０に設定するものである。「日付」は当該ファイルの作成日付を示し、これは使用者により変更可能である。「個別データ」は特に定められたものでなく、「タイトル」はディレクトリファイルのタイトルを示すものである。
【００３４】
ディレクトリエントリのリストは、ユーザファイル形式のファイルデータの一部の属性情報を管理するディレクトリエントリが複数集合して構成される。なお、１つのディレクトリエントリは４バイトである。
【００３５】
１ディレクトリエントリは、図１０に示すように、２バイトの「ファイル番号」と、「属性情報」と、「グループ番号」とで構成される。
【００３６】
ファイル番号は、図１１に示すように、２バイト中の最初のビットには「０」があり、残りの１５ビットにおいてファイル又はディレクトリの先頭論理アドレスが示されている。なお、「０ｘｆｆｆｆ」が示されている時は、未使用を意味する。
【００３７】
属性情報は、図１２に示すように、「ディレクトリ／ファイル」と、「対象フラグ」と、「マーク１」と、「マーク２」と、「連続記録」の情報を有する。「ディレクトリ／ファイル」では、１のときは当該ディレクトリの下にさらにディレクトリがあることを示し、０のときはファイルがあることを示す。「対象フラグ」では、１のときは上述のディレクトリインフォメーションで指定した対象ファイルＩＤのファイルであることを示し、０のときはそれ以外のファイルデータであることを示す。「マーク１」では、１のときはマーク１指定のがあることを示し、０のときはかかる指定がないことを示す。「マーク２」については、「マーク１」と同様である。なお、「マーク１」及び「マーク２」は、利用者が指定できるマーキングフラグである。「連続記録」では、００のときは通常のファイル，１１のときは先頭の連続ファイル，１０のときは連続指定されたファイルであることを示す。
【００３８】
「グループ番号」は、図１３に示すように、８ビットで示され、１階層の疑似階層を示すグループ番号である。
【００３９】
以上のように構成されたメモリカードシステム１において、ホストコンピュータ１０のＣＰＵ１４は、図１４に示すステップＳ１〜ステップＳ７の処理を行うことによって、ディレクトリの管理を行うことができる。
【００４０】
ステップＳ１において、ＣＰＵ１４は、フラッシュメモリ２２からルートディレクトリ用のディレクトリファイルを読み込んでＲＡＭ１２に格納して、ステップＳ２に進む。
【００４１】
ステップＳ２において、ＣＰＵ１４は、上記ディレクトリファイルから目的のディレクトリインフォメーションを読み込んでステップＳ３に進み、上記グループインフォメーション内のディレクトリＩＤをチェックして、ステップＳ４に進む。
【００４２】
ステップＳ４において、ＣＰＵ１４は、このディレクトリＩＤが示すデータに対応することができるか、すなわち、このディレクトリを取り扱うことができるかを判定し、対応できると判定したときはステップＳ５に進み、対応できないと判定したときはステップＳ７に進む。
【００４３】
ステップＳ５において、ＣＰＵ１４は、ディレクトリＩＤ別に定義されたフォーマットに従って個別データを読み込みを行ってステップＳ６に進み、そして、この個別データをアプリケーションの情報として利用する。
【００４４】
これにより、例えば論理アドレス０５のディレクトリはカメラ専用、論理アドレス１０のディレクトリは音楽専用のものにするように、予めディレクトリの用途を規定しておけば、全てのディレクトリの内容を調べないで、ディレクトリの用途を容易に管理することができる。すなわち、ホストコンピュータ１０では、ある用途毎に利用できるディレクトリを設けているため、アプリケーションで専用管理ファイルを準備する必要がなくなり、別管理をする手間を省くことができる。
【００４５】
また、個別データにアプリケーションの利用を想定したデータを入れておくことによって、ホストコンピュータ１０がサポートしていないディレクトリに対しても基本処理を実行することができる。
【００４６】
例えば、グループインフォメーションの個別データを利用して、グループ分類に使用するアイコンデータとのリンクを定義することができる。カメラ専用ディレクトリの個別データを用いることによって、一覧表示を行う際のＢＧＭとなるオーディオデータを有するディレクトリともリンクすることができる。音楽ディレクトリの個別データを用いて、アルバムのジャケットや歌詞カードのデータにリンクしたり、総演奏時間の管理を行うこともできる。また、ディレクトリＩＤによってターゲットとして扱う対象ファイルＩＤが決められているため、指定されたＩＤのファイル数を管理することによって、例えばカメラならば撮影枚数、音楽ならば曲数等を管理することができる。
【００４７】
一方、ステップＳ４において対応できないと判定したときのステップＳ７において、ＣＰＵ１４は、対応可能なアプリケーションの情報はないものとしてこのディレクトリを取り扱う。なお、このディレクトリをコピーしたり、他の機器に送信すること等は可能である。
【００４８】
また、ホストコンピュータ１０のＣＰＵ１４は、図１５に示すステップＳ１１〜ステップＳ１７の処理を行うことによって、ファイルの管理も行うことができる。
【００４９】
ステップＳ１１において、ＣＰＵ１４は、フラッシュメモリ２２から所定のファイルを読み出してＲＡＭ１２に格納し、そのファイルのファイルヘッダの読み込みを行ってステップＳ１２に進み、ファイルＩＤをチェックして、ステップＳ３に進む。
【００５０】
ステップＳ１３において、ＣＰＵ１４は、このファイルＩＤが示すデータに対応することができるか、すなわち、そのファイルを取り扱うことができるかを判定して、対応できると判定したときはステップＳ１４に進み、対応できないと判定したときはステップＳ１７に進む。
【００５１】
ステップＳ１４において、ＣＰＵ１４は、ファイルＩＤ別に定義されたフォーマットに従って個別データを読み込んでステップＳ１５に進み、この個別データをアプリケーションの情報として利用して、ステップＳ１６に進む。
【００５２】
ステップＳ１６において、ＣＰＵ１４は、エントリリストのデータ種別ＩＤを調べて、個別データエリアを含めて必要なデータ処理を実行する。
【００５３】
これにより、全てのファイルの内容を調べることなくファイルの用途を容易に管理することができる。すなわち、ホストコンピュータ１０では、ある用途毎に利用できるディレクトリ及びファイルを設けているため、アプリケーションで専用管理ファイルを準備する必要がなくなり、別管理をする手間を省くことができる。
【００５４】
一方、ステップＳ１３でファイルＩＤに示すデータに対応することができないと判定したときのステップＳ１７において、ＣＰＵ１４は、対応可能なアプリケーションの情報はないものとしてこのファイルを取り扱う。なお、このディレクトリをコピーしたり、他の機器に送信すること等は可能である。また、データ種別ＩＤによって取り扱うことができるデータがあれば、そのデータ処理を実行することはできる。
【００５５】
つぎに、ディレクトリが破壊されたときのディレクトリ復活処理について図１６を用いて説明する。すなわち、ＣＰＵ１４は、ディレクトリが破壊されたときは、ステップＳ２１以降の処理を行うことによってディレクトリを作成し、ファイルの管理を行うことができる。
【００５６】
ステップＳ２１において、ＣＰＵ１４は、ルートディレクトリがあるかを判定し、ルートディレクトリがあるときはステップＳ２３に進み、ルートディレクトリがないときはステップＳ２２に進む。
【００５７】
ステップＳ２２において、ＣＰＵ１４は、空きのルートディレクトリを作成してステップＳ２３に進む。
【００５８】
ステップＳ２３において、未処理のディレクトリがあるか、換言すると、ルートディレクトリに登録されていないディレクトリがあるかを判定する。そして、未処理のディレクトリがあるときはステップＳ２４に進み、未処理のディレクトリがないときはステップＳ２５に進む。
【００５９】
ステップＳ２４において、ＣＰＵ１４は、未処理のディレクトリＩＤを調べて、このディレクトリＩＤを上記ルートディレクトリに登録する。例えば、図８に示す「ディレクトリ数」を更新したり、ディレクトリエントリリスト内の図１０に示す１ディレクトリエントリとして、未処理のディレクトリファイルの先頭論理アドレスを登録したりして、ステップＳ２３に戻る。なお、ルートディレクトリに限らず、他のディレクトリに未処理のディレクトリが登録されることもある。これにより、ルートディレクトリを幹としたディレクトリの階層構造が決定される。
【００６０】
ステップＳ２５において、ＣＰＵ１４は、未処理のファイルがあるか、すなわちディレクトリに登録されていないファイルがあるかを判定し、未処理のファイルがあるときはステップＳ２６に進む。なお、未処理のファイルがないときは、各ディレクトリと各ファイルとの階層構造の構築は完成されているため、処理を終了する。
【００６１】
ステップＳ２６において、ＣＰＵ１４は、当該未処理ファイルのファイルＩＤと同じものがあるかを、全てのディレクトリのディレクトリＩＤを調べて、ステップＳ２７に進む。
【００６２】
ステップＳ２７において、ＣＰＵ１４は、未処理ファイルのファイルＩＤと一致するディレクトリＩＤがあるかを判定し、一致するディレクトリＩＤがあるとき、すなわち上記ファイルに対応するディレクトリがあるときはステップＳ２９に進む。また、一致するディレクトリＩＤがないとき、すなわち上記ファイルに対応するディレクトリがないときはステップＳ２８に進む。
【００６３】
ステップＳ２８において、ＣＰＵ１４は、上記未処理のファイルを登録するために必要なディレクトリを新たに作成し、このディレクトリをルートディレクトリに登録して、ステップＳ２９に進む。
【００６４】
ステップＳ２９において、ＣＰＵ１４は、新たに作成されたディレクトリに上記未処理ファイルを登録して、ステップＳ２５に戻る。ここでは、例えば図８に示す「ファイル数」を更新したり、ディレクトリエントリリスト内の図１０に示す１ディレクトリエントリとして、未処理のファイルの先頭論理アドレスを登録したりする。そして、未処理のファイルが無くなるまでステップＳ２５からステップＳ２９の処理を実行することによって、全てのファイルをディレクトリに登録して、階層構造を構築することができる。
【００６５】
したがって、ディレクトリが破壊されることによって遊離するディレクトリやファイルがあったとしても、そのディレクトリやファイルのＩＤによって元のディレクトリを作成することができるので、ディレクトリやファイルの管理の信頼性を高めることができる。
【００６６】
なお、本実施の形態では、フラッシュメモリ２２に記憶されたファイルやディレクトリの管理方法について説明したが、本発明はこれに限定されるものではなく、通常のコンピュータ等におけるデータの管理にも適用することができるのは勿論である。
【００６７】
【発明の効果】
本発明に係るファイル管理装置、ファイル管理方法、記録媒体及びファイル管理システムによれば、読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することによって、所定のファイルに対して高速にアクセスすることができる。
【図面の簡単な説明】
【図１】本発明を適用したメモリカードシステムの構成を示すブロック図である。
【図２】上記メモリカードシステムのメモリカード内のフラッシュメモリに格納される
データの構成を説明するための図である。
【図３】上記フラッシュメモリに格納されるデータの分散管理情報の構成を説明するための図である。
【図４】上記フラッシュメモリに格納されるファイルデータの構成を説明するための図である。
【図５】上記ファイルデータのＯＳヘッダの構成を説明するための図である。
【図６】上記ファイルデータのファイルヘッダ及びエントリエリアの構成を説明するための図である。
【図７】ディレクトリファイルの構成を説明するための図である。
【図８】上記ディレクトリファイルのディレクトリインフォメーションの構成を説明するための図である。
【図９】上記ディレクトリファイルのグループインフォメーションの構成を説明するための図である。
【図１０】上記ディレクトリファイルのディレクトリエントリの構成を説明するための図である。
【図１１】上記ディレクトリエントリのファイル番号を説明するための図である。
【図１２】上記ディレクトリエントリの属性情報を説明するための図である。
【図１３】上記ディレクトリエントリのグループ番号を説明するための図である。
【図１４】ディレクトリを管理するときのＣＰＵの動作を説明するフローチャートである。
【図１５】ファイルを管理するときのＣＰＵの動作を説明するフローチャートである。
【図１６】ディレクトリが破壊された場合にディレクトリを復活させるときの動作を説明するフローチャートである。
【符号の説明】
１ メモリカードシステム、１０ ホストコンピュータ、１２ ＲＡＭ、１４ ＣＰＵ、２０ メモリカード、２２ フラッシュメモリ、２３ コントローラ
Claims (4)
- ファイル番号を有するファイルと、ファイル番号とこのファイル番号が示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶する記憶手段と、
記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理する管理手段とを備え、
上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、
上記管理手段は、上記記憶手段から読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とするファイル管理装置。 - ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶し、
記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理し、
一のディレクトリの各対象フラグ情報を読み出し、
上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示しており、読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とするファイル管理方法。 - ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶し、上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、
上記記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルは、上記一のディレクトリの下の階層になるように管理され、
上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するか否かが判定されることを特徴とする記録媒体。 - ファイル番号を有するファイルと、ファイル番号とそのファイル番号の示すファイルを取り扱うことができるかを示す対象フラグ情報とからなるディレクトリエントリをファイル毎に有するディレクトリとを記憶する記録媒体と、
上記記録媒体から読み出されたファイルとディレクトリとを記憶する記憶手段と、記憶された一のディレクトリのディレクトリエントリのファイル番号が示すファイルを上記一のディレクトリの下の階層になるように管理する管理手段とを有するファイル管理装置とを備え、
上記対象フラグは、ファイルの種別が該ファイルの属するディレクトリの種別と一致するか否かを示し、
上記ファイル管理装置の管理手段は、上記記憶手段から読み出した上記一のディレクトリの各対象フラグ情報に基づいて上記一のディレクトリと各ファイルの種別が一致するかを判定することを特徴とするファイル管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26717497A JP3624647B2 (ja) | 1997-09-30 | 1997-09-30 | 記憶装置、データ管理装置、データ管理システム、データ管理方法、ファイル管理装置、記録媒体及びファイル管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26717497A JP3624647B2 (ja) | 1997-09-30 | 1997-09-30 | 記憶装置、データ管理装置、データ管理システム、データ管理方法、ファイル管理装置、記録媒体及びファイル管理システム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004006082A Division JP4055712B2 (ja) | 2004-01-13 | 2004-01-13 | データ管理装置、データ管理方法及びデータ管理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11110272A JPH11110272A (ja) | 1999-04-23 |
| JP3624647B2 true JP3624647B2 (ja) | 2005-03-02 |
Family
ID=17441142
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP26717497A Expired - Fee Related JP3624647B2 (ja) | 1997-09-30 | 1997-09-30 | 記憶装置、データ管理装置、データ管理システム、データ管理方法、ファイル管理装置、記録媒体及びファイル管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3624647B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008034903A (ja) * | 2006-07-26 | 2008-02-14 | Kyocera Mita Corp | 画像読取装置 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008132795A1 (ja) * | 2007-04-25 | 2008-11-06 | Panasonic Corporation | 情報再生方法及び情報再生装置 |
-
1997
- 1997-09-30 JP JP26717497A patent/JP3624647B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008034903A (ja) * | 2006-07-26 | 2008-02-14 | Kyocera Mita Corp | 画像読取装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11110272A (ja) | 1999-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3072722B2 (ja) | フラッシュメモリを用いるデータ管理装置及びデータ管理方法並びにフラッシュメモリを用いる記憶媒体 | |
| US7039754B2 (en) | Detachably mounted removable data storage device | |
| KR101033068B1 (ko) | 메모리 장치 및 그 메모리 장치를 이용한 기록 재생 장치 | |
| JPH08328762A (ja) | 半導体ディスク装置及びそのメモリ管理方法 | |
| US6662269B1 (en) | Data rewriting apparatus, control method, and recording medium | |
| JP2001325128A (ja) | ファイル管理方法、記録又は再生装置 | |
| JP5558093B2 (ja) | 半導体装置及びメモリシステム | |
| JP3624647B2 (ja) | 記憶装置、データ管理装置、データ管理システム、データ管理方法、ファイル管理装置、記録媒体及びファイル管理システム | |
| JP4055712B2 (ja) | データ管理装置、データ管理方法及びデータ管理システム | |
| JP2001325134A (ja) | ディレクトリ設定方法、記録装置 | |
| JPH11120044A (ja) | データ処理装置、データ処理方法、データ処理システム及び記録媒体 | |
| JP3620241B2 (ja) | ファイル管理装置、ファイル管理方法、記録媒体及びファイル管理システム | |
| JP4200362B2 (ja) | 記録媒体の記録制御方法、記録制御装置および電子機器 | |
| JP4003709B2 (ja) | ファイル管理装置、ファイル管理方法及びファイル管理システム | |
| JP3531438B2 (ja) | データ管理装置、データ管理方法、データ管理システム及び外部記憶装置 | |
| JP4403338B2 (ja) | 情報処理装置、情報処理方法 | |
| JP2001331328A (ja) | 情報処理装置、情報処理方法 | |
| JP2001331280A (ja) | 情報処理装置、情報処理方法 | |
| KR100513814B1 (ko) | 데이터관리장치,데이터관리방법및기억매체 | |
| JP2002007204A (ja) | 情報処理装置、情報処理方法 | |
| JP2001325127A (ja) | アクセス方法、記録又は再生装置 | |
| JP2002007179A (ja) | 情報処理装置、ファイルシステム | |
| JP2007018528A (ja) | メモリ装置、ファイル管理方法及び記録再生装置 | |
| KR100390486B1 (ko) | 디지털 데이터 재생장치의 파일 이름 저장 방법 | |
| JP2002007194A (ja) | 情報処理方法、情報処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20031111 |
|
| 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: 20041109 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041122 |
|
| LAPS | Cancellation because of no payment of annual fees |