Frage zu EOF unter Windows

[Aziz]

Nagut, obwohl ich das immer noch nicht schnalle habe ich folgende Frage:

Es ist ja bekannt, dass das Dateisystem die Dateien aufteilt (fragmentiert) wenn sie nicht durchgehend in die Cluster der Festplatte passen. Wie merkt sich das Dateisystem, wo die einzelnen Datenfragmente der selben Datei liegen?

[SideWinder]

In der Partition Table? Aber sicher nicht immer am Ende eines Teils

MfG SideWinder

[Aziz]

Das hört sich plausibel an

[Christoph]

Aziz schrieb:

Nagut, obwohl ich das immer noch nicht schnalle [...]

Nochmal anders formuliert: get() liefert die Daten byteweise. EOF passt aber nicht in ein Byte, deswegen kann es nicht zu den "Daten" gehören.

[Aziz]

Ok, ich versuche das wirklich zu verstehen, aber ich habe immer noch Fragen im Hinterkopf oder bin momentan einfach nur begriffsstutzig.

Noch mal zurück zu dem was du gesagt hattest:
**Das sind aber 4 Bytes, kein int. Die 4 Bytes "10000000 00000000 00000000 00000000" können natürlich auftreten, das hab ich nie bestritten

Der integer -1 (EOF) kann definitiv nicht auftreten, da get() niemals (außer eben bei EOF) etwas anderes als 0-255 zurückliefert.**

Wenn EOF nicht (int)-1 als 4 Byte (auf 32Bit Systemen) auf der Platte liegt, wie sieht das dann aus? Wenn get() die Datei byteweise einliest wie und wann merkt er, dass jetzt das Dateiende gekommen ist?

Nehmen wir an wir haben eine winzige Datei:

"00000110 00000110 00000110 11110111"

Nach '11110111' ist ja Dateiende. Wenn get() versuchen würde weiterzulesen, dann würde er doch nicht wissen, dass er jetzt kein Byte mehr einlesen müsste sondern ein EOF.

[Christoph]

Achso, jetzt versteh ich, was du meinst.

get() erkennt an den Einträgen im Dateisystem, wann das Ende der Datei erreicht ist. Dann liefert es (int)(-1) zurück.
In den Daten der Datei steht nichts dergleichen, dort ist das Ende nicht speziell markiert.

[Aziz]

Ok, sowas in der Richtung hatte ich schon vermutet

[Tolga]

Gut, scheint sinnvoll zu sein.
Dann wäre die Frage beantwortet.

[Christoph]

Tolga:
Interessanterweise gibt es doch eine Möglichkeit, Daten "hinter der Datei" zu verstecken.
Und zwar basieren die meisten Dateisysteme auf Clustern. Ein Cluster ist die kleinste logische Einheit auf der Festplatte.
Ein Cluster hat z.B. 4kb (das ist beim Formatieren einstellbar). Wenn eine Datei nun 1kb groß ist, werden 3kb verschwendet, um den Cluster vollzubekommen. Die Datei belegt also 4kb, obwohl sie nur 1kb groß ist. Deswegen ist die "Größe" einer Datei immer kleiner oder gleich groß wie ihre "Größe auf dem Datenträger" (schau dir die Eigenschaften einer beliebigen kleinen Datei an).

Die Mindestgröße jeder Datei auf dieser Festplatte beträgt also 4 Kilobytes, selbst wenn sie nur ein Zeichen enthält.
Logisch, dass bei großen Clustern und kleinen Dateien viel Platz verschwendet wird. Kleine Cluster erzeugen allerdings wieder andere Schwierigkeiten, weswegen man Kompromisse eingeht: NTFS bietet Clustergrößen von 512 bis 4096 Bytes.

In diesem verschwendeten Speicher am Ende fast jeder Datei lassen sich Daten unterbringen. Netterweise erscheinen diese Daten nirgends; sie belegen weder Speicher noch tauchen sie im Dateisystem auf. Sie existieren gewissermaßen gar nicht.
Natürlich gibt es keine Windows-Funktion, um direkt in diesen Speicher zu schreiben. Auf den ersten Blick würde ich vermuten, dass man selbst das Dateisystem analysieren und geeignete Stellen finden muss. Bei FAT32 sollte das machbar sein, bei NTFS wirds wohl etwas komplizierter (zumal es bei NTFS auch noch Ausnahmen gibt, kleinste Dateien belegen dort nämlich effektiv 0 Cluster).

Wenn man die Datei, hinter der die Daten versteckt sind, auf eine andere Partition/einen anderen Datenträger kopiert, werden die versteckten Daten allerdings nicht mitkopiert. Windows kennt die Daten ja nicht.

Alles in allem eine gute Methode, Daten (oder Code) vor unliebsamen Blicken zu schützen.
Ich meine von einem Virus gelesen zu haben, der genau das macht.
Ein Virenscanner kann nämlich prinzipbedingt nur die tatsächlichen Daten überprüfen, nicht diese versteckten.

[Irgendwer]

Viel mehr interessiert es mich warum es nicht geht?
Hängt es an der WINAPI, am Dateisystemtreiber oder wie oder was??

Vielleicht was ja einer doch etwas mehr...

Einen Terminator ist nicht die einzige Methode um die Länge einer Folge festzulegen. Hier ist ein Beispiel mit Strings ohne Nullterminator:

char*alloc_string(size_t num){
  int*mem=(int*)malloc(sizeof(size_t)+num);
  *mem=num;
  return (char*)mem;
}
#define free_string(str) free(str)
size_t string_size(const char*str){
  return *((size_t*)str);
}
char*string_begin(char*str){
  return str+4;
}
char*string_end(char*str){
  return str+4+string_size(str);
}
//...
for(char*pos=string_begin(str);pos!=string_end(str);pos+=1){
  //...
}

In den String kannst du jedes Zeichen packen und es klappt doch. Und was ist eine Datei anders als ein string auf der Festplate?

[Christoph]

Irgendwer schrieb:

Und was ist eine Datei anders als ein string auf der Festplate?

Das ist es nur aus Sicht des Anwenders. Das OS dagegen muss auch Dinge wie Fragmentierung und Blockgrößen berücksichtigen.