Re: PFile work

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

> I fixed the file/dir attribute stuff the basic write access to Paks. The
> serialization code is still untouched. Bjarke, can you have a look at it?
>
Sure. Simply a matter of having it do what you talk about below, and the
different section stuff (ie, offsets starting at 0 for each section) ?

> This is the layout of the Pak data structures as I'd like it (open for
> comments of course):
> 
> (1) Directory:
> 
> "dir\0"
> <HashTable info (NrOfEntries, HashTableSize, ...)>
> Entry1
> Entry2
> Entry3
> ...
>
What about the additional data of Directory? (like mtime and ctime) Do
they go before or after? (I think before, but I really don't think it
matters)

> (2) Directory Entry:
> 
> "dire"
> NameLength (1 Byte)
> Name (Max 255 chars, no trailing \0)
>
About that 255. What do we do about OSes that allow paths and names
longer than 255 characters? (are there any that does this? I don't know
the limit for Windows, but I do think it allows paths longer than 255)

We store path and filenames all over in one-byte-size variable. I think
we might want to consider using two bytes (ie, short) instead.

> Attribs (4 Bytes)
> CTime (8 Bytes)
> MTime (8 Bytes)
> FileSize (8 Bytes)  // 0 for dir
> DataSize (8 Bytes)  // 0 for dir
>
How about not having these at all for directories? The serialization
code that writes dirs and files is seperate anyway.

> File/Dir Position (8 Bytes)
> 
> File position is in "content space" (PakFile::m_dataPos is set correctly)
> Dir positions are in "dirinfo space"
> 
> You might have to add an m_entryPos field to PakDirectory so that it can
> correctly write the dir position thing
> 
Dir position? Directories are positioned in a recursive manner so that
their position relative to each other plus the number of subdirectories
of each directory make it clear what the position of each directory is.

> PS: I completely disabled delayed writing for files. That means that (1)
> PakFile::SerialiteContentTo () is a no-op and (2) You can assume that at
> serialization time all contained files are completely written (and all are
> closed)
> 
Good.