On Fri, 28 Jan 2005, DrDiettrich wrote:
> 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? There are routines which change file dates as reported by the various file functions to TDateTime, so you don't need to worry about this. > > 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? Yes. > > > 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. Seems fine. > > 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? Consider this a no, this is the safest; If you do it at file open, then the system may change your written timestamp as you write to the file. > > > 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 only file with such info is mime.types or mime.cap in /etc. Of course, KDE and GNOME have their own copies of this file for internal purposes. > > > 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? Just tell me what you need, and I'll be glad to implement it. As far as I remember, you were going to hide all platform specific stuff in a separate file anyway, insofar as it is not yet in sysutils. Michael. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
