Michael Van Canneyt wrote:
> > What time stamps are in use on the various platforms?
>
> Too various. I suggest using simply TDateTime. It has microsecond
> resolution, which should be more than enough. It offers the additional
> advantage that no transformations are necessary for display & compare
> routines. There are a lot of TDateTime routines in the RTL, they would
> all be at your disposal.
Okay, I'll use TDateTime internally, with the following questions:
FPC defines 1900-1-1 as the start date, whereas Delphi defines
1899-12-30 as the start date - note: neither 1900 nor dec. 31!
This requires different constants for converting a Unix date into
TDateTime, or portable procedures. What's the suggested way for such
conversions?
The next question addresses UTC vs. local time. Usually file times are
displayed in local time. In archives either Unix dates (UTC) or FAT
dates (local time) can be found, so that conversions are required.
Unfortunately I couldn't find a definition of the time, as used in the
FPC SysUtils functions for file dates/times. Is it guaranteed, on all
platforms, that file dates in a TDateTime represent local time, and not
UTC?
Currently I'm extending the FileDate object into a FileSpec object, that
also holds the file attributes, file name, file size, and a file system
flag. I'm not yet sure how different file systems, as defined by gzip,
influence the file related information in gzip or other archives. One of
such possible effects is the encoding (character set...) of the file
names. For now at least the methods for FAT and Unix file systems will
be implemented.
The FileSpec object will contain two methods for retreiving and setting
the file related information for disk files. FromFile will collect the
information about an file or directory on disk, for subsequent storage
in an archive. ToFile will apply the file attributes to an file after
extraction from an archive. Then only the conversion between the archive
information and the information in the FileSpec object has to be
implemented for each archive type. The internal information shall allow
for lossless handling of all file attributes, when the archive file
system equals the host system.
It would be nice to apply the file attributes just when a file is
created, instead of after closing an file, but I have no idea whether
this will be possible on all platforms?
The general archive interface will have at least two levels of
abstraction. In the highest level the archive formats will be handled by
according archiver (compressor...) classes. In the lowest level the
encryption and compression methods are handled by further classes. All
available handlers (classes) register themselves at program start, so
that this registry can determine the appropriate handler for an given or
to be created file type. The selected file handler in turn can select
the appropriate handlers for compression and encryption. This separation
allows to add further file formats and compression/encryption methods
easily, without any impact on already existing code.
AFAIR Unix has some kind of registry for file types, based on file
extensions and characteristic bytes at the begin of an file. Does
somebody know more about that registry, so that it could be integrated
into the intended registry for archive handlers?
The Abbrevia contols then can sit on top of that interface, after a
one-time adaptation; specialized components for various archive types
are no more required. The Abbrevia maintainers didn't respond yet, and I
can understand that very well - nobody likes to hear that his
modifications of the orginial code are, ahem, crap. But I think that I
can adopt the Abbrevia controls to the new interface myself, though I'd
appreciate some assistance for the implementation of the Unix specific
procedures, and for testing of course. Hands up somebody out there?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
