[fpc-devel] File Dates

[Michael Van Canneyt]

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.