[fpc-devel] File Dates
Michael Van Canneyt
michael at freepascal.org
Sat Jan 29 14:45:32 CET 2005
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
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
> 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?
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
> 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.
More information about the fpc-devel