Re: PFile notes

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>> Ooops, sorry. <WHACK>. Not "sync" but "serialization"

>The changes were pretty quick. I changed the code to do exactly what the
>old code does, just in the new scheme. All it does is to open a file
>(specified by filename),

PakFile::Open () does that.

> serialize and close the file.
>
>However, that leaves serialization of the header (or footer, as is the case

Done in the second constructor of PakFile (calls CreateHeader ()).

The PakFile writing code I wrote worked as follows:

(1) The User calls ppfCreatePak (), which creates a new PakFile object
using the second constructor. Here PakFile::CreateHeader () is called,
which writes the Pak header, creating a completely empty PakFile. After
that the PakFile object is immediately destroyed.

(2) The user mounts the new PakFile with the ppfMF_write flag. The code for
this creates a new PakFile object using the first constructor, which
recognizes the Pak as a new one, allowing the adding of files.

(3) The user uses ppfMkdir () and ppfCopy () to add directories and files
to the Pak. The changes are only reflected in the Pak's dir structure in
RAM (now composed of PakWDir and PakWFile objects) until ...

(4) The user umounts the Pak. The destructor of the PakFile object is
executed, which in turn makes the toplevel dir write itself (recursively).
The Pak is closed. Done.

The PakFile contains a header (always at the very start of the Pak fixed
size, standard layout independent of the Pak format) plus an "extended"
header (located at any place, format dependent layout/size, eventually even
variable size (I'm not sure about that yet)). The main header contains
links to both the extended header and the root dir structure.
These links (at least the one for the root dir struct) have to be updated
for format 1 (& eventual later formats) after adding files, so a generic
WriteHeader () instead of the CreateHeader currently in PakFile is better.
Trivial.


I guess you had some different assumptions of that process?


Ok, some notes about the code you added to PakFile::Umount () :

		Directory::SetContentOffset(0);
		Directory::SetSerializingPakFile(this);

You assume serializations to PakFiles only - at the level of the Directory
class. Bad. This is better: PakFiles that may have to update themselves
later (i.e. either ones being initially constructed or format 1 ones
mounted as writeable) accept no "foreign" directories below them - only
directories belonging to that PakFile. That ensures that the root dir of
the Pak and all dirs/files below it (1) are of proper type
(PakFileDir/PakFileFile or PakFileWDir/PakFileWFile), (2) know what PakFile
object they belong to, thus (3) know what format the Pak is of and with that
(4) know exactly how to serialize themselves.

So the Directory/File classes only need to provide (pure?) virtual
SerializeTo () methods. The details of that operation are then handled by
the classes derived from them.

This also makes it simple to serialize to something different than PakFiles
in the future.

Another thing - What about positioning the dir info of format 0 paks at the
end as well? That would make it possible for ppfCopy () to instantly copy
the file data instead of delaying that to umounting time. And that in turn
makes it easier for the client to keep track of the progress (very useful
for feedback to the gamer).


	Christian
-- 

Drive A: not responding...Formatting C: instead