[fpc-devel] File Dates

[Michael Van Canneyt]

On Sun, 30 Jan 2005, DrDiettrich wrote:

> 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.

NTFS is a bit weird regarding filetimes;
But I don't know whether we should concern ourselves with filesystem
details ?

>
>
> > > 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
> > purposes.
>
> What I saw was not restricted to MIME, but it might have been KDE
> specific.

That's what I was referring too...

>
>
> > > 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.

This is a tricky issue. I'm not sure what path should be followed here.

>
> 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?

No. It's a mess.

There is some support present for 8.3 in the FPC sources, but new things
will not be added.

>
> 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?

Send it private. Big files are not allowed on the list, although I don't
know the exact limit.

Michael.