AddPackMemory() zerstört Datei unter PB 5.2

[Thorsten1867]

Wenn ich eine Text- oder XML-Datei mittels AddPackMemory() in eine ZIP-Datei schreibe wird der Anfang der Datei zerstört.
Aus "Das ist eine Testdatei zum Packen." wird "Ä [NUL] Ä [NUL] eine Testdatei zum Packen."

Code: Alles auswählen

UseZipPacker()
#Pack = 1
#Datei = 2
PackFile$ = "E:\Temp\Test.zip"
File$ = "E:\Temp\Test.txt"

Procedure File2Pack(File.s)
  If ReadFile(#Datei, File) 
    length = Lof(#Datei)
    *MemoryID = AllocateMemory(length)
    If *MemoryID
      If ReadData(#Datei, *MemoryID, length)
        AddPackMemory(#Pack, *MemoryID, length, "Test.txt")
      EndIf
      FreeMemory(*MemoryID)
    EndIf
    CloseFile(#Datei)
  EndIf
EndProcedure

If CreatePack(#Pack, PackFile$, #PB_PackerPlugin_Zip)
  File2Pack(File$)
  ClosePack(#Pack)
EndIf

[Chimorin]

Ich habe mich nicht viel mit der Packerlib beschäftigt, deshalb kann ich nicht sagen, ob du irgendwo einen kleinen Fehler drin hast.
Insofern stimme ich dir zu, auch wenn bei mir nur "Das ist eine Tes" abgeschnitten und durch Gekraksel ersetzt wird.

[Rudi]

Den Fehler kann ich weder unter PB 5.11 noch unter PB 5.21 reproduzieren.

Anderer Bug:
Was mich aber stört, ist der Umstand, dass bei den Funktionsaufrufen: UncompressMemory(), UncompressPackFile() und UncompressPackMemory(), bei einem Fehler, "0" zurückgegeben wird. Den Gleichen Rückgabewert erhalte ich aber auch bei einer Null-Byte-Datei wenn sie korrekt entpackt wurde, da dann die unkomprimierte Größe zurückgegeben wird.

Vielleicht sollte man bei einem Fehler "-1" zurückgeben!

[ts-soft]

Eine 0-Byte Datei kann nicht gepackt werden, deshalb ist die Rückgabe von 0 (Fehler) korrekt.

Wenn der Speicherpuffer nicht komprimiert werden kann, dann wird er "so wie er ist" in der Paket-Datei gespeichert.

Es wird also nur ein leerer Eintrag erstellt im Localem Header des Archivs.

[Rudi]

Nun ja. Das liegt dann wohl im Auge des Betrachters.

Wenn eine Null-Byte-Datei auf der Festplatte erstellt wurde, dann möchte ich doch wissen, ob das korrekt geschehen ist oder ob es nicht geschehen ist. Darum bleibe ich noch bei meiner Sichtweise.

Aber das kann auch ein abendfüllendes, philosophisches Thema werden.

[ts-soft]

Eine Null-Byte Datei auf Datenträger zu schreiben, ist ja auch möglich, das Packen einer Null-Byte Datei ist aber
grundsätzlich nicht möglich

[Rudi]

Mir ging es ja auch nur um die Uncompress-Funktionen.

Wenn ich eine ZIP-Datei entpacke, dann interessiert mich beispielsweise, ob die jeweilige Datei entpackt wurde oder ob nicht. Ich überprüfe also auf Fehlerrückgabe ("0"). Auf welche Art und Weise eine Null-Byte-Datei in der ZIP-Datei gespeichert wurde sei mal nebensächlich - es kommt vor. Wenn nun beim Entpacken von Null-Byte-Dateien jedesmal ein Fehler gemeldet wird, obwohl die Datei korrekt "entpackt" wurde, dann kann ich den Rückgabewert so nicht gebrauchen.

Wenn man ein ganzes Verzeichnis packt, dann sind da ja auch diese Null-Byte-Dateien "enthalten" und nicht immer sind sie unerwünscht.

[ts-soft]

Das Problem ist, es gibt viele Verfahren, wie Fehler von Funktionen zurückgemeldet werden:
Einmal ist mit 0 alles okay, ansonsten enthält der Rückgabewert den Fehlercode, hierbei
können keine Werte direkt zurückgegeben werden.

Dann noch durch eine Fehlerfunktion, die extra aufzurufen ist. Usw.

PB verwendet: 0 = Fehler oder Ergebnis, <> 0 gleich Ergebnis.
Es erscheint Dir jetzt Sinnvoll, einen Minuswert zurückzugeben, der ja kein
erfolgreiches Ergebnis sein kann. Das würde das Händling in PB aber uneinheitlich
machen.
In Deinem speziellem Fall solltest Du also selber den Erfolg prüfen.

[Rudi]

Eine Möglichkeit wäre aber noch, eine Auswahlmöglichkeit per Flag zu geben, ob man die Dateigröße oder eventuelle Fehlermeldungen erhalten möchte.
Wenn das nicht realisierbar ist, wäre es besser, gar keinen Wert zurückzugeben. Eine Überprüfung muss ich dann ja, so oder so, selbst durchführen.