Re: PFile notes

[Bjarke Hammersholt Roune <asmild@post6.tele.dk>]

> 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..
> 
Aha, a misunderstanding! :)

I was talking about how the pakfile was invalid while is was being built
(ie, we don't complete the pak untill we unmount it). You replied that
there was no reason for this to be so anymore, since we now had this
serialization scheme in place. Atleast, that is the way I percieved it.

Anyway, and we agree... :)

> >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.
>
Hmm... Agreed.

> >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.
>
Why not? Taking the old start position of the DirInfo part and adding to
that the length of the newly included pak should give us the new start
position.

Actually, its even simpler than that. Just take the stream position just
after the content part has been added. That is the start position of the
next part.

> 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.
>
I still don't see how it helps.

> >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.
> 
That's pretty clever...