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