[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PakFiles & Portability
Christian Reiniger 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.
> (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
for linking to
things on _other_ file systems. Well, this might be quite usefull. What do
others think.
> (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
> time", so getting an appropriate value can be very cumbersome on some
> systems.
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
don't se a problem.
> What about storing the date/time as ASCII string (like the output of
> 'date -u') ?
I distrust strings in general. But that is just my taste.
>
>
> (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.