(57)【要約】【課題】ファイルを効率よく保存可能な情報処理装置、ファイル管理方法、およびファイル管理プログラムを提供する。【解決手段】ファイルを格納可能な記憶部を備えた情報処理装置であって、ファイルを識別するためのファイル識別情報に基づいてファイルを格納するディレクトリを定めたパス情報を生成し、生成したパス情報を圧縮した圧縮パス情報を生成するファイルパス生成部と、ファイルパス生成部によって生成された圧縮パス情報に基づいて、ファイルを記憶部に格納させるファイル配置部と、を備える。【選択図】図７
2012038071.tif 000002
【特許請求の範囲】
【請求項１】
ファイルを格納可能な記憶部を備えた情報処理装置であって、
前記ファイルを識別するためのファイル識別情報に基づいて前記ファイルを格納するディレクトリを定めたパス情報を生成し、生成した前記パス情報を圧縮した圧縮パス情報を生成するファイルパス生成部と、
前記ファイルパス生成部によって生成された前記圧縮パス情報に基づいて、前記ファイルを前記記憶部に格納させるファイル配置部と、
を備えたことを特徴とする情報処理装置。
【請求項２】
前記ファイルパス生成部は、前記ファイル識別情報と前記圧縮パス情報とを含むファイル管理用データを、前記ファイルとは別に前記記憶部に記憶させる、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記ファイルパス生成部は、ランレングス圧縮により、前記パス情報から前記圧縮パス情報を生成する、
ことを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記ファイルパス生成部は、前記パス情報から前記圧縮パス情報を生成する際に、連続する文字列が圧縮して効果がある文字数であるか否かを判定し、前記文字数が圧縮して効果がある文字数である場合にのみ、前記文字列を圧縮する、
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記ファイルパス生成部は、連続する前記文字列を、連続する前記文字列を構成する文字と前記文字とは異なる識別符号とを含めて前記圧縮パス情報を生成する、
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記ファイルパス生成部は、前記文字と前記識別符号とを含めて前記圧縮パス情報を生成する場合において、連続する前記文字列が４文字以上の場合に、前記文字数が圧縮して効果がある文字数であると判定する、
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
ファイルを格納可能な記憶部を備えた情報処理装置で行われるファイル管理方法であって、
前記ファイルを識別するためのファイル識別情報に基づいて前記ファイルを格納するディレクトリを定めたパス情報を生成するファイルパス生成ステップと、
生成された前記パス情報を圧縮した圧縮パス情報を生成する圧縮ファイルパス生成ステップと、
前記圧縮ファイルパス生成ステップにおいて生成された前記圧縮パス情報に基づいて、前記ファイルを前記記憶部に格納させるファイル配置部ステップと、
を有することを特徴とするファイル管理方法。
【請求項８】
コンピュータに、
ファイルを格納可能な記憶部を備えた情報処理装置に格納される前記ファイルを識別するためのファイル識別情報に基づいて前記ファイルを格納するディレクトリを定めたパス情報を生成するファイルパス生成ステップと、
生成された前記パス情報を圧縮した圧縮パス情報を生成する圧縮ファイルパス生成ステップと、
前記圧縮ファイルパス生成ステップにおいて生成された前記圧縮パス情報に基づいて、前記ファイルを前記記憶部に格納させるファイル配置部ステップと、
を実行させることを特徴とするファイル管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＳ（Operating  System）等のファイルシステムに保存されたファイルを管理する情報処理装置、ファイル管理方法、およびファイル管理プログラムに関するものである。
【背景技術】
【０００２】
従来、例えば、ユーザが作成したファイルをファイルシステム上に保存し、保存されたファイルを管理する場合、ファイルシステムが管理しているツリー情報（ファイル管理情報）と同様にファイルに関するツリーを作成するか、あるいは個々のファイルを一意に識別するためのＩＤ（IDentification）等の識別符号をファイルシステム上に作成し、作成したＩＤ毎にファイルを配置することによって、個々のファイルを管理している。このように、ファイルシステム上に直接ファイルを配置し、ＩＤ等の識別情報によってファイルを管理する場合、ファイルを保管するサーバやストレージ等の装置には大量のファイルが作成される。
【０００３】
一般に、１つのディレクトリやフォルダ内に保存できるファイルの上限はファイルシステムによって異なるが、１ディレクトリ等に大量のファイルを保存した場合、ディレクトリ等の一覧を表示させる速度等が遅延する等の性能に影響する為、１ディレクトリ内のファイルやフォルダ数は少ない事が望ましい。このような現象を防ぐために、大量のファイルを利用する場合、ディレクトリ等を階層化してデータを分散して保持する等の何らかの対応が必要となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−０５９２２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した方法によってディレクトリ等を作成してファイルを分散して保存する場合、例えば、ファイルＩＤを含むようなディレクトリ（フォルダ）を作成し、作成したディレクトリ（フォルダ）１つに対して１つのファイルを保存する方式が考えられる。この保存方式の場合、保存可能なファイル数（ファイルＩＤの上限等）以上のディレクトリ（フォルダ）が作成され、本来保存すべきファイルに対するバックアップの処理時間以外に、ファイルの保存を分散させる為に作成したディレクトリ（フォルダ）に対してのバックアップ処理に時間がかかったり、あるいは複数階層を管理するためのメモリ消費が必要となる結果、メモリ使用率が高くなる等、サーバリソースの観点から効率的な利用が出来ないという問題があった。
【０００６】
本発明は、上記に鑑みてなされたものであって、ファイルを効率よく保存可能な情報処理装置、ファイル管理方法、およびファイル管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明にかかる情報処理装置は、ファイルを格納可能な記憶部を備えた情報処理装置であって、前記ファイルを識別するためのファイル識別情報に基づいて前記ファイルを格納するディレクトリを定めたパス情報を生成し、生成した前記パス情報を圧縮した圧縮パス情報を生成するファイルパス生成部と、前記ファイルパス生成部によって生成された前記圧縮パス情報に基づいて、前記ファイルを前記記憶部に格納させるファイル配置部と、を備えたことを特徴とする。
【０００８】
また、本発明は、上記情報処理装置で実行されるファイル管理方法、およびファイル管理プログラムである。
【発明の効果】
【０００９】
本発明によれば、ファイルを効率よく保存可能な情報処理装置、ファイル管理方法、およびファイル管理プログラムを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本実施の形態にかかるファイルシステムの機能的な構成を示す図である。
【図２】ファイルの管理用データの例を示す図である。
【図３】ファイル格納処理の処理手順を示すシーケンス図である。
【図４】ファイル取得処理の処理手順を示すシーケンス図である。
【図５】従来の方法によってファイルを保存する場合のファイル保存方法の例を示す図である。
【図６】本実施の形態における方法によってファイルを保存する場合のファイル保存方法の例を示す図である。
【図７】ファイルパス生成部がファイルパスを生成する処理の処理手順を示すフローチャートである。
【図８】図７に示した桁数格納処理の処理手順を示すフローチャートである。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照して、本発明にかかるファイル管理システムの実施の形態を詳細に説明する。
[ファイル管理システムにおけるファイル管理方法の概念]
図１は、本実施の形態にかかるファイルシステム１０００の機能的な構成を示す図である。図１に示すように、ファイルシステム１０００は、クライアント１１０と、ネットワーク１１５と、ファイル管理システム１０１とを含んで構成されている。
【００１２】
クライアント１１０は、ＰＣ（Personal  Computer）等の一般的な情報処理装置であり、送信部１１１と、受信部１１２とを有している。なお、以下では特に説明していないが、実際にはＣＰＵ（Central  Processing  Unit）等の演算装置、ＲＡＭ（Random  Access  Memory）やＲＯＭ（Read  Only  Memory）等の記憶媒体、ユーザからファイルの指定等を受け付けるキーボード等の入力装置、入力装置から入力された種々の情報を表示するディスプレイ等の表示装置を備えているものとする。なお、ネットワーク１１５は、インターネット等の一般的な公衆回線網である。
【００１３】
ファイル管理システム１０１は、ユーザからの要求に応じて、ファイルのアップロードやダウンロードをするものである。具体的には、クライアント１１０上に存在するファイル１７０を、クライアント１１０の送信部１１１がネットワーク１１５を通じてファイル管理システム１０１にアップロードしたり、もしくはクライアント１１０の受信部１１２がネットワーク１１５を通じてファイル管理システム１０１からダウンロードするシステムである。図１に示すように、ファイル管理システム１０１は、Web/APサーバ１２０と、ファイルサーバ１３０と、ストレージ１４０と、ＤＢ（Data  Base）サーバ１６０と、ローカルネットワーク１５０とを有している。ローカルネットワーク１５０は、ＬＡＮ（Local  Area  Network）等の一般的な構内通信網である。
【００１４】
なお、ファイル管理システム１０１が有するサーバの台数や役割分担については、特にこれに限らず、例えば、１台のサーバのみ、あるいは複数台のサーバに分けて構成することとしてもよい。また、ファイル管理システム１０１は、上記に述べたファイルのアップロード、ダウンロードのみではなく、その他機能を有していてもよい。上述した各種のサーバは、例えば、クライアント１１０と同様のＰＣやサーバ装置等の一般的な情報処理装置であり、実際にはＣＰＵ等の演算装置や記憶媒体等の各種装置を備えているものとする。
【００１５】
クライアント１１０の送信部１１１は、不図示の入力装置から入力されたファイル１７０のアップロード指示に従って、ファイル１７０をファイル管理システム１０１にアップロード（送信）する。また、クライアント１１０の受信部１１２は、不図示の入力装置から入力されたファイル１７０のダウンロード指示に従って、ファイル１７０をファイル管理システム１０１からダウンロード（受信）する。
【００１６】
ファイル１７０がファイル管理システム１０１にアップロードされる場合、クライアント１１０の送信部１１１は、ファイル管理システム１０１にファイル１７０を格納するためのファイル格納要求を行う。ファイル管理システム１０１にアップロードされたファイル１７０は、Web/APサーバ１２０内に配置されているデータ生成部１２１により、ファイル１７０に関する詳細データ（管理用データ）が生成される。この管理用データについては、図２を用いて、後述する[ファイル管理ＤＢテーブル]において具体的に説明する。
【００１７】
生成された管理用データは、ローカルネットワーク１５０内に配置されているＤＢサーバ１６０に格納される。また、ファイル１７０の本体は、ファイル取得部１２２がローカルネットワーク１５０内に配置されているファイルサーバ１３０にアクセスし、そのファイルサーバ１３０のデータ共有部１３１によって、上述した管理用データとは別に、ストレージ１４０内に保存される。この処理の詳細は、図３を用いて、後述する[ファイル格納時の処理シーケンス]において具体的に説明する。
【００１８】
一方、ファイル１７０がファイル管理システム１０１からダウンロードされる場合、クライアント１１０の受信部１１２は、ファイル管理システム１０１からファイル１７０を取得するためのファイル取得要求を行い、Web/APサーバ１２０のデータ生成部１２１は、ファイル取得要求に含まれるファイルＩＤをキーとして該当のファイル１７０を特定する。
【００１９】
そして、ファイルパス取得部１２２を構成するファイルパス生成部１２３が、そのファイル１７０にアクセスするまでのファイルパスを生成する。さらに、データ取得/配置部１２４は、ローカルネットワーク１５０内に存在するファイルサーバ１３０のデータ共有機能１３１を通じてストレージ１４０上のファイル１７０を取得する。取得したファイル１７０はWeb/APサーバ１２０の送信部１２１によってクライアント１１０に送信される。この処理の詳細は、図４を用いて、後述する[ファイル取得時の処理シーケンス]において具体的に説明する。
[ファイル管理ＤＢテーブル]
続いて、図１に示したＤＢサーバ１６０のファイル管理ＤＢ１６１について説明する。図１に示したファイル１７０が、クライアント１１０からファイル管理システム１０１にアップロードされた際に、Web/APサーバ１２０のデータ生成部１２１によって、ファイル１７０の管理用データが生成され、ＤＢサーバ１６０のファイル管理ＤＢ１６１に格納される。
【００２０】
図２は、上述したファイル１７０の管理用データの例を示す図である。管理用データは、ファイル管理ＤＢ１６１に、ファイル管理ＤＢデータテーブル２０１のレコードとして保存される。図２に示すように、管理用データは、ファイルＩＤ２０２と、ファイル名２０３と、保存ファイル名２０４と、作成日時２０５と、更新日時２０６と、アクセス日時２０７と、保持サーバＩＤ２０８と、保持ディスクＩＤ２０９と、保持ファイルパス２１０とを有している。なお、以下ではこれらの９つのデータが格納されている前提で説明しているが、保持するデータ数に限定されず、例えば、ユーザがファイル管理システム１０１に対するアクセス権に関する情報等の付加的な情報（ファイル情報）を含めて管理用データとして保持することも可能である。
【００２１】
ファイルＩＤ２０２は、ファイル１７０を一意に識別するための番号等の識別情報であり、ファイル１７０毎にユニークに与えられるものである。ファイル管理システム１０１上ではファイルはファイルＩＤ２０２によって管理されるが、以下では、このファイルＩＤ２０２は、ユーザがファイル１７０をアップロードする際に、あらかじめファイル１７０の属性情報等としてファイル１７０に設定されているものとする。また、ファイルＩＤの他、例えば、ファイル１７０に対する上述したファイル情報についても、ファイルＩＤ２０２と同様に、あらかじめ設定されているものとする。
【００２２】
ファイル名２０３は、ユーザがファイル１７０に対して付与したファイル名である。ファイル１７０がクライアント１１０にダウンロードされる際、Web/APサーバ１２０の送信部１２１はファイル１７０を送信し、クライアント１１０の受信部１１２がそのファイル１７０を受信した場合にファイル名２０３を付与され、不図示のメモリ等の記憶媒体に記憶される。
【００２３】
保存ファイル名２０４は、ファイル１７０がストレージ１４０に格納される際にファイル管理システム１０１のデータ生成部１２３がファイル１７０に対して付与するファイル名である。このように、保存ファイル名２０４をファイル名２０３と別に格納させる事により、ＯＳ等のファイル名、あるいはファイルパス長に制限されることはなく、ファイル管理システム１０１における他の種々の処理を行う際に、効率よく管理することが可能となる。
【００２４】
作成日時２０５は、ファイル１７０自体がユーザによって作成された日時である。また、更新日時２０６は、ファイル１７０自体がユーザによって更新された日時である。アクセス日時２０７は、ファイル１７０自体がユーザによってアクセスされた日時である。
【００２５】
保持サーバＩＤ２０８は、ファイル管理システム１０１を構成する各種のサーバを一意に識別するための識別情報である。また、保持ディスクＩＤ２０９は、各種のサーバが有するディスクを一意に識別するための識別情報である。保持サーバＩＤ２０８および保持ディスクＩＤ２０９は、保存ファイル名２０４と同様に、ファイル１７０がストレージ１４０に格納される際にファイル管理システム１０１のデータ生成部１２３によって付与される。
【００２６】
この保持サーバＩＤ２０８や保持ディスクＩＤ２０９は、例えば、ファイル管理システム１０１で保存するファイル１７０の数が多くなった場合に、サーバの負荷分散や負荷軽減をするためにファイルサーバ１３０を分割したり、あるいはファイルサーバ１３０の内部に保持されるディスクを分割・増設した場合に、ファイル１７０が保存されているサーバやディスクを特定するために利用される。
【００２７】
保持ファイルパス２１０は、ファイル管理システム１０１に保存されているファイル１７０のパス情報である。この保持ファイルパス２１０は、後述するように、ファイルパス生成部１２１によって生成される。ユーザがクライアント１１０からファイル１７０のファイル取得要求を行った場合、ファイル管理システム１０１のデータ取得／配置部１２４が、その時点で生成されていた保持ファイルパス２１０によってファイル１７０にアクセスして取得することとしても良いし、ファイルパス生成部１２３が、ユーザがクライアント１１０からファイル１７０を取得する際に、ファイルパス２１０を逐次生成してファイル１７０を取得することも可能である。以下では、後者の方法によってファイルパス２１０が生成される場合について説明している。
[ファイル格納時の処理シーケンス]
続いて、クライアント１１０がファイル１７０をファイル管理システム１０１にアップロードする場合のファイル格納処理について説明する。図３は、ファイル格納処理の処理手順を示すシーケンス図である。
【００２８】
図３に示すように、まず、クライアント１１０は、ユーザからファイル１７０の格納要求と、ファイル管理システム１０１に格納すべきファイル１７０とを受け付けると、送信部１１１が、受け付けられたファイル１７０をWeb/APサーバ１２０に送信する（ステップＳ３０１）。
【００２９】
その後、Web/APサーバ１２０の受信部１２２は、クライアント１１０から送信されたファイル１７０を受信し（ステップＳ３１１）、データ生成部１２１は、受信されたファイル１７０の管理用データを生成する（ステップＳ３１２）。
【００３０】
例えば、データ生成部１２１は、ファイルＩＤが「００００１」、ファイル名が「ＡＢＣ」、作成日時、更新日時、アクセス日時が、それぞれ「２０１０／０７／０１  １５：００」「２０１０／０７／０２  １６：００」「２０１０／０７／０３  １７：００」であるファイル１７０が受信された場合、そのファイルＩＤ「００００１」を、図２に示したファイルＩＤ２０２に設定し、ファイル名「ＡＢＣ」をファイル名２０３に設定し、作成日時「２０１０／０７／０１  １５：００」を作成日時２０５に設定し、更新日時「２０１０／０７／０２  １６：００」を更新日時２０６に設定し、アクセス日時「２０１０／０７／０３  １７：００」をアクセス日時２０７に設定する。このとき、データ生成部１２１は、例えば、保存ファイル名として「ＳＹＳ−ＡＢＣ」を付与し、保存ファイル名２０２に設定する。なお、管理用データが有する項目のうち、保持サーバＩＤ２０８、保持ディスクＩＤ２０９、保持ファイルパス２１０は、あらかじめ管理者等によって定められた内容（ＩＤやフォルダ名等）が設定されるものとする。
【００３１】
その後、データ生成部１２１は、生成した管理用データをファイル管理ＤＢ１６１の所定のフォルダに格納する（ステップＳ３１３、Ｓ３２１）。そして、ファイルパス生成部１２３は、格納された管理用データにアクセスしてその内容を参照し（ステップＳ３１４、Ｓ３２２）、ファイル１７０のファイルパスを生成する（ステップＳ３１５）。このステップＳ３１５の具体的な処理については、図７を用いて後述する。
【００３２】
その後、データ取得／配置部１２４は、生成されたファイルパスに従ってファイル１７０をファイルサーバ１３０に送信し（ステップＳ３１６）、ファイルサーバ１３０のデータ共有部１３１が、受信したファイルをストレージ１４０のストレージ内に格納する（ステップＳ３３１、Ｓ３４１）。このステップＳ３４１の処理が終了すると、図３に示した全ての処理が終了する。
[ファイル取得時の処理シーケンス]
続いて、クライアント１１０がファイル１７０をファイル管理システム１０１からダウンロードする場合のファイル取得処理について説明する。図４は、ファイル取得処理の処理手順を示すシーケンス図である。
【００３３】
図４に示すように、まず、クライアント１１０は、ユーザからファイル１７０の取得要求と、ファイル管理システム１０１に格納されたファイル１７０のファイルＩＤ２０２とを受け付けると、送信部１１１が、受け付けられたファイルＩＤ２０２をWeb/APサーバ１２０に送信する（ステップＳ４０１）。
【００３４】
Web/APサーバ１２０の受信部１２２は、クライアント１１０からファイルＩＤ２０２を受信することにより、ファイル１７０の取得要求を受け付ける（ステップＳ４１１）。そして、ファイルパス生成部１２３は、ファイルＩＤ２０２をキーとしてファイル管理ＤＢ１６１にアクセスし、そのファイルＩＤ２０２に一致する管理用データを参照する（ステップＳ３１４、Ｓ３２１）。
【００３５】
その後、ファイルパス生成部１２３は、参照した管理用データに含まれるファイルＩＤ２０２と、保持サーバＩＤ２０８と、保持ディスクＩＤ２０９とから、受信したファイルＩＤ２０２のファイル１７０が格納されている場所までのファイルパスを生成する（ステップＳ３１５）。このステップＳ３１５の具体的な処理については、図７を用いて後述する。
【００３６】
そして、データ取得／配置部１２４は、生成されたパスに従ってファイルサーバ１３０にアクセスし（ステップＳ４１２）、ファイルサーバ１３０のデータ共有部１３１が、データ取得／配置部１２４からのアクセスを受けて、生成されたパスに格納されているファイル１７０を取得し、さらに、データ取得／配置部１２４は、そのファイル１７０を取得する（ステップＳ３３１、Ｓ３４１）。
【００３７】
その後、送信部１２１は、取得されたファイル１７０をクライアント１１０に送信し（ステップＳ４１３）、クライアント１１０の受信部１１２は、Web/APサーバ１２０から送信されたファイル１７０を受信する（ステップＳ４０１）。このステップＳ４０２の処理が終了すると、図４に示した全ての処理が終了する。
【００３８】
図３、図４（および後述する図７）に示した処理を行うことによって、ファイルサーバ１３０が管理するメモリや、ストレージ１４０上のファイルバックアップの時間が低減され、ファイルの保存効率が上がる。
【００３９】
図５は、従来の方法によってファイル１７０を保存する場合のファイル保存方法の例を示す図である。図５に示すように、従来の方法によってファイルを保存する場合、所定の桁数（ＸＸ桁）のファイルＩＤ２０２が、所定の桁数（ＹＹ桁）に区切られ、区切られたＹＹ桁の値が、ディレクトリ名（フォルダ名）として付与される。従って、例えば、ファイル１７０のファイルＩＤ２０２が「１２３４５６７８９０ＡＢＣＤ」である場合、ファイルパスは、Ｗｉｎｄｏｗｓ（登録商標）の場合「￥１２￥３４￥５６￥７８￥９０￥ＡＢ￥ＣＤ」となり、ＵＮＩＸ（登録商標）やＬｉｎｕｘの場合「／１２／３４／５６／７８／９０／ＡＢ／ＣＤ」となる。そして、最下位のフォルダの直下にファイル１７０が格納される。
【００４０】
なお、図５では、ファイル１７０が格納されているストレージ１４０は、ファイルサーバ１３０からマウントされ、ファイル１７０はデータ共有部１３１にて共有されている場合について示しているが、ストレージ１４０自身にデータ共有機能１３１のインターフェースがある場合は、直接共有されても構わない。
【００４１】
すなわち、従来の方法では、ファイルサーバ１３０上で管理され、保存されているファイル１７０は、ファイルＩＤ２０２を複数桁に分けた文字列（ＹＹ桁）５０１毎に分けて階層化され、ファイル１７０は決められた保存ファイル名２０４にて最下層のフォルダに格納される。この処理において、最下層のフォルダに入っているのはファイル１７０のみとなり、ファイルＩＤ２０２から作成されたパスには該当のファイル１７０が格納されていることとなる。
【００４２】
図６は、本実施の形態における方法によってファイル１７０を保存する場合のファイル保存方法の例を示す図である。図６に示すように、ファイル１７０を保存する方法は、図５に示した場合と同様であるが、ファイルパスの生成時にファイルＩＤ２０２を圧縮することにより、保存するフォルダの階層を低減している。圧縮された後のファイルＩＤ６０１（ＺＺ桁）は、ファイルＩＤ２０２と同様にユニーク性は保っている為、該当パス配下にあるファイル１７０は、ファイルＩＤ２０２に紐づくファイルのみとなる。これにより、図５に示した従来の方法に比べ、ディレクトリ（フォルダ）自体の数を減らすことが出来る。ファイルＩＤ２０２を圧縮する方法は、例えば、連長圧縮（ランレングス圧縮）を行うことによって実現できる。この具体的な方法は図７を用いて後述するが、連続した数値や文字列が存在した場合にのみ、特殊記号の後に１桁の数値でその連長を表現している。
[ファイルパス生成ロジック処理フロー]
続いて、ファイルパス生成部１２３が行うファイルパス生成処理について説明する。図７は、ファイルパス生成部１２３がファイルパスを生成する処理の処理手順を示すフローチャートである。以下に示すように、ファイルパス生成部１２３が行う処理は、ファイル１７０のユニークなコード（ファイルＩＤ２０２）を一定の桁数で区切り、それぞれをディレクトリ（フォルダ）の階層としたパスを生成する処理である。
【００４３】
図７に示すように、まず、ファイルパス生成部１２３は、ファイルパスを生成するにあたり、その前処理として処理対象となるファイル１７０のファイル情報（例えば、ファイルＩＤ２０２の他、ファイル１７０に対するアクセス権等を含むファイル１７０に関する種々の情報）を取得して読み取り（ステップＳ７０１）、読み取ったファイル情報の中からファイルＩＤ２０２を読み取る（ステップＳ７０２）。
【００４４】
そして、ファイルパス生成部１２３は、読み取ったファイルＩＤ２０２のうち、同一の文字列となっている箇所を全ての桁についてチェックしたか否かを判定する（ステップＳ７０３）。ファイルパス生成部１２３は、同一の文字列となっている箇所を全ての桁についてチェックしたと判定した場合（ステップＳ７０３；Ｙｅｓ）、ステップＳ７１６に進む。
【００４５】
このように、ファイルパス生成部１２３が同一の文字列をチェックする理由は、ファイルパスを圧縮するにあたり、同一の文字列を利用している箇所を特定する必要があるためである。なお、以下では、ファイルパスを圧縮する方法の一例として、ランレングス圧縮を用いた場合について説明しているが、特にこの方法に限定されることはなく、桁数を圧縮することが可能であれば、従来から知られている種々の方法を用いることができる。
【００４６】
一方、ファイルパス生成部１２３は、同一の文字列となっている箇所を全ての桁についてチェックしていないと判定した場合（ステップＳ７０３；Ｎｏ）、ファイルＩＤの桁数を確認し、２桁目以降であるか否かを判定し、そのひとつ前の桁の値と同一否かチェックをする（ステップＳ７０４）。なお、ファイルＩＤの桁数が２桁目以降ではない（最初のケタである）と判定した場合（ステップＳ７０４；Ｎｏ）、チェックせずに再び桁数の確認を行う。
【００４７】
一方、ファイルパス生成部１２３は、ファイルＩＤの桁数が２桁目以降である（最初のケタではない）と判定した場合（ステップＳ７０４；Ｙｅｓ）、処理桁、前桁、および前々桁の文字列を取得する（ステップＳ７０５）。なお、処理している桁が２桁目の場合は、前々文字が存在しないため、前々文字は格納しない。
【００４８】
ファイルパス生成部１２３は、処理桁、前桁、および前々桁の文字列を取得すると、前桁と処理桁の文字列を比較し、同じ文字列であるか否かを判定する（ステップＳ７０６）。そして、ファイルパス生成部１２３は、前桁と処理桁の文字列が同じ文字列であると判定した場合（ステップＳ７０６；Ｙｅｓ）、ファイルＩＤ２０２内に連続した文字列があると判定し、さらに、前々桁と処理桁の文字列を比較し、両者が同一であるか否かを判定する（ステップＳ７０７）。
【００４９】
そして、ファイルパス生成部１２３は、前々桁と処理桁の文字列が同一であると判定した場合（ステップＳ７０７；Ｙｅｓ）、連続している文字が後続の桁にもある可能性がある為、連続文字数をカウントアップして保持する（ステップＳ７０８）。
【００５０】
一方、ファイルパス生成部１２３は、前々桁と処理桁の文字列が同一でないと判定した場合（ステップＳ７０７；Ｎｏ）、前桁を連続文字開始桁として格納７１２し（ステップＳ７０９）、連続文字数をカウントアップして保持する（ステップＳ７１０）。この理由は、連続文字数を加算（＋１）するにあたり、どの桁数から連続しているかを記憶する必要があるためであり、前々桁と処理桁が違う、または前々桁が無い、すなわち２桁目の場合には前桁から連続する文字列が始まっている為である。
【００５１】
その後、ファイルパス生成部１２３は、現在の処理桁が最終桁であるか否かを判定し（ステップＳ７１１）、現在の処理桁が最終桁であると判定した場合（ステップＳ７１１；Ｙｅｓ）、最終桁まで連続している文字列がある為、桁数圧縮処理を行う（ステップＳ７１２）。この桁数圧縮処理の詳細については後述する。
【００５２】
一方、ファイルパス生成部１２３は、現在の処理桁が最終桁ではないと判定した場合（ステップＳ７１１；Ｎｏ）、ステップＳ７０３に戻って、ステップＳ７０３以降の処理を繰り返す。
【００５３】
ステップＳ７０６において、ファイルパス生成部１２３が、前桁と処理桁の文字列が同じ文字列ではないと判定した場合（ステップＳ７０６；Ｎｏ）、連続開始桁数として値が格納されているか否か判定する（ステップＳ７１３）。ファイルパス生成部１２３が、このような判定を行う理由は、ファイルＩＤ２０２に連続した文字列が無い、もしくは前桁まで文字列が連続していたが、その連続が途切れた状態であるか否かを判定するためである。
【００５４】
そして、ファイルパス生成部１２３は、連続開始桁数として値が格納されていると判定した場合（ステップＳ７１３；Ｙｅｓ）、上述した桁数圧縮処理を行い（ステップＳ７１２）、連続文字数と連続開始桁をクリアし（ステップＳ７１５）、ステップＳ７０３に戻り、以降の処理を繰り返す。
【００５５】
一方、ファイルパス生成部１２３は、連続開始桁数として値が格納されていないと判定した場合（ステップＳ７１３；Ｎｏ）、連続した文字列が無く次の桁の確認処理に移るため、何もせずにステップＳ７０３に戻り、以降の処理を繰り返す。
【００５６】
そして、ファイルパス生成部１２３は、ステップＳ７０３において、同一の文字列となっている箇所を全ての桁についてチェックしたと判定した場合（ステップＳ７０３；Ｙｅｓ）、圧縮処理が行われた後のファイルＩＤ２０２を取得し（ステップＳ７１６）、取得した圧縮後のファイルＩＤ２０２を所定の桁数（例えば２桁）ずつ区切り、ファイルパス（階層）２１０を作成する（ステップＳ７１７）。
【００５７】
その後、ファイルパス生成部１２３は、そのファイルＩＤ２０２が格納されている保持サーバＩＤ２０８、保持ディスクＩＤ２０９から、取得するファイルパス２１０を生成し（ステップＳ７１９）、生成したファイルパス２１０を、データ取得／配置部に引き渡す（ステップＳ７１９）。このステップＳ７１９の処理が終了すると、図７に示した全ての処理が終了する。なお、図７に示した例では、ファイル情報とは別にファイルパス２１０を生成した場合について説明したが、ファイル情報にファイルパス２１０を含めて格納させることとしても良い。
【００５８】
続いて、図７に示した桁数格納処理について説明する。図８は、桁数格納処理の処理手順を示すフローチャートである。
【００５９】
図８に示すように、桁数圧縮処理では、まず、ファイルパス生成部１２３は、連続文字数を確認し、圧縮して効果がある連続数（４文字以上）であるか、または圧縮しても効果が無い連続数（３文字以内）であるか判定する（ステップＳ８０１）。そして、ファイルパス生成部１２３は、連続文字列や数値を圧縮して効果がある連続数（４文字以上）であると判定した場合（ステップＳ７１３；Ｙｅｓ）、連続文字開始桁の次の桁から連続文字数桁分の文字列を「＠(連続文字数)」に置換する（ステップＳ８０２）。ここで、圧縮して効果のある文字数を、上述したように連続数が４文字以上であるか否かを基準として判定している理由は、連続する桁数分の文字列を「＠」（１文字）に置換しているため、少なくとも４文字以上でなければ、文字列が圧縮前と同数となるためである。
【００６０】
例えば、ファイルパス生成部１２３は、ファイルＩＤ２０２が「５１３５５５５７」(８桁)である場合、圧縮後のファイルＩＤ２０２は「５１３５＠４７」(７桁)となる。このように、圧縮する部分の文字列として「＠」を用いた場合、圧縮の効果がある連続文字数が３文字から４文字となり、その効率が落ちる。しかし、圧縮箇所を明確にし、ファイルＩＤ２０２のユニーク性を保つ為に必要な文字列となる。
【００６１】
例えば、ファイルＩＤ２０２が、「５１３５５５７」、「５１１１５３７」(７桁)である２つのファイルＩＤ２０２を考えた場合、特別文字「＠」を利用せずに連続文字列のみを用いた場合、これらの２つのファイルＩＤ２０２は、いずれも「５１３５３７」(６桁)となってしまう。このような不具合を避けるために、ここでは「＠」を用いることによって、圧縮後のファイルＩＤ２０２を、それぞれ「５１３５＠３７」、「５１＠３５３７」(７桁)として、共にユニーク性を保つことができるようになっている。
【００６２】
なお、上述した例では、連続する桁数分の文字列を「＠」（１文字）に置換した場合について説明したが、ファイルＩＤ２０２に利用されない特別な文字であれば、これに限定されず種々の文字列等を用いることが出来る。
【００６３】
このように、ファイルを格納可能な記憶部を備えたファイル管理システム１０００において、ファイルパス生成部１２３が、ファイル１７０を識別するためのファイルＩＤ２０２に基づいてファイル１７０を格納するディレクトリを定めたファイルパスを生成し、生成したファイルパスを圧縮した圧縮後のファイルパス（保持ファイルパス２１０）を生成し、データ取得／配置部１２４が、ファイルパス生成部１２３によって生成された圧縮後のファイルパス（保持ファイルパス２１０）に基づいて、ファイル１７０をファイル管理システム１０００に含まれるストレージ１４０に格納させるので、ファイルを効率よく保存することが可能となる。
【００６４】
例えば、圧縮されたファイルパスは、通常のファイルパスよりも短く（階層が浅く）なっているため、作成されるフォルダ数が減少し、サーバのリソースの消費を低減し、バックアップ処理の時間を低減する事ができ、Ｗｉｎｄｏｗｓ  ＭＦＴ（Master  File  Table）の抑制や、Ｕｎｉｘ  ｉｎｏｄｅの抑制も可能となる。すなわち、ファイルＩＤ２０２と一対一のディレクトリ（フォルダ）の階層を作成する場合において、ファイルＩＤ２０２を可逆圧縮（ランレングス圧縮）することにより、ディレクトリ（フォルダ）の階層やその作成数を抑制することが可能となる。
【００６５】
なお、上述したクライアント１１０、Web/APサーバ１２０、ファイルサーバ１３０等の各種装置で実行される処理は、実際にはプログラムが実行されることによって、これらの各機能が実現され、そのプログラムは、例えば、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【００６６】
また、本実施の形態のプログラムは、上述した各部（データ生成部、ファイルパス生成部、データ取得／配置部等）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵが上記記録媒体からプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、データ生成部、ファイルパス生成部、データ取得／配置部等が主記憶装置上に生成されるようになっている。
【００６７】
なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。
【符号の説明】
【００６８】
１０００  ファイルシステム
１０１  ファイル管理システム
１２０  Web/APサーバ
１２１  送信部（Web/APサーバ）
１２２  受信部（Web/APサーバ）
１２１  データ生成部
１２２ファイル取得部
１２３  ファイルパス生成部
１２４  データ取得／配置部
１３０  ファイルサーバ
１３１  データ共有部
１４０  ストレージ
１５０  ローカルネットワーク
１６０  ＤＢサーバ
１６１  ファイル管理ＤＢ
１１０  クライアント
１１１  送信部（クライアント）
１１２  受信部（クライアント）
１１５  ネットワーク。
【図１】
2012038071.tif 000003
【図２】
2012038071.tif 000004
【図３】
2012038071.tif 000005
【図４】
2012038071.tif 000006
【図５】
2012038071.tif 000007
【図６】
2012038071.tif 000008
【図７】
2012038071.tif 000009
【図８】
2012038071.tif 000010