Virtual file systems

Question

Most games come with their own resources (models, textures, etc.) packaged in special files (for example, .pk3 files in Quake 3, for example). Apparently, these files are somehow "mounted" and used as if they were separate file systems.

I would like to know how this is achieved. The only strategy that I have encountered so far is to place information about the size of the offset in the file header, and then map the memory to the file and access the resources as if they were independent write-protected memory blocks.

I would like to know if my strategy is viable and if there are better alternatives.

Thank!

Answer 1

Your strategy is quite reasonable; in fact, it is an exact analogue of what a file system driver with a raw block device does. What problems arise with this implementation?

Answer 2

Your approach sounds reasonable. Basically you will have an ISAM file with (optional) metadata. You can divide the file into sections ("directories") based on criteria (type of content, frequency of use, location of use, etc.) and have a separate index / table of contents for each section. If you allow a section as a type of content, you can nest them in them and process them in a consistent way.

, zip/tar . , , , .

Answer 3

Quake3, , :

• (ZIP, Tar ..)
• . Windows Microsoft Structured Storage
• , , , - ( , ..).

.

SolFS , . , .

Archives and some complex file implementations usually have a linear sequential structure - files are written one after another with some directory at the beginning or at the end of the file.

Some complex file implementations, databases, and the virtual file system have a page-based structure (a “page” is similar to a sector or cluster in FAT or NTFS), where files can be scattered throughout the repository.