Re: PFile notes

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:
>If its a pakfile that will be opened by several processes at different
>times, we could have a method that wrote the pak filesystem architecture
>data (like umount does now).

I'm not sure I understand what you mean with that..

>> (1) Creating the (big?) Pak once and after that accessing it only
>> readonly.
>>     Here behavior is exactly the same as for Format 0 Paks.
>>
>Except for the building the pak part. If its a 1000 files pak, the
>filestrucutre serialization code will be run a 1000 times... Is this really

Of course not!
Each file's data is written to the Pak, and *after* that, when the Pak is
umounted, the dirinfo is serialized.
I.e. the serialization code is only called *once*. And only that one call
is neccessary, because we can access the Pak just fine as long as we have
the proper dirinfo data *in memory*.

>I agree with this, but I think its best to let the client decide when it
>thinks its nessecary to have the pakfile be valid, and when it doesn't
>matter. IMHO we get the best of both worlds that way.

That means exactly...?

>> I want to have PakFiles layouted like that:


>That looks good, except I think the x-part should be before the dir-part,
>as we *know* that the dir-part will grow when adding to the pak, while the
>x-part might not.

Hmm, yes, that makes sense. Agreed.
Stop - wait! That's wrong! When we add something to the Pak the "Content"
part grows, (partially) overwriting the following part. So we always have to
rewrite both DirInfo and XHeader after adding something.

So placing the XHeader at the end again makes more sense, as it might
contain information about how the DirInfo part is laid out - and thus
should be written *after* that one.

>I don't see how it helps, though. Offsets into the content-part are very
>easy to compute (and impose no overhead), as the header-part has static
>size. The dir- and x-parts only need a single link from the header-part,
>which they would need anyway.

The background is the following problem: When we add something to the Pak
we overwrite the start of the dirinfo part, but don't neccessarily reach
the end of the PakFile. That means we can't easily determine the start of
the (XHeader|DirInfo) part after such an op. The solution for this is to
"pipe" all write ops through PakFile, which through that can easily keep
track of how big each part is [Note to self: There is some problem with
properly keepin track of the DirInfo part size with this. I can't
completely lay my hands on it yet though...].
This is done my PakFile providing WriteContent () and ReadContent ()
methods.

And the "relative" addressing is primarily a mechanism for abstraction and
easier understanding (keeping the parts independent of each other). Not
really neccessary, but nicer.

>Hmm... Wouldn't this also make it harder to go thorugh the pakfile in a
>hex-editor? ;)

*grin*
No, not really. It *can* even make it easier by allowing you to split the
Pak into several files and thus examine its parts independently.


	Christian
-- 

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