Re: PFile work

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

> >> >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.
>
Hmm... I hadn't thougth of that. Yes, that's a problem.

Not a overwhelming one, though. See below.

> >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.
>
Hmm... I 50% like this, and 50% don't like this... :)

There's also the argument that the directory is not created at mount
time, it was there before, it just got connected to virtual FS at mount
time. Kind of like a file (or dir, as is the case here) on a floppy disk
(or a harddisk for that matter), which don't get its date set to "now".

For now, I'll implement it by setting it to "now", as I wouldn't exactly
say this is an issue that keeps me up at night... ;)

> >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).
>
The question then is wheter its really worth it to add special case code
to handle a case that can be handled just fine by the normal code,
albeit a little less effeciently.

Now, we could (de)serialize the top-level dir completely normally
from/to storage, without any special case for it. Then when its time to
mount, we simply ignore the top-level dir and adds its contained
files/dirs to the mount point. No extra code. We loose a very little bit
of effeciency in that the top-level dir then have some attribs and the
like that we really don't NEED to write, but that's something like a
constant 4 (very small amount, anyhow) bytes per entire pak, nomatter
the size of the pak.

> >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".
>
We could just give it a name of "\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
> 
> >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.
>
Well, I've done that... ;)

> >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 ;)
>
<stares at the screen>

Uh, ok...

<feels a little bit stupid>

> >Excuse my english... What I meant was storing the filenamesize in
> >unsigned shorts rather than unsigned chars.
> 
> Ok, that makes sense. Fine with me.
>
Actually, do any OSes support names longer than 255 chars? I mean,
paths, certainly, but names? I don't know...

> 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.
> 
Ok, fine.