PakFiles

[Christian Reiniger <warewolf@mayn.de>]

Hi,

apart from the memory mapping issue discussed in the other thread there are
some things about the PakFile system I'd like to discuss.

1) The current PakFile format contains some redundant information, e.g.
file names are stored both in the directory structure and in the
corresponding file structure. I thought this would be useful for data
recovery, but now I think data recovery actually isn't needed here (mainly
because we can't, without serious overhead in file size, provide recovery
features for the contained files). Is it ok to remove that redundancy?

2) The current file format contains checksums for all data structures. They
are intended for error detection. But simple checksums actually can be
wrong - i.e. the checksum is correct while the data is corrupted. So the
checksums are no substitute for actually validating the data - just as
without them. They could be useful if they'd be checked when the PakFile is
mounted - but that takes too much time. I think it is safe to remove them.

3) The current file format doc states that, if a file has both "compressed"
and "encrypted" flags set, it's been compressed first, then encrypted. But a
friend told me that, depending on the encryption algo, the resulting data
can be larger than the original - despite compression. So the format should
allow for both compress-then-encrypt and encrypt-then-compress. I think an
additional "compressed-first" flag is appropriate for this. Comments?

Cu
	Christian

PS: The major parts of the PakFile compiler tool now compile. Individually.
In an isulated environment. With egcs 1.1. I hope I'll have the remaining
code for a first version ready this weekend so I can attempt to actually
link things together and run it ;)
--

Windows 95 - Native Plug & Pray