[fpc-devel] File Dates
drdiettrich at compuserve.de
Sun Jan 30 01:36:07 CET 2005
Michael Van Canneyt wrote:
> > 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 file functions are not applicable to the information stored in
archive files. Archives can contain Unix or MSDOS specific file
information, that has to be handled on all platforms, or better: file
systems, where the files are to be extracted. Abbrevia implements e.g.
procedures to map between Unix and DOS file attributes. In Delphi a
FileTimeToLocalFileTime procedure only is supported as a Windows API
function, not available on Linux.
> > 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.
Your're right, at least the timestamp(s) must be updated after the file
has been closed.
> 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
What I saw was not restricted to MIME, but it might have been KDE
> > 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.
IMO it would make sense to have an Unix "stat" record available on all
platforms. This record then can be filled with the Unix-style file
information in an archive, and then has to be applied to the extracted
file, on any platform. Similarly it should be possible to initialize it
with the information about an existing file, on any platform or file
system, for storage of the applicable information in an archive. As
mentioned above, a translation between the Unix permissions and FAT file
attributes can be borrowed from Abbrevia. A more general procedure would
be nice, that can translate the Unix and FAT file attributes for use on
the actual target platform, as far as supported by fpc.
Next comes the conversion of file names, what migth be tricky for MSDOS.
That's why I would not support 16-bit DOS now - does somebody see a need
for such support? Or would you implement according conversions for DOS?
My fileutil unit currently is 13 KB, in the Windows version, but I'll
have to add some more comments to it. Then I can send you this unit, or
can I simply post it here as information for everybody?
More information about the fpc-devel