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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
