Re: PakFiles & Portability

[Christian Reiniger <warewolf@mayn.de>]

Adrian Ratnapala wrote:

>> (1) In the archive file format description I wrote that each "directory
>> entry" would have ctime, mtime (creation/modification time) stored with it,
>> but I'm not sure anymore whether this data is useful at all. What do you
>> think?
>
>Include them unless there are performance problems.

Ok. There's not performance overhead throught them. I'll keep them.

>> (2) (almost the same issue as above) Is support for (sym-) links useful?
>
>I thought that symlinks would be vital, but lets see.  On a read only
>filesystem,the only use I can think of for symlinks (instead of hard ones) are

Hmm, I even can't imagine real benefits of hard links in such pak files..

>for linking to
>things on _other_ file systems.  Well, this might be quite usefull.   What do
>others think.

Perhaps for aliasing directoriey (i.e. /grapics/movies/ to /movies/), but I
doubt any game developer will do this...

>> (3) I wanted to store the archive creation time/date as "seconds since
>> 1/1/1970" since that is the format I know from PCs. But the C time ()
>> function is only required to return "an arithmetic value representing the
>
>Man pages say seconds since 1/1/1970 (GMT).   I'm sure this is true
>rightacross POSIX.  On Windows we just subtract one decade (I think).  So I

Hmmm, yes. POSIX seems to define this. ok.

>> (4) Should allowed file sizes and offsets in PakFiles be 32 or 64 bit?
>> 64bit has the advantage of supporting files > 2GB, but implementing 64bit
>> values in C portably is a pain in the a**.
>
>Leave 64 in the file format.  But if you don't want to bother implementing 64
>bits,don't bother.

Ok, I won't bother for now ;)

Cu
	Christian
--

C:\DOS\COMMAND\SYSTEM\HELP\WHERE\THE\F*CK\AM_I