[Allegro] problem mit import.exe bei großen datenbanken

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

ich weiss nicht, ob die Sache die Muehe lohnt, spaetestens ab 4GB
Dateigroesse wird man auf MS-32bit-Plattformen bestimmt noch groessere
Probleme bekommen. Und selbst wenn man alle allegro-Module umstellt
auf Behandlung von Dateien >2GB gibt es beim Arbeiten mit diesen
Dateien womoeglich anderen Aerger (z.B. beim Kopieren auf eine
alte FAT32-Partition ;-)?

Andererseits muessen die neuralgischen Stellen sowieso alle
angefasst werden, denn offensichtlich wird dort nicht der vom
System zurueckgegebene Fehlerzustand abgefangen ...


>> Aber gewisse Funktionen in der 32bit-Library (speziell fseek() )
>> koennen nur Positionen im Bereich -2^31 .. 2^31. Fuer groessere
>> Dateien gibt es evtl. andere Funktionen, auf die ausgewichen werden
>> kann.
>>
>> Das 16bit-Import.exe macht evtl. keine fseek(), das 32bit-Programm
>> macht ausweislich des Quellcodes welche. Argumente dafuer sind
>> vom Typ (signed) "long", das ist auf der Plattform Visual C++ 2005
>> ein 32bit Integer. See?
>>
> Das 16bit-Programm ist an der Stelle identisch. Kann Herr Lehmann mal
> prüfen, ob seine Ergebnisdatei, die es erzeugt hat, an der Nahtstelle
> von 2GB korrekt ist? Vermutlich demnach nicht.
> 
> Es gibt im Visual C++ eine Funktion
>   __int64 _lseeki64( int handle, __int64 offset, int origin );
> 
> Aber kennt GNU C++ Vergleichbares?

Nicht ganz analog (und mit GNU C++ hat das nichts zu tun, sondern m.E. eher
mit glibc bzw. POSIX und der konkreten Plattform. In der Tat ist es besser,
geeignete Aufrufe zu nutzen als darauf zu spekulieren, dass "long" 8 Bytes
breit ist. Linux-Distributionen der letzten Jahre unterstuetzen den "Large
Files Standard" LFS):

es gibt fseeko(), wo das Offset nicht long sondern vom Typ off_t ist
(-> man fseeko : Anscheinend muss man die Eigenschaften des Typs off_t
ueber ein #define vorgeben. Das veraestelt sich dann ziemlich in
LARGE_FILE und LARGE_FILE64 und duerfte stark plattformabhaengig sein,
also separate Compilierung erfordern. Andererseits ist off_t sowieso
*der* zentrale Datentyp fuer Dateioffsets, etwa auch beim locken...
aktuelle Kernels unterstuetzen allerdings nur Dateigroessen bis 2TB
- alles wie gesagt auf 32bit-Plattformen)

Aus dem autoconf-Manual:
>>>
 -- Macro: AC_SYS_LARGEFILE
     Arrange for 64-bit file offsets, known as large-file support
     (http://www.unix-systems.org/version2/whatsnew/lfs20mar.html).  On
     some hosts, one must use special compiler options to build
     programs that can access large files.  Append any such options to
     the output variable `CC'.  Define `_FILE_OFFSET_BITS' and
     `_LARGE_FILES' if necessary.

     Large-file support can be disabled by configuring with the
     `--disable-largefile' option.

     If you use this macro, check that your program works even when
     `off_t' is wider than `long int', since this is common when
     large-file support is enabled.  For example, it is not correct to
     print an arbitrary `off_t' value `X' with `printf ("%ld", (long
     int) X)'.

     The LFS introduced the `fseeko' and `ftello' functions to replace
     their C counterparts `fseek' and `ftell' that do not use `off_t'.
     Take care to use `AC_FUNC_FSEEKO' to make their prototypes
     available when using them and large-file support is enabled.
<<<


Es gibt auch ein "alternatives Interface" mit fsetpos(), wo ein Objekt
vom Typ fpos_t uebergeben wird. Das wird als sehr portabel bezeichnet,
die Microsoft Standard C++ library scheint das auch zu kennen, mein Eindruck
ist allerdings, dass fpos_t nicht a priori fuer dieses Problem geeignet
ist:
"fpos_t (long integer, __int64, or structure, depending on the target platform)"


viele Gruesse
Thomas Berger