[4.10 Beta 2] LOF Bug bei WriteByte ????

[Donald]

Hier mal ein kleines Testprogramm.
Also wenn es kein Bug sein sollte warum dieses verhalten ?

Code: Alles auswählen

;Ich erstelle mal nur eine Testfile
CreateFile(0,"Testfile.txt")
For i = 1 To 10
  WriteStringN(0,"Diese ist ein Test, für den WriteByte-Bug")
Next i
CloseFile(0)
 
;So, damit hätten wir erst mal eine Testdatei
;Nun schaut mal was passiert
 
OpenFile(0,"Testfile.txt")
Debug "Aktuelle Filegröße vor dem ändern  = "+Str(Lof(0))
FileSeek(0,1)
WriteByte(0,Asc("e"))
WriteByte(0,Asc("i"))
WriteByte(0,Asc("n"))
Debug "Aktuelle Filegröße nach dem ändern = "+Str(Lof(0))
CloseFile(0)
 
; Und warum ist nun LOF() grösser als vorher ?

[Kaeru Gaman]

bug bestätigt in 4.02

habe folgendes angehängt:

Code: Alles auswählen

ReadFile(0,"Testfile.txt")
Debug "Filegröße nach erneutem öffnen = "+Str(Lof(0))
CloseFile(0)

dort stimmt die LOF angabe wieder....

eventuell findet für ein aktuell geöffnetes file ein mitschreiben statt, damit für die ermittlung von LOF nicht auf den datenträger zugegriffen werden muss.
die vorgehensweise ist zwar generell bei append mehr performant, aber bei overwrite produziert es fehler.

[ts-soft]

Das liegt an den gepufferten Funktionen, Lof stimmt nach dem öffnen, danach
ist es nicht mehr sichergestellt. Müßte man Close und FileSize nehmen

[PureLust]

Das liegt an den gepufferten Funktionen, Lof stimmt nach dem öffnen, danach
ist es nicht mehr sichergestellt.

Worin würde denn das Problem liegen, bei der Pufferung auch einen FileSeek() mit zu berücksichtigen?

[Kaeru Gaman]

Müßte man Close und FileSize nehmen

ich nehme mal an, du meinst oder

trotzdem.
wenn LOF nur beim öffnen aktualisiert würde, dürfte es sich nicht ändern.
es findet also tatsächlich ein "mitschreiben" statt, das auf append ausgelegt ist.

...darauf sollte dann in der Help ganz präzise bezug genommen werden.


> Worin würde denn das Problem liegen, bei der Pufferung auch einen FileSeek() mit zu berücksichtigen?

PB ist in erster linie auf schlankheit und performanz ausgelegt.
eine zusätzliche routine um FileSeek zu beobachten könnte das untergraben.

ja, es wäre schöner, wenn LOF immer aktuell wäre.
eventuell gibt es eine möglichkeit, das korrekt zu implementieren,
und dabei nur die LOF funktion langsamer zu machen....

soweit wie es im moment implementiert ist, wäre es nutzbar, wenn darauf explizit hingewiesen würde....

[PureLust]

> Worin würde denn das Problem liegen, bei der Pufferung auch einen FileSeek() mit zu berücksichtigen?

PB ist in erster linie auf schlankheit und performanz ausgelegt.
eine zusätzliche routine um FileSeek zu beobachten könnte das untergraben.

Momentan scheint es ja so zu sein, dass LOF() bei einem Write() einfach um die entsprechende Anzahl der Bytes hochgezählt wird - also ohne Berücksichtigung der aktuellen Schreib-Leseposition.
Einen Zeiger mitzuführen in dem sich die aktuelle Schreib-/Leseposition befindet und LOF() demendsprechend nur anzupassen wenn sich die Datei durch einen Write() vergrößern würde, täte der Performance wohl keinen allzu großen Abbruch.

soweit wie es im moment implementiert ist, wäre es nutzbar, wenn darauf explizit hingewiesen würde....

Jo.

[Kaeru Gaman]

yo genau.

ein ein faches erwähnen in der Help, dass LOF auf append ausgelegt ist
und nach FileSeek möglicherweise nicht mehr adäquat funktioniert,
wäre vorerst ausreichend.
eine zusätzliche ausführung über die genaue funktionsweise
wäre zwar wünschenswert, aber nicht dringend notwendig.

wie du, PL, sagtest, eine anpassung an genauere beobachtung des file-zeigers wäre nicht allzu schwierig,
aber es besitzt auch keine besondere priorität.


[bla]
ich meine, Freds intension ist in erster linie kürze und performanz.
insofern ist seine lösung durchaus nachvollziehbar.
eine anpassung halte ich auch nur bedingt für nötig,
da man ja LOF meistens im append-bereich verwenden wird.

natürlich, wenn man append und overwrite verwenden will, geht das nicht.
also um ein file-system zu proggen, was per FileSeek ans ende springt,
ist das nicht zuverlässig verwendbar....

aber auch eher eine frage der anpassung...

spingt FileSeek auch dann ans ende, wenn man einen zu hohen wert eingibt?

außer der beobachtung gibt es wohl kaum einen bedarf....

aber ja, es ist streng genommen ein bug.

(sorry für viel zu viele worte... ich bin halt auch soziologe aus leidenschaft..)

[ts-soft]

>> spingt FileSeek auch dann ans ende, wenn man einen zu hohen wert eingibt?
Gibt eine Debugger-Meldung. Ohne Debugger springt er über das Ende
hinaus, was auch nützlich sein kann, da man ja das Ende des Files per
TruncateFile() oder SetEndOfFile_() setzen kann.

Ich führe immer eigene Zähler mit, wenns tatsächlich mal hin und her geht

[nco2k]

wenn man GetFileSize_(FileID(0), 0) statt Lof(0) schreibt bzw. den buffer nach den schreiboperationen mittels FlushFileBuffers(0) entleert, dann funktionierts.

ich hoffe, dass der bug schnell behoben wird, denn was nützt uns eine unzuverlässige Lof() funktion?! ich hab den bug vermutlich bisher nicht entdeckt, weil ich sowieso immer den buffer flush.

ps: FileSize() ist eine andere geschichte, da es von windows abhängig ist, wann die daten tatsächlich auf die platte geschrieben werden und erst danach der korrekte wert sichergestellt werden kann: http://www.purebasic.fr/english/viewtopic.php?t=26350

c ya,
nco2k