exakte dateigrösse herausfinden & effizientes laden/schreiben von dateien

[loki1985]

hi folks!

frage 1: wie kann ich die exakte grösse einer datei herausbekommen?

frage 2: ich habe ein programm, das mir eine datei nach einem selbsentwickelten containerformat erstellt. funktion: viele kleinere dateien werden zu einer grossen datei zusammengesetzt und eine index sowie platzhalter zwischen den teilen wird geschrieben.
wie kann ich die vielen kleineren dateien einladen? natürlich eine nach der anderen, aber lade ich die in einen string, oder wie? sie müssen vor allem binär eingelesen und wieder binär geschrieben werden.

thx in advance,

---loki

[Windalf]

zu 1)
datei binär öffnen, dateipointer mit fseek ans ende setzen und mit ftell die postion bestimmen, die dann gleichzeitig anzahl der bytes ist, datei schliessen

zu2)
wenn du die dinger sequentiell hintereinandere ballerst brauchst du gar nicht immer erst die komplette datei einlesen, reicht einen buffer zu nehmen... in den einlesen und in die neue datei schreiben, usw. bis die datei fertig ist, dann ab zur nächsten datei usw...

[Daniel E.]

Windalf schrieb:

datei binär öffnen, dateipointer mit fseek ans ende setzen und mit ftell die postion bestimmen, die dann gleichzeitig anzahl der bytes ist, datei schliessen

Das funktioniert nicht; die Norm warnt explizit in einer Fußnote davor. Wirklich sicher ist wohl nur, die Datei mit fgetc oder so durchzurattern, und warten, bis der EOF kommt. Das ist nur -- auf komischen Systemen und laut Norm -- nicht hinreichend, dafür, daß die Datei zu Ende ist, weswegen man nochmal mit feof nachsehen muss, ob die Datei auch wirklich fertiggelesen wurde. Ja, das ist häßlich, und vermutlich hatten die Erfinder von C sich das auch etwas anders vorgestellt.

[Windalf]

@Daniel E.
ups gut zu wissen, habs selber bisher nie verwendet. eigentlich braucht mans wenn überhaupt ja meist eh nur wenn man "unschöner weise" die komplette datei in den speicher ballern will (an statt sie stück für stück zu verarbeiten was meistens ja auch problemlos möglich ist) und im vorherein wissen will wie gross man das array macht, um sich realloc's zu sparen...

habs aber eben mal spassenhalber bei mir ausprobiert mit dem ftell und bei den von mir getesteten dateien gings... wo genau kann man da denn in welchem zusammenhang fehlerchen bekommen? (oder ist das ne macke eines bestimmten os und auf den anderen läuft es?)

[Daniel E.]

Windalf schrieb:

habs aber eben mal spassenhalber bei mir ausprobiert mit dem ftell und bei den von mir getesteten dateien gings... wo genau kann man da denn in welchem zusammenhang fehlerchen bekommen?

Das Problem ist nicht ftell sondern fseek(file, 0, SEEK_END) auf Binärströmen; das ist undefiniert (O-Ton: 'because of possible trailing null characters'). Normalerweise funktioniert's natürlich trotzdem.

[loki1985]

Daniel E. schrieb:

(O-Ton: 'because of possible trailing null characters').

wenn ich das richtig verstanden habe sollte es demnach im binär-modus keine probleme geben, sondern nur im ASCII-mode... oder?

[Daniel E.]

loki1985 schrieb:

Daniel E. schrieb:

(O-Ton: 'because of possible trailing null characters').

wenn ich das richtig verstanden habe sollte es demnach im binär-modus keine probleme geben, sondern nur im ASCII-mode... oder?

Nee, genau andersrum.
Es gibt Systeme (oder Geräte, von denen man gerne lesen möchte), die speichern Daten nur pro Block, wobei ein Block größer als ein Byte sein kann und wird. Bei einer gewöhnlichen Textdatei kann man also sehr gut die binäre Null benutzen, um das Dateiende innerhalb eines Blocks zu signalisieren; binär funktioniert das allerdings nicht, weil jedes Zeichen eine potentiell sinnvolle Bedeutung hat.