[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PFile work

> 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

> (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)