Kleine Erklärung für Anfänger

MBCS-CITP

c.rackwitz schrieb:

ihr scheints nicht zu begreifen, oder?

wenn ich eine datei ueberschreibe, dann oeffne ich diese, ohne die enthaltenen daten zu loeschen. dann schreibe ich so viele bytes in die datei, wie schon in der datei sind. dabei ueberschreibe ich die datei genau dort, wo auch die originalbytes liegen.

mit festplatte zumuellen oder sektoren finden hat das nicht im geringsten zu tun!
*argh!!*

Es geht darum, dass das Betriebsystem ueber das Filesystem den genauen physikalischen Ort auf dem Speichermedium (z. B. Festplatte) festlegt. Es gibt keine direkte Garantie, dass eine geoeffnete, ueberschreibe und wieder geschlossene Datei physikalisch am gleichen Ort des Speichermediums steht. Wenn das aber nicht der Fall ist, dann bleibt eine Spur der urspruenglichen Daten irgentwo im Speichermedium haengen - und das koennte z. B. bei einer forensischen Untersuchung gefunden werden.

Denke in diesen Zusammenhang mal an moderne File-Systeme, die Fragmentierungen vermeiden (ext3) auf einem Multi-Task-Betriebssystem. Keine Macht der Welt kann Dir garantieren, dass hinter dem Journal-Layer nicht den physikalischen Ort Deines Files verschoben wird, waerend Du ihn geoeffnet hast, da Du nie tiefer zugreifen kannst vom OS aus, nur weil ein anderer Prozess etwas mehr von dem Block benoetigt oder freigibt?

c.rackwitz

ich meine nicht truncate-and-write sonder ueberschreiben im sinne des wortes. ich ueberschreibe ein byte in der datei und damit auch genau die stellen, an denen die daten vorher lagen.
und damit du mich nicht nochmal falsch verstehst, ich weiss, was fragmentierung, clusterketten und journalling sind.

lege eine datei "foofile" an, in der "0123456789abcdef" steht. dann fuehre folgenden code aus.

FILE *f;
f = fopen("foofile","r+b");
fseek(f, 3, SEEK_SET);
fwrite("foobarbaz", 1, 9, f);
fclose(f);

alles klar?
wenn nicht, kann ich dir auch nicht mehr helfen.

im uebrigen gehe ich davon aus, dass eine datei fuer schreibzugriff gesperrt ist, wenn ich sie gerade beschreibe. deswegen halte ich es fuer unsinn, zu befuerchten, dass andere prozesse/threads an der datei rummachen, waehrend mein thread/prozess das auch tut.
ich hab auch mal kurz nach ext3 und fragmentierung gesucht. ich weiss jetzt, dass ext3 bereits geschriebene dateien nicht extra verschiebt, um zu defragmentieren. es haelt die cluster/sektoren nur nah beieinander und prealloziiert freie sektoren nahe der datei.

SG1

Und woher weisst Du, dass der alte Dateiinhalt nicht noch irgendwo auf der Platte ist?

SG1 schrieb:

Und woher weisst Du, dass der alte Dateiinhalt nicht noch irgendwo auf der Platte ist?

Das Dateisystem wird doch von ANSI C vorgegeben :p

*scnr*

FILE *f;
f = fopen("foofile","r+b");
fseek(f, 3, SEEK_SET);
fwrite("foobarbaz", 1, 9, f);
fclose(f);

Das dieser Code auf jeder Plattform in gleicher "Art und Weise" funktioniert, d.h.
Low-Level (Dateiinhalt noch igendwo vorhanden, vielleicht) weisst du ganz sicher
nicht.
Pro OS kannst du, was genau passiert, nur bei genauer Kenntnis des Filesystem
vorhersagen.

ihr scheints nicht zu begreifen, oder?

Es scheint, du bist derjenige der nicht begreift.

MBCS-CITP

@Rackwitz

Vielleicht war mein Beispiel mit ext3 wirklich nicht gut. Grundsaetzlich hast Du in C nur einen Pointer auf den File. Dieser Pointer wird vom Betriebssystem und/oder den Layern des Filesystems verwaltet. Grundsaetzlich kannst Du nicht sehen, wo und wie das verwaltet wird. Deshalb kann keine Aussage ueber den physikalischen Ort der Information im Speichermedium getroffen werden - zumindest keine die unabhaenig vom Betriebs- und Filesystem ist.

c.rackwitz

na wenn das so ist, dann koennen die ganzen "safe eraser" das auch nicht.
selbst wenn die teile also das dateisystem parsen und jeden cluster der datei einzeln loeschen, waere nicht garantiert, dass die daten weg sind.

ich wuerde es gut finden, wenn ihr mal praktisch denkt und mir beispiele gebt, wo das dateisystem wirklich so unvorhersehbar handelt.
ein laufendes system hat wohl weniger mit theorie als mit debugging zu tun.

c.rackwitz schrieb:

na wenn das so ist, dann koennen die ganzen "safe eraser" das auch nicht.

Wer sagt, dass die "Safe Eraser" die Standardfunktionen verwenden und nicht system-/dateisystemspezifische?

c.rackwitz

ok, erklaers mir fuer ganz dumme, bitte.
oder schick mich auf seiten oder gib mir stichworte fuer google.

ach und komm mir bitte nicht mir "das koennte ja so oder so sein". spekulationen nuetzen mir nichts.

c.rackwitz schrieb:

ok, erklaers mir fuer ganz dumme, bitte.

Nun, ich kann nur wiederholen was die anderen schon gesagt haben: Was wann und wo physikalisch auf der Festplatte geschrieben wird kannst du nicht mit den Sprachmitteln des ANSI Standard festlegen.

Aber vielleicht doch ein praktisches Beispiel: File A liegt fragmentiert auf der Platte. Du öffnest A und überschreibst es. Das OS/Filesystem findet es aber besser, die Datei unfragmentiert abzuspeichern und schreibt es an einen freien Ort und ändert lediglich die Einträge in der FAT.