Re: PFile work

[Christian Reiniger <warewolf@mayn.de>]

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

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.


	Christian
-- 

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