[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.