Re: PakFiles

[s369625@student.uq.edu.au]

I just pressed "return" without looking at the return adress, so only Christian
received this even though I meant it for the list.  Thank god for "sent mail"
folders.


On Wed, 16 Sep 1998, Adrian Ratnapala wrote:
>On Fri, 18 Sep 1998, Christian Reiniger wrote:
>>Hi,
>>
>>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?
>>
>Hmm, I would have been more woried about the complexities of variable
>sized data like filenames, but for whatever reason, I see no reason for
>the 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.
>Wise users might like a generic "check your Pakfiles" util.  That's the kind
>of value added which is pointless for a single game to give, but would be a nice
>benefit of an SDK like PPlay.  You don't need the extensive checksums you
>were talking about  though.
>
>
>>
>>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?
>Ok, but I would have thought compressing encrypted data would do shitall.
>(I'm no cryptography expert but I wouldn't trust an encryption algo that left
>us with compressible data).
>
>
>PS.  Does anyone know about the PAK files Quake uses?  I got the impression
>that it was not an Id proprietry format.
>
>
>>
>>Windows 95 - Native Plug & Pray
>Plug and Play is evil on all platforms.  I'd probably feel safer trying to get a
>P&P going on an 'doze 95 box than a linux box