File I/O

[Christian Reiniger <warewolf@mayn.de>]

Hi,

Just a little contribution to the madly loved
"Important-Subprojects-Nobody-Dared-To-Start-Working-At" (TM) series ;)

This time: The File I/O system

The main idea here is to provide transparent handling of files collected in tar-like archives.
I won´t discuss the Why etc here - I assume everyone here has encountered such files already.

Ok, I´ll start with an example. Imagine the game´s directory looking somehow like that:

-----------
gamedir/
    data/
        textures/
            wall/
                01.png
                100.png
                101.png
                ...
        textures.tre
        bigart.tre
        maps.tre
        ...
    save/
        ...
    game.exe
-----------

The *.tre files are PPlay archives.

Imagine textures.tre would contain this directury structure:

-----------
textures.tre
    wall/
        01.png
        02.png
        ...
        99.png
    furniture/
        ...
    people/
        ...
    floor/
        ...
    ...
-----------

Ok, now the game decides it needs the wall texture #01. It executes a

ppFile *texture1 = ppfopen ("data/textures/wall/01.png", "r");

call (syntax identical to fopen ()). Now the PPlay File-I/O system looks at the directory structure.
It finds a file "data/textures/wall/01.png" - so it opens it. Now trying to get wall texture #02 the game executes

ppFile *texture2 = ppfopen ("data/textures/wall/02.png", "r");

Here PPlay again tries to find 02.png in the "data/textures/wall/" directory - without success this time. So
it tries to find an alternative location of the file. It sees that a file "data/textures.tre" exists and (recognizing the
file´s header as the header of its archive files) uses this file as virtual directory "data/textures/".
textures.tre contains a file "wall/02.png" - bingo. The file handle is returned. Call successful.

Summary:

* The archive files themselves are used to emulate subdirectories. 
* They contain a directory/file hierarchy - just like a normal file system. 
* The ppfopen () calls do not (!!) distinguish between "real" files and files in an archive file. 
* If a file exist both as "real" file and in an archive, the "real" version has the higher precedence (very useful for testing, adding of packages)
* The archive files do not have to have a standard extension - they are recognized via their header (of course this info has to be cached)
* Each archive file represents a directory with identical name _without_ the last extension (dir1.foo.bar.somearchiv -> dir1.foo.bar/)

Ok, this makes for a solid basic functionality. But there are some more things:

* Files and directories in archives have attributes. They have at least timestamps (ctime, atime, evtl. mtime). owner/group info
   is unnecessary, as only "the game" accesses them, regardles of the person playing the game.
* Archive files need to contain info about name and version of the game, copyright info, required/recommended PPlay version,
   creation date etc in the Header.
* Archive files should provide facilities for data recovery (checksums, multiple copies of important structures etc)
* It has to be possible to encrypt archive header and files with a user-defined algorithm (for those paranoid game companies)
* transparent (de)compression of certain files (e.g html, ...)is a big plus. Perhaps with some "compressed" attribute for each file/dir

Well, that´s all for now - except for one topic: writing files

Making the files contained in archives writable raises some really big problems - they are very likely to change their size.
To support this the entire archive struchture has to be block based (like any full-featured HDD file system). Ugly.

So the archives have to be assembled once with a special tool (taking care about additional info like header, file attributes, ...),
staying readonly thereafter..

So who´s gonna start working? ;-))

Cu
	Christian