Ich habe die Klasse TMemoryStream untersucht und die folgende Routine gefunden :
Ich habe dieses Muster sehr oft gesehen, wo Int64 einem Longint zugewiesen wurde.
Mein Verständnis ist, dass Longint vier Bytes und Int64 ist acht Bytes in 32-Bit- und 64-Bit-Windows, also wenn meine Dateigröße FFFF FFFF == 8589934591 == 8 GB ist dann wird diese Routine einfach nicht lesen, weil die endgültige Zählung $ FFFF FFFF == -1 ist.
Ich verstehe nicht, wie das erlaubt ist und vielleicht nicht berücksichtigt wird (vielleicht versuchen nicht viele Leute, eine Datei mit mehr als 8 GB zu lesen).
Ich habe ein Ticket dafür eingeloggt und es wurde anscheinend in Tokio 10.2 behoben. Dies ist ein Problem für die 64-Bit-Kompilierung.
Es gibt Probleme mit großen (& gt; 2 GB) Dateien in TCustomMemoryStream und TMemoryStream . In TMemoryStream sind die Probleme einfach, da die lokalen Variablen als NativeInt anstelle von LongInt deklariert werden müssen und die Kapazität in NativeInt geändert werden muss. In TCustomMemoryStream sind sie subtiler, weil beide Methoden TCustomMemoryStream.Read das Ergebnis einer Int64 - Int64 Berechnung direkt einer LongInt zuweisen. Dies wird selbst dann überlaufen, wenn das Ergebnis dieser Berechnung nicht größer als% LongInt ist.
Wenn Sie dies in Seattle beheben möchten, müssen Sie entweder einen Code-Hook durchführen, die Unit System.Classes ersetzen oder Ihre eigene Ersatzklasse für TMemoryStream einrichten. Beachten Sie, dass Sie für die letzte Option auch TBytesStream und TStringStream ersetzen müssen, da diese von TMemoryStream abstammen.
Das andere Problem mit der letzten Option ist, dass Komponenten von Drittanbietern keine "Fixes" haben. Für uns hatten wir nur ein paar Stellen, an denen wir mit Dateien arbeiten mussten, die größer als 2 GB waren, also haben wir diese umgekehrt.
Die Korrekturen für TCustomMemoryStream.Read (müssen für beide Methoden gelten) sehen etwa so aus:
%Vor%Tags und Links delphi delphi-10-seattle