JP2008040806A - ファイル処理装置、ファイル処理方法およびファイル処理プログラム - Google Patents

Abstract

【課題】SEEK可能位置がファイルOPEN時のファイルサイズ内に制限されるファイルシステムに対しても、アルゴリズムの大幅な変更を伴わず、かつ処理効率のよい手法で追加部分へのSEEKを可能とする。
【解決手段】各処理のアルゴリズムに基づいて作成された変換テーブル４４に基づいて処理後のファイル容量を計算し、この計算に基づいた容量の仮ファイルの作成をファイルシステム３０に行わせるとともに、この仮ファイルの開き直しをファイルシステム３０に行わせ、開き直し後の仮ファイルに処理の結果を書き込ませる。仮ファイルに余剰領域があればこの余剰領域の無効化を行っても良い。また書き込み中に仮ファイルの領域が不足したら領域追加を行う。
【選択図】図４

Description

本発明は、ファイル処理装置、ファイル処理方法およびファイル処理プログラムに関する。

従来、携帯電話機やＰＣ（Personal Computer）などの情報処理を行う電気電子機器には、記憶媒体とこの記憶媒体に記録されているデータを管理するファイルシステムとを備える。ファイルシステムは、通常、OS（オペレーティングシステム）の持つ機能の一つとしてAPI（Application Program Interface）を介して提供され、ファイルのOPEN、READ、WRITE、CLOSE、SEEK、GetInfoなどの基本的なファイル処理を行う。アプリケーションは、適当な引数とともにAPIを介してファイルシステムを呼び出し、任意のファイル処理を行わせることができる。
一般に、ファイルシステムではファイル処理の際のアクセス開始位置（SEEK位置）をファイルポインタで管理している。このファイルポインタは、READやWRITE等でファイルを順に処理する場合は、この処理に従ってREADやWRITEの行われたデータサイズ分移動する。一方、処理の都合上、前処理の終了位置とアクセス開始位置とが異なる場合はSEEKを行ってSEEK位置を指定する必要が生ずる。
このSEEKを利用した技術として、ファイルのOPEN後にデータの書込みが終了してもファイルをCLOSEせず、またファイルのOPEN後にデータを読み出しが終了してもファイルをCLOSEしないことにより、補助記憶装置をいわゆるリングバッファのように用いて順次書込み及び読み出しを行うことができ、転送速度を高めることができる記憶制御装置が知られている（特許文献１など）。
特開２０００−２５９３６６号公報

上述したようにファイルシステムはOSにより仕様が異なる。従って、OPENしたファイルに追記を行ってもこの追記部分に対するSEEKが可能なファイルシステムが存在する一方、一部のOSではSEEK可能範囲がファイルOPEN時のファイル容量（ファイルサイズ）に制限されるものも存在し、新たに追記した部分にはSEEK不可能な仕様が存在する。

図７に追記部分へのSEEK不可能なファイルシステムを説明する図を示した。図７の左が新規ファイル作成時の例、図７の右が既存ファイルにデータ追加を行った例である。同図における各ファイルのサイズは、新規ファイルのデータ書き込み後のファイルサイズがｍバイト、既存ファイルサイズがｋバイト、既存ファイルにデータ追加されて生成されるファイル容量がｌバイトである。
新規ファイルが作成されると所定のデータ処理後のデータがこの新規ファイルに書き込まれ、（１−ｂ）のようにｍバイトの新規書き込み領域が生成される。このときファイルポインタはデータ書き込みに伴って０バイトからｍバイトまで移動する。この新規ファイル作成において、ファイルOPEN時のファイル容量は０バイトであるので０〜ｍバイトが追記部分に相当する。すなわち、ｍバイトまでファイル書き込み終了後は（１−ｃ）のようにこの追記部分のうち０バイト以上ｍバイト未満のいずれかの位置にアクセスする必要が生じてもSEEK位置を移動することができないためアクセス不可能であった。
また、ファイルにデータを追記した場合は、まず（２−ａ）のように既存のファイルが読み込まれてｋバイトの既存領域が生成される。この既存領域はファイルOPEN時のファイル容量なのでSEEK位置を移動可能である。そして所定のデータ処理後のデータがｋ〜ｌバイトに追記されて（２−ｂ）のように全ファイル容量がｌバイトとなる。すなわちｌバイトまでファイル書込み終了後は、０〜ｋバイトへはSEEK位置を移動可能であるがｋバイトより大きくｌバイト以下の範囲へはSEEK位置を移動不可能となる。

このようにSEEKに制限のある仕様のファイルシステムを採用した携帯電話機やＰＣなどの情報処理を行う電気電子機器には、SEEKに制限の無い仕様を前提として開発されたアプリケーションの使用がそのままではできなくなる。この場合の対策として、アプリケーションのアルゴリズム（手順）を変更することが考えられる。
この変更としては、例えば追加部分の書込開始位置からデータを書き込むために、SEEK可能な位置から書込開始位置までのデータを全て読み込み、読み込んだデータと書き込むべきデータとをバッファ上で１つにまとめ、SEEK可能な位置を指定してSEEKを行った後でまとめたデータをそのSEEKした位置から書き込む、というアルゴリズムが必要となる。このアルゴリズムを採用するとアルゴリズムの大幅な変更が伴うためアプリケーションの開発工程および検査工程が増大するとともにアプリケーションプログラム側の負担が増大するという問題がある。

本発明は、上記課題に鑑みてなされたもので、SEEK可能位置がファイルOPEN時のファイル容量内に制限されるファイルシステムに対しても、アルゴリズムの大幅な変更を伴わず、かつ処理効率のよい手法で追加部分へのSEEKを可能とするファイル処理装置、ファイル処理方法およびファイル処理プログラムを提供することを目的とする。

上記目的を達成するため、本発明は、シークがファイルオープン時のファイル容量内に制限されるファイルシステムに対して所定のファイル処理を指示するファイル処理装置であって、仮ファイル作成手段と開き直し手段と書込手段とを備えることを特徴とする。

上記仮ファイル作成手段は、ファイルに対する所定のデータ処理が開始されると、所定のファイル容量を持つ仮ファイルの作成を上記ファイルシステムに指示する。次に上記ファイルシステムに対して上記開き直し手段がクローズとオープンとを順に指示する。そして上記書込手段は開き直された仮ファイルに対する上記データ処理の結果の書き込みをファイルシステムに指示し、この書込み終了後に同仮ファイルのクローズをファイルシステムに指示する。

上記所定のファイル容量とは、データ処理後のデータを格納するのに十分な容量が望ましく、仮ファイルは新規ファイルとして用意されたり、既存のファイルに所定のファイル容量となるように領域を追加して用意されたりしてもよい。すなわち、データ処理後のデータを新規ファイルに格納する場合は、新規ファイルの容量が所定のファイル容量となり、データ処理後のデータを既存のファイルの更新ファイルとして保存する場合は、既存のファイルに一定の容量を追加して所定のファイル容量とする。
また所定のファイル容量は、処理の種類、処理前のファイル容量等により処理後に作成されると想定される容量とすることが考えられ、例えば処理のアルゴリズムに基づいて想定できる。また、上記十分な容量とは、格納に必要と想定される容量以上を意味する。従ってファイル処理装置の機器特性（バッファサイズ、処理速度、記憶領域容量等）次第では、格納に必要とされる容量と同一であっても良いし、格納に必要とされる容量より大きな仮ファイルを作成してもよい。アルゴリズムに基づいても格納に必要な容量が想定不可能な処理では、一定容量の新規ファイルを作成したり、一定容量の領域現在のファイルに追加することが考えられる。該十分な容量は、予めチューニングされた式や値のテーブルをプログラム段階で設定することが考えられる。
上記クローズとオープンは上記仮ファイルの全領域でシーク可能とするために行うものであり、仮ファイル容量をファイルオープン時のファイル容量と一致させるために行う。上記制限とはファイル容量内でのみ可能でありファイル容量を超えると不可能となることを意味する。該ファイル処理装置は、携帯電話やＰＣや情報家電等、ファイル処理を行う情報処理装置が考えられる。

上述したファイル処理装置は、ある機器に組み込まれた状態で他の方法とともに実施されることもある等、各種の態様を含む。また、本発明は、上述した装置の構成に対応した工程を有する制御方法、上述した装置の構成に対応した機能をコンピュータに実現させるプログラム、該プログラムを記録したコンピュータ読み取り可能な記録媒体、等としても適用可能である。これらファイル処理方法、ファイル処理プログラム、該プログラムを記録した媒体、の発明も、上述した作用、効果を奏する。

以上説明したように請求項１、請求項７、請求項８に係る発明よれば、シークがファイルオープン時のファイル容量内に制限されるファイルシステムが採用されたファイル処理装置であっても、仮ファイルの作成処理および仮ファイルの開き直し処理をデータ処理開始時に一回行うだけで、データ処理により増加したファイル領域にもシークが可能なファイル処理装置、ファイル処理方法、ファイル処理プログラムを提供できる。
また請求項２に係る発明によれば、アルゴリズムに基づいて仮ファイルを作成するためより適切な容量の仮ファイルを用意することが可能となる。
そして請求項３に係る発明によれば、予め容易されたテーブルにより各データ処理に必要な仮ファイルの容量を想定するため、計算処理を行う必要が無く、処理時間短縮につながる。

さらに請求項４に係る発明によれば、変化率を示す情報により各処理の前後で変化するファイル容量を計算するので、より適切な容量の仮ファイルを用意することができる。
さらに請求項５に係る発明によれば、仮に上記計算より処理後のファイル容量が超過しても仮ファイルに領域を追加し、かつ仮ファイルの開き直しを行うので、仮ファイルの容量不足を回避するとともに仮ファイルの全領域にシーク可能とすることができる。
また請求項６に係る発明によれば、メモリに記録する前に余剰領域を削除するためメモリを効率的に利用可能となる。

以下、下記の順序に従って本発明の実施形態を説明する。
（１）本発明の構成：
（２）ファイル処理：

（１）本発明の構成：
以下、本発明のファイル処理装置を具体化した一実施形態としての携帯電話機を図１〜６に従って説明する。
図１は携帯電話機の外観を示す正面図である。携帯電話機１０は、電話機能（通話機能）と無線送信機能の他に、少なくとも、電子メール機能と、ブラウザ機能と、静止画や動画を撮影するカメラ機能を備えている。

携帯電話機１０は、操作面１１を有する操作部１０ａと、表示パネル１５を有する表示部１０ｂと備え、この操作面１１と表示パネル１５とが対面するように開閉可能に連結されている。操作面１１は入力を行う操作キー１２を備えている。操作キー１２は少なくとも電話番号入力または文字入力のために操作される複数のキーと、項目を選択するための選択キー（十字キー）と、項目の選択入力を行う決定キーとを備えるが、これら以外に電源キー、電子メールキー、インターネットキー（ブラウザ起動キー）、などの各種機能が割り当てられたキーを備えてもよい。携帯電話機１０には各種アプリケーションが搭載され、表示パネル１５の画面にアプリケーションで扱われる各種画像やテキストなどが表示される。

図２は携帯電話機１０の電気的構成を示すブロック図である。携帯電話機１０は、概略、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、通信部２４と、操作キー１２と、表示パネル１５と、Removable Memory Interface(以下、ＲＭＩＦと略す)２５とを備える。通信部２４は公衆電話回線網と接続できる所定周波数帯域の電波を送受信できるアンテナおよび通信回路を備え、通話、電子メールおよびインターネットを可能にする。また通信部２４は赤外線通信やBluetooth（Ｒ）などの近距離無線通信部を備えてもよい。

ＲＭＩＦ２５は、携帯電話機１０の操作部１０ａに挿着されたRemovable Memory（以下、ＲＭと略す）２６と接続される。ＲＭ２６は増設メモリとして機能し、携帯電話機１０が取り扱う各種データなどが記憶可能である。また携帯電話機１０は、OS（オペレーティングシステム）および携帯電話機の機能として必要な各種プログラムがＲＯＭ２２に格納されている。なお、例えば携帯電話機１０内のＲＯＭ２２にはOS内あるいはOSとは別にファイルシステムを構築するファイルシステム用プログラムが記憶されており、またＲＭ２６には画像編集機能を有するアプリケーションプログラムが記憶されている。

図３は、携帯電話機１０において、ＣＰＵ２１がファイルシステム用プログラムおよびアプリケーションプログラムを実行することにより構築される機能ブロック図である。
同図に示すように、携帯電話機１０はファイルシステム３０とファイル編集システム４０とを備えている。ファイル編集システム４０はアプリケーションプログラムであるファイル編集用プログラムをＣＰＵ２１が実行すると携帯電話機１０内に構築される。ファイルシステム３０はファイル管理部３５(本例ではＲＭ２６)に格納されているファイルを管理し、ファイル編集システム４０がファイル管理部３５にアクセスする場合はファイルシステム３０を介して行う。ファイル編集システム４０はファイルシステム３０が管理するファイルを呼び出して、呼び出したファイルに対して編集処理（データ処理）を行う。

編集処理とは、１つの画像データに他の画像データを貼り付けて合成する処理（フレーム画像に写真画像を貼り付ける合成処理等）、あるいは画像データにテキストデータを貼り付けて合成する処理（画像データに住所・氏名などのテキストデータを貼り付ける合成処理）、画像をJPEGに圧縮する処理等である。フレーム画像は、例えば通信部２４を介してインターネットに接続してメーカーやソフトサービス会社のサ一バが提供するものをダウンロードして入手する。写真画像は、携帯電話機１０のカメラ機能を用いて撮像した写真やデジタルカメラで撮像した写真データをＲＭ２６に記憶させてこれを携帯電話機１０に挿着することで取得する。特に本実施形態の編集処理では画像編集処理を例にとり説明する。

ファイル編集システム４０は、入力制御部４１とファイル要求部４２と編集処理部４３と変換テーブル４４とを備える。入力制御部４１は操作キー１２からの入力を受け付け、例えば画像データの選択・取得のための操作入力、文字入力、その他各種の指示入力などを受け付ける。編集処理部４３は、入力制御部４１が受け付けた指示に基づき、複数の画像データを合成したり画像データとテキストデータを合成したりするなどの編集処理を行う。ファイル要求部４２は、ファイルシステム３０に対してSystemCallを発行し、ファイルに関する所定の処理を指示する。変換テーブル４４は「処理の種類」と「容量変化率」とを対応付けるテーブルである。「容量変化率」は、「処理の種類」の処理により変化するファイル容量（ファイルサイズ）の割合を示す。

SystemCallには、OPEN（オープン）、CLOSE（クローズ）、READ（リード）、WRITE（ライト）、SEEK（シーク）などがある。ファイル編集システム４０は、ファイルシステム３０からSystemCallに対する返り値を受け取り、この返り値に基づき、指示した処理の成功・失敗などを判断する。なお、本実施形態では、OPEN、CLOSE、READ、WRITE、SEEKなどのSystemCallは、ライブラリ関数も含む広い概念のファイル操作関数を指す。

ファイルシステム３０は、制御部３１とＦＡＴ管理部３２とバッファ３３を備える。ファイルシステム３０はSystemCallを受け付けると対応するファイル処理を実行する。すなわち制御部３１は、ファイル編集システム４０からファイル名で指定されたファイルを開くOPENのSystemCallを受け付けると、これに応答してファイル管理部３５にアクセスして指定のファイルを読み込んでバッファ３３上に展開するOPEN処理を行う。また、制御部３１は、ファイル編集システム４０からREADのSystemCallを受け付けると、これに応答してバッファ３３上のファイルから指定のデータをファイル編集システム４０に読み込ませるREAD処理を行う。さらに制御部３１は、ファイル編集システム４０からWRITEのSystemCallを受け付けると、これに応答してバッファ３３上のファイルに指定されたデータを書き込むWRITE処理を行う。また、制御部３１はファイル内の位置を指定するSEEKのSystemCallを受け付けると、ファイルポインタを指定された位置に移動させるSEEK処理を行う。シーク処理後、リードまたはライトのSystemCallを受け付けたときには、SEEKによって移動させた新たなファイルポインタの位置から、指定のデータの読込みまたは書込みを開始する。

本実施形態のファイルシステム３０はFAT File Systemであり、ＦＡＴ管理部３２はＦＡＴ(ファイルアロケーションテーブル(File Allocation Table))を管理している。ＦＡＴは、ファイルが格納管理されているファイル管理部３５(本例ではＲＭ２６)に格納されるファイルの位置と順番を把握するために参照され、ＲＭ２６上のファイルの物理的位置を記録したテーブルである。ファイルシステム３０の制御部３１は、OPEN処理やCLOSE処理等を行うときに、ＦＡＴ管理部３２のＦＡＴを参照する。制御部３１は、ファイル管理部３５からファイルを読み出したりファイル管理部３５にファイルを書き込んだりするときは、ＦＡＴ管理部３２のＦＡＴを参照する。

ファイルシステム３０では、ＲＭ２６は非常に多数の小さなClusterに分割して管理され、ファイルは小さなPieceに分割されて、それぞれ別々のClusterに格納して保存される。ＦＡＴは、Cluster内で各ファイルの状態を把握でき、新しいファイル作成時やデータ書込み時は、割り当てのないClusterを見つけることができる情報を制御部３１に提供する。ファイルを読み出すときは、制御部３１はＦＡＴ管理部３２のＦＡＴを参照してそのファイルのPieceを組み立て直して閲覧できるようにする。

（２）データ処理：
以下、図４〜６を参照して本実施形態のファイル編集システム４０のデータ処理について説明する。図４と図５はファイル構造の説明図、図６はファイル編集システム４０のデータ処理を示すフローチャートである。図６のデータ処理は、入力制御部が所定のデータ処理の指示入力などを受け付けると実行される。ファイル編集システム４０はデータ処理中に、適宜SystemCallを発行してファイルシステム３０にファイル処理を実行させる。以下の説明では「OPENのSystemCallの発行」等を単に「OPENの発行」等として記載する。なお、本実施形態のファイルシステム３０は、段落０００３から段落０００５で述べたようにファイルOPEN時のファイル範囲内にSEEK位置が制限される。

携帯電話機１０の利用者は、データ処理を行うための操作を所定の操作キー１２に対して行うことによりファイル編集プログラムを起動可能である。携帯電話機１０では、利用者から同操作の入力を受け付けると、まずステップＳ１０でデータ処理の結果として生成されるデータを格納するのに十分な仮ファイル容量を想定する処理を行う。ファイル編集システム４０は、処理種類と仮ファイルの容量とを関連付けた変換テーブル４４を有し、この変換テーブル４４によって処理の結果として生成されるデータの格納に十分な仮ファイルの容量を想定できる。（以下、想定された仮ファイル容量を想定容量と略す）

変換テーブル４４としては、処理種類、処理対象ファイル（以下、元ファイルと略す）の容量、作成すべき仮ファイル容量、を関連付けたものが考えられる。処理対象ファイルの容量と仮ファイルの容量との関連付けの仕方としては、処理対象のファイル容量が所定容量範囲にあるとき所定容量の仮ファイルを作成するなどとすることができる。つまり処理対象のファイル容量が０〜ａバイトの時は仮ファイルをＡバイトに、ａ〜ｂバイトの時はＢバイトに、ｂ〜ｃバイトの時はＣバイトに、とする。この変換テーブル４４は、各処理において作成すべき仮ファイルの容量が定義されたテーブルに相当する。

また、変換テーブル４４としては、処理種類と該処理による容量変化率（例えばJPEGでは圧縮率等）を関連付けたものでもよい。すなわち、ファイル編集システム４０は、処理種類から容量変化率を取得し、処理対象ファイルの容量と取得した容量変化率から処理後のファイル（以下、新ファイルと略す）の容量を想定する。この想定における計算処理を実行するファイル編集システム４０が計算手段を構成する。

次にステップＳ２０で、ステップＳ１０のファイル容量計算に従ってバッファ３３上に仮ファイルを作成する。
新ファイルを元ファイルに上書きする場合は、ファイル要求部４２がファイルシステム３０に対して元ファイルを開くOPENを発行し、続いてファイルシステム３０に対して仮ファイルを書き込むWRITEを発行する。ファイルシステム３０ではOPENを受け付けると新規ファイルのOPEN処理が行われ、WRITEを受け付けると仮ファイルの書込み処理が行われる。

これらの処理の想定容量をｍバイトとすると、図４（ａ）に示すようにｎバイトの元ファイルをバッファ３３上に開き（ｍ＞ｎとする）、図４（ｂ）に示すように元ファイル（ｎバイト）末端に所定容量（ｍ−ｎバイト）のファイル（ダミーファイル）を追加し（容量拡張）、元ファイルと追加されたファイルとの合計が上述の想定容量（ｍバイト）となる仮ファイルを作成させる。すなわち、この時点での仮ファイルでは、元ファイル部分（０〜ｎバイト）は既存領域であり該元ファイル部分に対するSEEKは可能であるが、追加ファイル部分（ｎ〜ｍバイト）は新規書込領域であり該追加ファイル部分に対するSEEKは不可能である。
一方、新ファイルを元ファイルとは別の新規ファイルとして作成する場合は、ファイル要求部４２がファイルシステム３０に対して新規ファイルを作成するOPENを発行し、新規ファイルがOPENされると仮ファイルを書き込むWRITEを発行する。ファイルシステム３０ではOPENを受け付けると新規ファイルのOPEN処理が行われ、WRITEを受け付けると仮ファイルの書き込み処理が行われる。
これらの処理の想定容量をｍバイトとすると、図５（ａ）に示すように所定容量（ｍバイト）のファイル（ダミーファイル）が新規ファイルとしてバッファ３３に書込まれ、ファイル容量が想定容量（ｍバイト）の仮ファイルが作成される。すなわち、この時点での仮ファイルでは、全領域（０〜ｍバイト）が新規書込み領域であるため該全領域に対するSEEKが不可能である。
よって計算に基づいて所定の処理後のファイル格納に十分な容量を持つ仮ファイルが作成される。このステップＳ２０を実行するファイル編集システム４０が仮ファイル作成手段を構成する。ここでダミーファイルは、無意味なデータの書き込みやファイル容量情報の変更等により作成可能であり、各機器において採用したファイルシステムの仕様に従って作成される。

ステップＳ２２では、ステップＳ２０で生成した仮ファイルの開きなおしを行う。つまり、ファイル要求部４２はファイルシステム３０に対して仮ファイルを指定してCLOSEを発行し、クローズ処理終了後OPENを発行する。CLOSEを受け付けたファイルシステム３０では、仮ファイルのクローズ処理が行われる。すなわち、制御部３１はＦＡＴ管理部３２のＦＡＴを参照してファイル管理部内の空き容量を検索し、バッファ３３の仮ファイルをファイル管理部３５の引き当てた空き容量に書き込む。次に、OPENを受け付けたファイルシステム３０では、仮ファイルのOPEN処理が行われる。すなわち、制御部３１はＦＡＴ管理部３２のＦＡＴを参照して仮ファイルを構成する各Pieceが格納されたClusterを調べ、ファイル管理部３５内における各Clusterから読み込んだPieceを組立て直してバッファ３３上に仮ファイルを展開する。この処理により、図４（ｃ）および図５（ｂ）に示すように仮ファイルの全領域（０〜ｍバイト）が既存領域となり、該全領域に対するSEEKが可能となる。このステップＳ２２を実行するファイル編集システム４０が開き直し手段を構成する。

ステップＳ２４では、所定の処理を行って該所定の処理の結果（新ファイル）を仮ファイルに書き込む。つまり、ファイル要求部４２は、ファイルシステム３０に対してバッファ３３上の仮ファイルに新ファイルを書き込むWRITEを発行する。WRITEを受け付けたファイルシステム３０では、仮ファイル上に新ファイルを書き込むWRITE処理が行われる。仮ファイルは上述の計算により新ファイルを格納可能な容量に作成されており、新ファイルは仮ファイル上に全て書込み可能である。すなわち、この書込み処理では、図４（ｄ）および図５（ｃ）に示すように新ファイル（０〜ｋバイト）が既存領域である仮ファイル（０〜ｍバイト、ｋ≦ｍ）上に書き込まれるため新ファイル（０〜ｋバイト）の全領域に対するSEEKが可能となる。

ところで、仮ファイルは所定の処理のアルゴリズムに基づいた容量で作成されるが、処理によってはアルゴリズムに基づく新ファイルの容量計算が難しいものも存在する。このような場合、新ファイルが上述のステップＳ２０〜Ｓ２４で作成した仮ファイルを超過して仮ファイルの領域が不足し、該新ファイルが該仮ファイル内に格納不可能な場合が考えられる。そこで仮ファイルに新ファイルの書込みが終了したか否かを判断する処理をステップＳ２６で行う。ステップＳ２６で条件成立時にはステップＳ２８〜Ｓ３０に進んでファイルCLOSEに関する処理を行い、条件不成立時にはステップＳ３２〜Ｓ３４に進んで仮ファイルへの領域追加に関する処理を行う。

ステップＳ３２では、仮ファイル領域が終了しているか否かを判断する。具体的には、所定の処理により作成された新ファイルを仮ファイル領域に書き込んでいき、仮ファイル領域全体に新ファイルが書き込まれているが、新ファイルの書込みは終了していない状態であるか否かを判断する。この判断は、例えば所定時間毎や所定書込み量毎に行われ、書込み処理に従って移動したポインタと仮ファイルの末端アドレスとを比較する等して実現できる。これは所定の処理により生成された新ファイルが仮ファイルよりも大きいか否かの判断とも言える。仮ファイル領域が未終了のときはステップＳ２２に戻って書き込み処理を続行する（条件不成立）。一方、仮ファイル領域が終了している場合はステップＳ３４に進む（条件成立）。

ステップＳ３４では、仮ファイルの末端に所定容量の領域を追加する。つまりファイル編集システム４０はファイルシステム３０に仮ファイルの末端に所定容量の領域を追加させるWRITEを発行する。WRITEを受け付けるとファイルシステム３０はダミーファイルの書込み処理を行う。この処理では、仮ファイル末端から後方に所定容量のファイル（ダミーファイル）を書き込むことにより領域を追加する。つまり図４（ｅ）および図５（ｄ）のように仮ファイル（０〜ｋバイト）の末端（ｋバイト目）から後方に所定容量（ｌ−ｍ、ｌ≧ｍ）の領域を追加して仮ファイルの総容量をｌバイトとする。このときｋ〜ｌバイトは新規書込領域なのでSEEK不可能である。
ステップＳ３４終了後、ステップＳ２２に戻り新たな仮ファイルの開き直しを行うため新たな仮ファイル（０〜ｌバイト）の全領域に対するSEEKが可能となる。そしてステップＳ２４の書込み処理を継続する。

ここでステップＳ３４の所定容量とは各機器特性によりファイル編集プログラムのプログラム段階で予め設定される量である。機器特性としては、例えば機器によるメモリ（バッファ）の多寡であり、メモリの少ない機器では一定量（例えば１０KBなど）ずつ追加し、メモリが十分な機器では一気に追加（例えば現ファイル容量の一割など）することが考えられる。また、メモリの総量で判断するようにプログラムしても良いし、メモリの空き容量で判断するようにプログラムしても良い。
むろん所定の処理により生成される新ファイルの容量を該所定の処理のアルゴリズムに基づいて間違いなく計算可能である場合（必ず所定容量以下になるとの想定が可能な場合）、もしくは計算された新ファイルの容量より十分に大きな仮ファイルを用意できるだけのメモリを有している場合は、ステップＳ２６、Ｓ３２、Ｓ３４の処理は無くても構わない。

一方、ステップＳ２８では仮ファイルの余剰領域を無効化する処理を行う。この無効化処理としては、ファイルを終了させたい位置にファイル終端を示す情報（例えばEOF（EndOfFile）やEOI（EndOfImage）等）を付加することによって行う。本実施例ではEOFでファイル終端を示す場合を例にとって説明する。
まず、ファイル編集システム４０はファイルシステム３０に例えばSEEKとSetEndOfFileを順に発行する（ファイルシステムによってはtruncateの発行で代替可能）。ここでSEEKは仮ファイル中の新ファイル末端を指定して行われ、次いで発行されるSetEndOfFileは新ファイル末端に移動したファイルポインタを指定して行われる。
このSEEKを受け付けたファイルシステムは指定された位置にファイルポインタを移動させるSEEK処理を行う。またSetEndOfFileを受け付けたファイルシステムは現在のファイルポインタの位置にファイル終端を示す情報を付加する。このSEEK処理とSetEndOfFile処理により仮ファイルのEOFを新ファイルの末端に移動させ、仮ファイルの容量を新ファイルの容量に一致させることができる。
つまり図４（ｆ）および図５（ｅ）では、ステップＳ２８の処理前はｍバイト目に記載されていたEOFを該処理によりｋバイト目に移動させ、仮ファイル（０〜ｍバイト）中で新ファイル（０〜ｋバイト）が記録されていない領域（ｋ〜ｍバイト）を無効化することにより仮ファイルから削除することができる。よって仮ファイルからデータの記載されていない余剰領域が無くなり、仮ファイルの保存に必要なメモリを少なくすることが可能となる。

むろん所定の処理により生成されるファイルが、その仕様上、後部に無意味なデータが存在しても構わないのであれば、ステップＳ２８、Ｓ３０の処理は省略しても構わない。例えば、JPEGのように０〜ｘバイトに意味のある情報が存在するとのヘッダを持つことにより読み取り可能な部分のみを解釈して画像表示を行う仕様であれば、後部に読み取り不可能なデータが存在しても構わないため、余剰領域の削除は省略可能である。この省略は、実用的には記録媒体（本実施例ではＲＭ２６）の容量が十分な場合に可能である。

ステップＳ３０ではファイルクローズを行う。つまりファイル編集システム４０はファイルシステムに対してCLOSEを発行して処理を終了する。このCLOSEを受け付けたファイルシステムの制御部３１は、ＦＡＴ管理部３２のＦＡＴを参照してファイル管理部内の空き領域を探索してバッファ３３の仮ファイルをファイル管理部３５の引き当てた空き領域に書き込む（保存する）。そしてＦＡＴにファイルの格納位置を書き込んで更新する。すなわち余剰領域の削除された仮ファイルがＲＭ２６に書き込まれる。すなわち図４（ｆ）および図５（ｅ）に示すように全領域に新ファイルが記録された（無駄なデータの記載されていない）仮ファイル（ｋバイト）がメモリに記録される。以上、ステップＳ２４、Ｓ２６、Ｓ２８、Ｓ３０、Ｓ３２、３４の処理を実行するファイル編集システム４０が書込手段を構成する。

以上より、SEEK処理の発生する可能性のあるステップＳ２４のデータ書込み中およびステップＳ２８の余剰領域削除中は、仮ファイル領域内に対するSEEK処理を確実に行うことのできるファイル編集システムを提供することができる。また、予め処理後のファイル容量を計算して仮ファイルを作成するため、ステップＳ３２〜Ｓ３４で領域を追加する必要が発生することは稀であり、ファイル開き直し回数はステップＳ２２の一回だけと効率的になり処理時間を短縮することができる。また仮ファイルの容量が不足しても、予め各処理のアルゴリズムに基いて仮ファイルを作成しているため領域追加の回数は少なくてすむ。

またアルゴリズムの大幅な変更を伴わない他のデータ処理として、例えばアプリケーションに以下の変更を行うことも考えられる。すなわち、ファイル書込み時に追加部分へのSEEKが可能なファイルシステムであるか否かを判断し、さらにこのファイル書込みが使い部分への書込みであるか否かを判断する。そして追加部分へのSEEK不可能であり、かつ拡張部分への書込みである場合は、書き込み後にファイルの開きなおしをする。但し、このアルゴリズムではファイル書込みが発生するたびに判断する処理を行うことに加えて追加部分への書込みでは書き込むたびにファイルが開き直されるため、段落００２５から段落００４０に記載のデータ処理に比べて処理効率が劣り、処理時間の増加が避けられない。

なお、本発明は、上述した実施形態や変形例に限られず、上述した実施形態および変形例の中で開示した各構成を相互に置換したり組み合わせを変更したりした構成、公知技術並びに上述した実施形態および変形例の中で開示した各構成を相互に置換したり組み合わせを変更したりした構成、等も含まれる。

本実施形態に係る携帯電話機の外観を示す正面図である。 携帯電話機の電気的構成を示すブロック図である。 携帯電話機に構築される機能ブロック図である。 ファイル構造の説明図である。 ファイル構造の説明図である。 ファイル編集システムのデータ処理を示すフローチャートである。 従来の、追記部分へのSEEK不可能なファイルシステムを説明する図である。

符号の説明

１０…携帯電話機 １０ａ…操作部 １０ｂ…カバー部 １１…操作キー １５…表示部
２１…ＣＰＵ ２２…ＲＯＭ ２３…ＲＡＭ ２４…通信部 ２５…Removable Memory I/F（ＲＭＩＦ） ２６…Removable Memory（ＲＭ）
３０…ファイルシステム ３１…制御部 ３２…ＦＡＴ管理部 ３３…バッファ ３５…ファイル管理部 ４０…ファイル編集システム ４１…入力制御部 ４２…ファイル要求部 ４３…編集処理部 ４４…変換テーブル

Claims (8)

1. 各種の指示を受け付け、同指示に対応するファイル処理を実行するファイルシステムに対し、上記指示を出して所定のデータ処理を実現するファイル処理装置であって、
   ファイルに対する所定のデータ処理が開始されると、所定のファイル容量を持つ仮ファイルの作成を上記ファイルシステムに対して指示する仮ファイル作成手段と、
   上記ファイルシステムに対して同仮ファイルをクローズした後、オープンさせる指示を出す開き直し手段と、
   上記所定のファイル処理の結果を上記開き直された仮ファイルに対して書き込む指示を出し、この書き込み処理後に同仮ファイルをクローズする指示を出す書込手段と、を備えることを特徴とするファイル処理装置。
2. 上記所定のファイル容量は、上記データ処理のアルゴリズムに基づいて、該データ処理後のデータを格納するのに十分と想定される容量であることを特徴とする上記請求項１に記載のファイル処理装置。
3. 各データ処理において作成すべき仮ファイルの容量が定義されたテーブルを備えることを特徴とする上記請求項１または請求項２に記載のファイル処理装置。
4. 各処理の前後で変化するファイル容量の変化率を示す情報を有し、該情報に基づいてファイル容量の変化を計算する計算手段を備えることを特徴とする上記請求項１〜請求項３のいずれかに記載のファイル処理装置。
5. 上記書込手段は、書き込み中に上記仮ファイルの容量が不足すると所定容量の追加を指示した後、上記開き直し手段に該仮ファイルのクローズとオープンとを順に指示させてから書き込みを続行することを特徴とする上記請求項１〜請求項４のいずれかに記載のファイル処理装置。
6. 上記書込手段は、上記仮ファイルをクローズする前に、該仮ファイルの余剰領域の無効化を指示することを特徴とする上記請求項１〜請求項５のいずれかに記載のファイル処理装置。
7. 各種の指示を受け付け、同指示に対応するファイル処理を実行するファイルシステムに対し、上記指示を出して所定のデータ処理を実現するファイル処理方法であって、
   ファイルに対する所定のデータ処理が開始されると、所定のファイル容量を持つ仮ファイルの作成を上記ファイルシステムに対して指示する仮ファイル作成工程と、
   上記ファイルシステムに対して同仮ファイルをクローズした後、オープンさせる指示を出す開き直し工程と、
   上記所定のファイル処理の結果を上記開き直された仮ファイルに対して書き込む指示を出し、この書き込み処理後に同仮ファイルをクローズする指示を出す書込工程と、を備えることを特徴とするファイル処理方法。
8. 各種の指示を受け付け、同指示に対応するファイル処理を実行するファイルシステムに対し、上記指示を出して所定のデータ処理を実現するファイル処理プログラムであって、
   ファイルに対する所定のデータ処理が開始されると、所定のファイル容量を持つ仮ファイルの作成を上記ファイルシステムに対して指示する仮ファイル作成機能と、
   上記ファイルシステムに対して同仮ファイルをクローズした後、オープンさせる指示を出す開き直し機能と、
   上記所定のファイル処理の結果を上記開き直された仮ファイルに対して書き込む指示を出し、この書き込み処理後に同仮ファイルをクローズする指示を出す書込機能と、をコンピュータに実現させることを特徴とするファイル処理プログラム。

Images