此，期望元数据的数据大小尽可能地小。
[0070]然而，如以上所描述的，当在间接块的项目中存在大量空(null)数据时，也在存储器中扩展这些空数据，从而减少存储器空间。在游戏软件70包括多于10000个文件的情况下，具体地，当准备了针对每个文件的索引表时，包括空数据的元数据可能会超过IG字节。
[0071]图8示出游戏数据的数据结构的参照示例。通过向包括多个(例如，10000个)游戏文件的游戏数据区域202添加包括超级块、1-节点列表、以及多个(N个)间接块的元数据区域200，来获得本参照示例中所示的数据结构。超级块已经在其中记录了用于管理在游戏数据区域202中包括的文件的信息，并且包括诸如块大小、块的总数目等的元数据。i_节点列表包括数目至少等于在游戏数据区域202中包括的文件的数目(例如，10000个)的1-节点。(顺便提及，为了精确起见，在这一文件系统中，也将目录和文件名当作一个文件，于是，1-节点列表还包括与目录和文件名相关的i_节点)。
[0072]为那些不能够在i_节点的12个项目中登记其数据块的文件提供间接块。在本参照示例中，如已经描述的，间接块和i_节点的项目包括块编号和在数据块中包括的数据的哈希值。
[0073]因此，当游戏数据区域202包括10000个文件时，存在着大量间接块。在某些间接块中，大多数项目可能包括空数据，如以上所描述的。于是，元数据区域200的数据大小变得不必要的大。在游戏程序的执行期间，从存储器的高效使用以扩展在存储器中的元数据区域200中包括的元数据的角度，这是所不希望的。
[0074]因此，本实施例中的游戏数据具有其中最小化了元数据的数据大小的数据结构，而非具有针对每一文件的每一块的哈希值的数据结构。具体地讲，创建了其中将无签名(哈希值)的多个文件汇总(lump)在一起的完全纯文本(plain text)图像文件,并且创建了通过向图像文件添加元数据所获得的游戏数据。顺便提及，图像文件指的是作为包括文件系统的结构、控制信息等的一个文件所形成的图像文件。
[0075]使用这一游戏数据的数据结构，将多个文件记录在记录介质上的连续的位置(块)中。于是，当将开始位置和文件大小作为元数据保存在i_节点的项目中时，可以标识每个文件的记录位置。因此，变得不需要具有用于标识每个数据块的记录位置(诸如块编号等)的信息。另外，由于不为每个数据块附加签名，所以变得不需要为每个数据块具有作为每个文件的元数据的哈希值。于是，可以将每个文件的元数据包含在i_节点的项目中。即，当不针对每个块生成哈希值、并且将数据块记录在连续编号的块中时，间接块显得不必要，因此可以显著减小元数据的数据大小。
[0076]图9是游戏数据创建方法的流程图。流程图中所示的步骤表示这样的过程:其中，游戏制造商创建了最终的游戏包(package)软件，并且通过包创建软件来实现这些步骤。首先，包创建软件创建纯文本游戏数据(无压缩、无加密、以及无签名)的图像文件(S10)。如已经描述的，将图像文件形成为包括文件系统的结构、控制信息等的一个文件。
[0077]图1OA示出本实施例中的游戏数据的完全纯文本图像文件的示例。图像文件210具有通过向包括多个(例如10000个)文件的游戏数据区域202添加包括超级块、i_节点列表、超级根目录、以及平路径表的元数据区域204所获得的数据结构。以下将描述超级根目录和平路径表。超级块在其中已经记录了用于管理在游戏数据区域202中包括的文件的信息，并且包括诸如块大小、块的总数目等的元数据。
[0078]将具有连续编号的逻辑块分配于在游戏数据区域202中包括的多个游戏文件。分配于在游戏数据区域202中包括的多个游戏文件的块的排列使得能够根据将文件分配于其的开始块编号和文件的数据大小来标识记录介质上的一个游戏文件的存储位置。因此，通过记录游戏文件的1-节点中的文件的开始块编号和文件的数据大小，来标识文件的记录位置。于是，当OS访问游戏文件时，通过获得游戏文件的i_节点编号，可以标识游戏文件的记录位置。
[0079]无签名被附加于在游戏数据区域202中记录的游戏文件。于是，不存在针对每个块的哈希值。因此，不需要准备用于记录文件的元数据的间接块，而可以将文件的元数据包含在i_节点的一个项目中。因此，元数据区域204中的i_节点列表包括数目等于游戏数据区域202中文件的数目的i_节点。另一方面，与图8进行比较可以清楚地看出，元数据区域204不包括与文件相关的多个间接块。顺便提及，如已经描述的，在这一文件系统中，也将目录和文件名当成一个文件。于是，i_节点列表也包括与目录和文件名相关的i_节点。然而，在这一情况下，未将签名附加于目录和文件名，使得不需要准备间接块。
[0080]与图8中所示的元数据区域200进行比较可以看出，能够显著减小图1OA中所示的元数据区域204的数据大小，因为元数据区域204不包括间接块。因此，即使当在游戏程序执行期间将在元数据区域204中包括的元数据读出到诸如DDR 3等的存储器中时，元数据也仅具有小的数据大小。
[0081]返回至图9，包创建软件压缩图1OA中所示的纯文本图像文件210(S12)。图1OB示出压缩图像文件的示例。包创建软件将具有连续编号的逻辑块分配于压缩图像文件212。在压缩图像文件212中，将指示压缩之前和压缩之后的文件的块之间的关系的压缩表写入至元数据区域204。在压缩表的头部分中描述该压缩之前的纯文本图像文件210的大小，并且在压缩表的表部分中互相关联地描述压缩之前的块编号、压缩之后的块编号、以及压缩之后的块编号的块中的位移位置。与游戏数据区域202的数据大小相比，这样的压缩减小了游戏数据区域206的数据大小。
[0082]可以将图1OA和图1OB中所示的图像文件210和212照原样用作游戏数据的图像文件。即，当信息处理设备10中的OS在用于执行游戏的预先确定的安装点(以下将将其安装点称为执行安装点)时安装了图像文件210或者212时，开启启动文件，以执行游戏程序。此时，可以在不包括间接块的情况下使元数据区域204的数据大小偏小，因此能够高效地在存储器中扩展元数据。
[0083]然而，未将签名附加于图像文件210和212。因此，存在着这样的缺点:当读出块的数据时，不能够验证数据，并且不能够有效地防止数据被篡改。于是，在本实施例中，将档案格式的图像文件212当作一个文件，附加签名，并且还进行加密以创建安全游戏数据。顺便提及，当对图像文件212施加签名和加密，以整体减小游戏数据的数据大小时，在进行压缩以创建安全游戏数据之前，可以对图像文件210施加签名和加密。
[0084]包创建软件将压缩图像文件212当作一个文件，并且向图像文件212分配具有连续编号的逻辑块。包创建软件将签名附加于构成压缩图像文件212的多个块中的每个块，或者具体地获得每一段块数据的哈希值，并且将签名作为元数据添加于图像文件212 (S14)。顺便提及，为了提高游戏数据的安全性，包创建软件可以将签名附加于所创建的元数据，并且还对游戏数据的元数据和主体进行加密处理。
[0085]图11示出根据本实施例的游戏数据的数据结构的示例。将具有这一数据结构的游戏数据作为包文件214记录在ROM介质44上，或者作为包文件214从内容服务器12或者商店服务器16下载至信息处理设备10，并且将其记录在辅助存储设备2上。
[0086]如图11中所示，包文件214具有其中嵌套了图像文件212的数据结构。通过将包括超级块、i_节点列表、多个(M个)间接块、超级根目录、以及平路径表的元数据区域208添加于被当作一个文件的图像文件212，来获得根据本实施例的数据结构。
[0087]超级块中已经记录了用于管理图像文件212的信息，并且包括诸如块大小、块的总数目等的元数据。将包括图像文件212的各块的哈希值的元数据记录在将1-节点包括在i_节点列表以及多个间接块中的图像文件212的i_节点的项目中，所述项目至少包括多个其数目等于对作为一个文件的图像文件212进行划分所获得的块的数目的项目。于是，使用通过如下方式所获得的数据结构形成包文件214:将包括至少附加于构成图像文件212的多个块中每块的签名(哈希值)的元数据添加于游戏数据的图像文件212，其中游戏数据的图像文件包括分别被赋予一个或多个块的多个文件，并且包括这些文件的元数据。应该加以注意的是，如已经描述的，未将签名附加于包括在图像文件212中的各文件的块。
[0088]记录在记录介质(ROM介质44或者辅助存储设备2)上的包文件214具有其中嵌套了图像文件212的数据结构。于是，通过两次安装包文件214，0S的内核能够访问包括在游戏数据区域202中的每个文件。
[0089]在第一阶段中的安装处理中，所述内核在第一安装点处安装包文件214，以能够识别包文件214的文件系统。具体地讲，所述内核使用包括在包文件214的元数据区域208中的元数据，以能够识别图像文件212，从而能够将图像文件212视为一个文件。由作为第一安装处理部分操作的内核实现这一安装功能。
[0090]在第二阶段中的安装处理中，为了执行游戏程序，所述内核在第二安装点处(执行安装点)安装图像文件212，以能够识别图像文件212的文件系统。具体地讲，所述内核使用包括在图像文件212的元数据区域204中的元数据，以能够识别游戏数据区域206，从而能够访问包括在游戏数据区域206中的多个(例如，10000个)游戏文件。由作为第二安装处理部分操作的内核实现这一安装功能。顺便提及，第一阶段中安装处理中的第一安装点与第二阶段中安装处理中的第二安装点可以相同或不同。
[0091]在第二阶段中的安装处理之后，所述内核执行启动文件。顺便提及，在游戏数据区域206中不压缩启动文件。因此所述内核可以照原样启动启动文件。由于图像文件212的元数据区域204的很小的数据大小，能够在诸如DDR3等的存储器中有效地扩展元数据。
[0092]以下，将描述作为图像文件210或者212的元数据区域204中的元数据所包括的平路径表。
[0093]在根据本实施例的、在UNIX中所使用的文件管理方法中，如已经描述的，也将目录和文件名当作一种文件，因此，赋予目录和文件名一个块，并且加以记录。例如，当存在目录结构“user/AAA/BBB/CCC/文件名”时，向目录名和文件名中的每个目录名和文件名分配一个块。因此，总共需要5个块。
[0094]特别是，目录的数目随游戏数据的文件的数目的增加而增加。如已经描述的，需要将文件的i_节点作为元数据读出到诸如DDR3等的存储器中。于是，期望在规模上尽可能多地减小元数据的量。因此，为减小元数据的量，在根据本实施例的数据结构中，不将以上所描述的示例中所示的全路径信息(user/AAA/BBB/CCC/文件名)用作元数据，而使用了平路径表。
[0095]将平路径表配置为将游戏文件的全路径信息的哈希值与用于标识游戏文件的记录位置的信息相关联的对应文件。期望将能够从游戏程序读出的所有游戏文件的全路径信息的哈希值和用于标识游戏文件的记录位置的信息互相关联地记录在平路径表中。此处，用于标识文件的记录位置的信息可以为唯一标识记录在记录介质上的文件的i_节点编号。因此，例如，将相应文件的全路径(user/