Re: [fpc-devel] File Dates
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] File Dates
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. Hmm, I'd look in /usr/share/misc/magic/ myself. Or wherever the file commando's data is stored on your distro. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] File Dates
On Sat, 29 Jan 2005, Marco van de Voort wrote: Michael Van Canneyt wrote: 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? IIRC there are some problems that lead to multiple definitions for julian dates: - original julian starts at noon, so the exact moment taken for the first day could be before and after. - leaphandling for the year 1900 was not uniform IIRC over all calendars But I don't know why FPC's definition is not the same as delphi's :-) The definition is the same. It's also used in variants; that is why it has this strange form. If the docs say otherwise, then the docs are wrong. I should check this. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] File Dates
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? 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? 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? 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 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? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] File Dates
On Mon, 24 Jan 2005, DrDiettrich wrote: Currently I'm trying to define an object for file dates. This object shall allow to compare time stamps for files on disk and in archives, and it also shall be usable to set time stamps for such files. Now I'm undecided what unique internal date/time representation to use in such an object. For comparison the minimum resolution of the given time stamps should be taken into account, so that computations don't result in different time stamps for the same time. This restriction prohibits the use of TDateTime, where floating point calculations can result in such differences. Do there exist usable data formats for such time stamps? 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. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] File Dates
Currently I'm trying to define an object for file dates. This object shall allow to compare time stamps for files on disk and in archives, and it also shall be usable to set time stamps for such files. Now I'm undecided what unique internal date/time representation to use in such an object. For comparison the minimum resolution of the given time stamps should be taken into account, so that computations don't result in different time stamps for the same time. This restriction prohibits the use of TDateTime, where floating point calculations can result in such differences. Do there exist usable data formats for such time stamps? What time stamps are in use on the various platforms? What methods would you expect with such an object, so that the date/time information can be displayed and compared to other time stamps on the host OS? AFAIK Unix file time stamps are UTC in seconds since 1970. That format would be safe for comparisons, calculations only are required for display purposes (uncritical). DOS (FAT) file time stamps are in local time, without an indication of the time zone. Furthermore the date is a calendar date, so that calculations are required to convert such time stamps into UTC. How to accomplish a conversion into a unique UTC date, so that the stamps will compare equal regardless of local time zones or daylight savings? Win32 has another (NTFS) file time format, using UTC and elapsed time in 100 ns resolution. A translation from/into Unix time stamps should be safe and easy? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
