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

Re: PFile work

Bjarke Hammersholt Roune wrote:

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

Plus "unrolling" of the dir storage recursion if possible.

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

In the corresponding dir entry. At least I thought that. But that leaves
the toplevel dir without such info. Hmmmm, the attribs are not the problem
(default values are fine), and ctime/mtime could be the ones in the Pak
header. But that's bad with the current implementation. Perhaps some
"freestanding dir entry"?
I mean, repeating the info for every dir isn't nice...

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

Bad luck. Anyway, the data should be stored in the file, not in the file
name ;)

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

Not yet. And the stdio functions don't support wide chars anyway. Support
for that is something for the "later" list.

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

Hmmm, why not? Ok.

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

See top of mail. You know I don't like that recursion <evilgrin>
Eliminating it isn't difficult anyway.


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