Das scheint auch nicht zu funktionieren. Hatte auch schon mit Set("FileMode", N)
rum gespielt. Früher gab es mal in Turbo Pascal den Befehl TRUNCATE, der eine
angebene Anzahl Bytes hinten an der Datei abschnitt. Wenn man vorher durch geschicktes
Umsortieren den zu löschenden Datensatz ans Ende schob, wurde der dann gelöscht.
Wenn man denn auch ein richtiges FileHandle hätte, könnte man mit der Kernel32.dll
und der File-Api das End Of File neu setzen. Geht aber wegen des echten fehlenden Handle
nicht. Es gibt ja nur Kanal-Nummern von 1-99. Auch die Funktion Assign() gibt nur eine
solche zurück. Und alle Dateioperationen mit API machen, möchte ich auch nun wieder nicht.
Ich vermute mal, daß RGH einen profaninternen Speicher nicht freigibt, bzw. beim
wiederholten Schreiben nicht dementsprechend neu dimensioniert. Somit bleiben auch
Reste, wenn der neu zu schreibende Bereich, den wir dann neu dimensionieren, halt
kleiner, als der alte profaninterne ist. Ob RGH vergessen hat, dies zu berücksichtigen,
oder ob es gar nicht vorgesehen war, bleibt halt offen. Wir haben ja mehrer Bereiche,
wie RegEx, Json, openGL usw., die nur rudimentär implementiert sind.