Re: PFile work

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>> >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.
>>
>To which implementation are you referring? And what is the problem?

The one we have right now. The problem is that PakDirectory assumes that it
either (1) is initialized by deserializing itself from a Pak or (2) is a
new Dir that has to be added to the Pak.

The root dir doesn't completely fit in any of these categories.

>Actually, do we even need ctime/mtime for directories? I mean, I can't
>imagine when I would use such information. And other attribs, well,

Consistency is good. and mtime for dirs *does* make sense (when was
something added to the dir?). But we *could* initialize the Pak's root dir
with the time of "now" (when the Dir object is created), as this dir is
also the mount point - which is in fact "created" at mounting time.

>actually, I don't see any that are needed there either, except the
>number of elements in the dir (which is handled by the container
>contained by Directory).

The attribs should stay. But the Pak's root dir as special case doesn't
need them (it just uses the defaults, eventually modified by the mounting
options).

>That leaves the dir name.

The pak root dir doesn't have a name as such. It gets its name only at
mounting time. When the client calls ppfMount ("mypak.xxx", "manyfiles",
0); the root dir of Pak "mypak.xxx" is "created" as mountpoint, named
"manyfiles".

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

>But, well, what do we do? I mean, if a the player of a game for some
>reason wants to store his game in this path:
[...]

Then he should think a bit about his sanity. Really.

>realistic, but its not impossible to have paths longer than 255
>characters. Anyways, its really a very easy thing to fix. Just use

PFile *does* support Paths > 255 chars. It supports paths with up to 32
parts, each up to 255 chars long (as it stands now).
That's a maximum path length of 32*255 = 8160 chars. Plus
slashes/backslashes ;)

>Excuse my english... What I meant was storing the filenamesize in
>unsigned shorts rather than unsigned chars.

Ok, that makes sense. Fine with me.

>> See top of mail. You know I don't like that recursion <evilgrin>
>> Eliminating it isn't difficult anyway.
>> 
>You do realise that not doing it in this way will have several bad
>sideffects, while offering no benefits that any client of PFile will
>ever know about?

[...]

Ok, you convinced me 80%.
I still believe that my method is *less* error-prone, simply because it's
easier to understand, but well...

I guess you're right. So go ahead with the recursive version. But please
use the "dir\0" marker for directories at least for now (for initial
testing). Dump the markers for dir entries, but leave the dir ones in for
now.


	Christian
-- 

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