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] VMT compatibility
I where any chance to see FreePascal generating VMT's for classes that is more compatible with C++ / TurboPascal / Delphi one? To explain mine question: recently I've been porting Delphi framework interfacing to C++ code to FPC and finded out that althrow Delphi VMT layout is compatible to C++ one, FPC is not. Are you sure Delphi is compatible to C++ or just to Borland C++? The latter would be logical, since both Delphi and C++ Builder use the same backend. Or are Delphi classes also binary compatible with Visual C++ and g++ classes? Delphi is compatible at least with Borland C++ and MS VC++. And taking in accout how COM intefaces are implemented in C++ (I'm supposing here all C++ compilers support the same syntax) - each C++ compiler supporting MS way to declare COM interfaces has compatible VMT layout. PS. I'm not insisting for compatibility on internal fields (with negative offset in Delphi case), but hope for layout compatibility of user defined virtual methods. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMT compatibility
On Sun, 30 Jan 2005, Alexey Barkovoy wrote: I where any chance to see FreePascal generating VMT's for classes that is more compatible with C++ / TurboPascal / Delphi one? To explain mine question: recently I've been porting Delphi framework interfacing to C++ code to FPC and finded out that althrow Delphi VMT layout is compatible to C++ one, FPC is not. Are you sure Delphi is compatible to C++ or just to Borland C++? The latter would be logical, since both Delphi and C++ Builder use the same backend. Or are Delphi classes also binary compatible with Visual C++ and g++ classes? Delphi is compatible at least with Borland C++ and MS VC++. And taking in accout how COM intefaces are implemented in C++ (I'm supposing here all C++ compilers support the same syntax) - each C++ compiler supporting MS way to declare COM interfaces has compatible VMT layout. That would be true only for interfaces, not for straight VMTs ? And Delphi's VMT's are not compatible with GCC's; At least, kylix cannot use GCC classes. I'm not even sure they are compatible with the ones from MS Visual C++; Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: File Dates
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?
=
unit libmagic;
interface
{$PACKRECORDS C}
{$LINKLIB magic}
{$LINKLIB c}
const
MAGIC_NONE = $000;
MAGIC_DEBUG = $001;
MAGIC_SYMLINK= $002;
MAGIC_COMPRESS = $004;
MAGIC_DEVICES= $008;
MAGIC_MIME = $010;
MAGIC_CONTINUE = $020;
MAGIC_CHK= $040; // naming conflict ( was MAGIC_CHECK )
MAGIC_PRESERVE_ATIME = $080;
MAGIC_RAW= $100;
MAGIC_ERR= $200; // naming conflict ( was MAGIC_ERROR )
type
size_t = dword;
magic_set = record
{opaque structure}
end;
magic_t = ^magic_set;
function magic_open(flags:LongInt):magic_t;cdecl;external;
function magic_file(cookie:magic_t; filename:pChar):pChar;cdecl;external;
function magic_error(cookie:magic_t):pChar;cdecl;external;
function magic_setflags(cookie:magic_t; flags:LongInt):LongInt;cdecl;external;
function magic_load(cookie:magic_t; filename:pChar):LongInt;cdecl;external;
function magic_compile(cookie:magic_t; filename:pChar):LongInt;cdecl;external;
function magic_check(cookie:magic_t; filename:pChar):LongInt;cdecl;external;
function magic_errno(cookie:magic_t):LongInt;cdecl;external;
procedure magic_close(cookie:magic_t);cdecl;external;
function magic_buffer( cookie:magic_t;
buffer:pointer; buflen:size_t):pChar;cdecl;external;
implementation
end.
=
program testmagic;
uses strings, libmagic;
var
magic: magic_t;
begin
if ( paramcount = 1 ) then begin
magic:=magic_open( MAGIC_SYMLINK or MAGIC_MIME );
magic_load(magic, nil);
WriteLn(magic_file(magic, argv[1]));
magic_close(magic);
end else WriteLn(StdErr, 'Usage: testmagic filename');
end.
=
Requires file --version = 4.0
See also:
http://directory.fsf.org/file.html
http://prdownloads.sourceforge.net/gnuwin32/file-4.12-lib.zip?download
.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
