SSD Secure Erase Dauer

Ich habe keine Werte zu aktuellen Flash-Chips im Kopf, aber vor Jahren 
lag die Grösse eines Erase-Blocks bereits bei 0,5 MB. Wenn ein 
Löschvorgang 2 Millisekunden benötigt, dann liegt man rein sequentiell 
bei 4 Sekunden pro GB. Die Blöcke werden mittlerweile wohl entsprechend 
grösser geworden sein, und die einzelnen Chips einer SSD können parallel 
gelöscht werden.

Oder sie löscht einfach den Schlüssel und generiert einen neuen.

Vermutlich wurde gar nichts gelöscht.

Eventuell verschlüsselt die SSD standardmäßig alle Sektoren und hat auf 
den Befehl zum "Secure Erase" hin gar nichts physisch gelöscht, sondern 
nur den Schlüssel vernichtet.

Damit kann man die Platte den Inhalt nicht mehr entschlüsseln.

Um zu beurteilen, ob ein stattlicher staatlicher Angreifer das 
vielleicht doch kann, müsste man die Firmware der Platte disassemblieren 
oder besser noch gleich den Quellcode durchlesen.

Du könntest mit einem Hexeditor versuchen, die Platte auszulesen.
Ist alles auf Null?

Ich bevorzuge sequentielles Löschen per Software.
Allerdings können die ATA-Eigenschaften wie "Secure Erase" eventuell 
noch mehr löschen, nämlich Sektoren, die man von Außen mit Bordmitteln 
nicht auslesen kann.

Peter M. schrieb:
> Um zu beurteilen, ob ein stattlicher staatlicher Angreifer das
> vielleicht doch kann,

Daten die ernsthaft vor staatlichem Zugriff geschützt werden sollen weil 
das persönliche Wohlergehen oder das Anderer davon abhängt verschlüsselt 
man lieber selbst und zwar mit einer Software der man vertraut. Alles 
andere ist Spielzeug.

Bissel im Web gegraben: Es scheint keine einheitliche Linie zu geben.

- Manche löschen auch den Inhalt, obwohl verschlüsselt wird. Allein 
schon, weil gelöschte Blöcke sofort überschrieben werden können, somit 
die Performance anschliessend wieder maximal ist.

- Manche ersetzen bloss den Schlüssel. Geht schneller, aber die Blöcke 
können dann noch nicht sofort überschrieben werden. Letztlich verlagert 
es die Löscherei auf später.

- Es soll auch welche geben, oder gegeben haben, bei denen das ganze 
Verfahren Augenwischerei ist und man hinterher trotzdem noch rankommt.

Bernd K. schrieb:
> Daten die ernsthaft vor staatlichem Zugriff geschützt werden sollen weil
> das persönliche Wohlergehen oder das Anderer davon abhängt verschlüsselt
> man lieber selbst und zwar mit einer Software der man vertraut. Alles
> andere ist Spielzeug.

Ja, sehe ich genauso.

A. K. schrieb:
> - Es soll auch welche geben, oder gegeben haben, bei denen das ganze
> Verfahren Augenwischerei ist und man hinterher trotzdem noch rankommt.

Ja. Es gibt keinen Grund den Festplattenherstellern zu vertrauen.

Paul schrieb:
> allerdings mit der Auflage, seine Daten zu löschen. Es geht also nicht
> darum, forensischen Untersuchungen zu trotzen.

In diesem Fall wird das Secure Erase ausreichen.

Peter II schrieb:
> also ob man heute irgendwelcher Software vertrauen kann. Wenn schon
> Paranoid dann bitte richtig.

Bitte zieh' Deinen Aluhut aus, bevor Du mit mir sprichst, damit nicht 
Dein Hut mit meinem zusammenstösst! :)

Über Deine Aussage bin ich enttäuscht.

Quellcodeoffene Software ist die Lösung.

Peter II schrieb:
> Also nur eigene Software ist sicher.

Eines ist sicher: Eigene Verschlüsselungssoftware ist unsicher.
Also wenn man nicht grad Bruce Schneier heisst, oder so.

Paul schrieb:
> SecureErase nach längerem Betrieb ohne
> TRIM auch eine Art "Frischzellenkur" darstellen kann

Dagegen hilft doch das simple Einschalten von TRIM, evtl vielleicht 
einmal manuell TRIMen, kein Grund deswegen gleich die ganze Platte zu 
löschen.

Bernd K. schrieb:
> kein Grund deswegen gleich die ganze Platte zu löschen.

Genau das war aber die Vorgabe.

A. K. schrieb:
> Eines ist sicher: Eigene Verschlüsselungssoftware ist unsicher.

Ja! Ich habe auch mal für private Zwecke einen Algorithmus geschrieben 
und den habe ich für ziemlich ausgefuchst gehalten.
Nach späterer Lektüre von Artikeln über Kryptologie kann ich über mich 
in diesem Punkt nur ganz herzhaft lachen.

> Also wenn man nicht grad Bruce Schneier heisst, oder so.

Nein!
Auch akademische Reputation schützt vor Kryptopleiten nicht.
Der Witz besteht in der gegenseitigen Prüfung der Machwerke, der auch 
z.B. anlässlich des AES-Wettbewerbs stattgefunden hat.

Peter II schrieb:
> Die Vergangenheit hat ja gezeigt, das Opensource 100% sicher ist.

Bist Du staatlicher Schnüffler und möchtest gerne mit der 
Microsoft'schen FUD-Strategie das Konzept von "Open Source" torpedieren, 
oder bist Du nur ein Troll?

Oder unterstellst Du anderen gerne Dinge, die sie nicht gesagt haben?

Egal, hier im Forum kannst Du Deine perversen Neigungen nach besten 
Kräften ausleben.

Peter II schrieb:
> aber nur weil es nicht genauer beschrieben wurde. Es sollten alle Daten
> unwiderruflich gelöscht werden.

Beachte die Präzisierung um 20:34. Nix unwiderruflich.

> Dafür ist ein überschreiben bei einer SSD nicht geeignet, weil man damit
> die Reserve Sektoren nicht erwischt.

Ein Secure Erase in den von ihm genannten gefühlten 10 Sekunden passiert 
garantiert nicht per Überschreiben. Was nahelegt, dass das Samsung-Tool 
verwendet wurde.

Peter M. schrieb:
>> Also wenn man nicht grad Bruce Schneier heisst, oder so.
>
> Auch akademische Reputation schützt vor Kryptopleiten nicht.

Klar. Aber für Laien stehen die Chancen doch noch ein klein wenig 
schlechter. Und grad der Experte wird das schon realistisch einschätzen, 
der braucht meinen Tipp nicht. ;-)

A. K. schrieb:
> Klar. Aber für Laien stehen die Chancen doch noch ein klein wenig
> schlechter.

Auf jeden Fall.

A. K. schrieb:
> Peter M. schrieb:
>>> Also wenn man nicht grad Bruce Schneier heisst, oder so.
>>
>> Auch akademische Reputation schützt vor Kryptopleiten nicht.
>
> Klar. Aber für Laien stehen die Chancen doch noch ein /klein wenig/
> schlechter. Und grad der Experte wird das schon realistisch einschätzen,
> der braucht meinen Tipp nicht. ;-)

Da hatte Fefe noch was die Tage... Von wegen Experten:
https://de.wikipedia.org/wiki/Magenta_(Algorithmus)
Telekom Beitrag zum DES-Nachfolger: "Die Kryptologen Adi Shamir und Ross 
Anderson fanden bereits während der 20-minütigen Präsentation des 
Algorithmus theoretische Angriffsmöglichkeiten. Kurze Zeit später 
bewiesen sie, dass dieser Angriff auch praktisch möglich und das 
Kryptosystem somit leicht zu brechen ist."

Paul schrieb:
> Habe hier eine Samsung 840 EVO mit 120 GB in gefühlt 10 Sekunden
> gelöscht, möglicherweise waren es nicht mal 10 Sekunden.

Wenn man mal in das Datenblatt eines Flash-ICs schaut, z.B. 
H27UAG8T2BTR-BC, dann dauert ein Block-Erase typisch 2,5ms und er 
enthält 512 Blöcke.
D.h. nach 1,3s ist der gesamte Flash gelöscht.
Und natürlich kann der Controller die Erase-Befehle an alle Flash-ICs 
gleichzeitig senden.

Schreiber schrieb:
> Dummerweise haben nur wenige CPUs einen echten Zufallszahlengenerator.
> Mir fallen hier nur die veralteten CPUs von VIA ein.

Intel enthält ab Ivy Bridge einen RdRand Befehl, AMD zog nach:
https://en.wikipedia.org/wiki/RdRand
http://electronicdesign.com/learning-resources/understanding-intels-ivy-bridge-random-number-generator#1
http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator

Davor war das bereits Teil des optionalen Trusted Platform Module (TPM).

Inwieweit man solchen Verfahren trauen will, oder doch lieber dem 
eigenen Aluhut (*), ist eine andere Frage. Der sich der Wikipedia 
Artikel auch widmet.

*: o tempora o mores. Galten früher Aluhüte als untrügliches Kennzeichen 
für Spinner, entwickeln sie sich zunehmend zum etablierten Element 
elektronischen Daseins.

Schreib doch ein 128GB File drauf:
dd if=/dev/random of=/dev/sdx bs=512M (x=Deine SSD)

Alternativ unter Windows große Dateien erzeugen und duplizieren.

Pete K. schrieb:
> Schreib doch ein 128GB File drauf:
> dd if=/dev/random of=/dev/sdx bs=512M (x=Deine SSD)

Hast du das mal ausprobiert? Die SSD ist eher zu Staub zerfallen als 
vollgeschrieben. /dev/random ist kein Performance-Wunder, da die Menge 
an Entropie begrenzt ist. Besonders in virtuellen Umgebungen, in denen 
es schon etliche Minuten dauert, einen 4Kbit-RSA-Key da rauszuzupfen.

Wenn schon, dann /dev/urandom.

Aber dieses Verfahren ist bei SSDs nicht wirklich sinnvoll, jedenfalls 
wenn man es ernst meint, da aufgrund der Technik von SSDs nicht 
gewährleistet ist, dass wirklich alle Daten überschrieben werden.

Es geht ja nur darum, die Platte mit neuen Werten zu beschreiben, damit 
die alten Daten auch wirklich überschrieben werden.
Ob man da random oder null oder etwas anderes nimmt ist völlig egal.

Wichtig ist nur, dass die Platte ausreichend vollgeschrieben wird. Dann 
sind auch sicher die alten Daten komplett gelöscht.

Peter II schrieb:
> Pete K. schrieb:
>> Wichtig ist nur, dass die Platte ausreichend vollgeschrieben wird. Dann
>> sind auch sicher die alten Daten komplett gelöscht.
>
> genau das ist bei einer SSD nicht der Fall.
>
> Reservesektoren kann man mit überschreiben nicht erreichen. Später
> werden sie von der Firmware eventuell wieder sichtbar gemacht und dann
> sind ein teil der Daten wieder da.

HDDs haben ebenfalls Reserve-Sektoren.

Peter II schrieb:
> Reservesektoren kann man mit überschreiben nicht erreichen. Später
> werden sie von der Firmware eventuell wieder sichtbar gemacht und dann
> sind ein teil der Daten wieder da.

"wieder sichtbar gemacht":
Wie soll das bitte funktionieren?
So ein Vorgang ist technisch gesehen sinnlos.

Reservesektoren sind jungfräulich und mit Festplattenkauf unbeschrieben.
Sie enthalten keine Benutzerdaten.

Nach meinem Verständnis werden Sektoren, die nicht mehr beschreibbar 
sind, auf einen dieser Reservesektoren umgeroutet.

Ab diesem Moment ist so ein Sektor für das Betriebssystem auch 
erreichbar.
Bei einer Löschaktion durch Nullen oder Überschreiben mit irgendeinem 
Wert wird so ein "ersetzter" Sektor auch überschrieben.

Es gibt also nur jungfräuliche versteckte Reservesektoren oder 
zugängliche in Benutzung.

Ein Sektor der nicht mehr lesbar ist, ist eventuell noch mit einem 
Schreibvorgang wieder benutzbar.
In diesem Fall wird kein Reservesektor in Anspruch genommen.

Erst wenn der Schreibvorgang scheitert, muss der Sektor ersetzt werden.

Interessant sind die nicht mehr beschreibbaren Defektsektoren und die 
hängenden Sektoren, also solche, die nicht mehr lesbar sind.

Ob ein Labor solche hängenden oder ersetzten Defektsektoren wohl 
auslesen kann?

Peter M. schrieb:
> Nach meinem Verständnis werden Sektoren, die nicht mehr beschreibbar
> sind, auf einen dieser Reservesektoren umgeroutet.

Für Flash ist das eine reichlich bescheuerte Idee. Denn damit ist die 
Mehrheit der Sektoren schon stark belastet, wenn sie durch jungfräuliche 
Sektoren ersetzt werden. Da die anderen Sektoren aber auch schon alt 
sind, reichen deine Reservesektoren nicht aus und du hast schnelle 
Totalausfälle bei gleichzeitig verschwendetem Flash.

Wear-Levelling basiert auf der Idee, dass die Schreibzugriffe durch den 
gesamten Flash (inklusive der Reservesektoren) wandern. Damit altert 
jeder Sektor ungefähr gleich schnell.

S. R. schrieb:
> Peter M. schrieb:
>> Nach meinem Verständnis werden Sektoren, die nicht mehr beschreibbar
>> sind, auf einen dieser Reservesektoren umgeroutet.
>
> Für Flash ist das eine reichlich bescheuerte Idee. Denn damit ist die
> Mehrheit der Sektoren schon stark belastet, wenn sie durch jungfräuliche
> Sektoren ersetzt werden. Da die anderen Sektoren aber auch schon alt
> sind, reichen deine Reservesektoren nicht aus und du hast schnelle
> Totalausfälle bei gleichzeitig verschwendetem Flash.
>
> Wear-Levelling basiert auf der Idee, dass die Schreibzugriffe durch den
> gesamten Flash (inklusive der Reservesektoren) wandern. Damit altert
> jeder Sektor ungefähr gleich schnell.

Danke für den Hinweis, S.R.,

ich war mental bei herkömmlichen Platten. Inhaltlich kann ich Dir nicht 
widersprechen.

Damit hat aber auch der von mir oben kritisierte Peter II wieder Recht!

Dank Wear-Levelling können noch funktionierende Sektoren dem 
Betriebssytem entzogen werden und der Zugriff auf ein Datenduplikat 
umgeroutet werden.

Peter II schrieb:
> Reservesektoren kann man mit überschreiben nicht erreichen. Später
> werden sie von der Firmware eventuell wieder sichtbar gemacht und dann
> sind ein teil der Daten wieder da.

Ach, und diese Reservesektoren binden sich auch gleich ins Dateisystem 
ein und zeigen einem die alten Dateien?
Das möchte ich sehen.

Ich halte das Risiko der von mir beschriebenen Methode im privaten 
Umfeld für ausreichend.

Zitat des TO: "Es geht also nicht darum, forensischen Untersuchungen zu 
trotzen."

Planlos schrieb:
> Nein. Flash-Controler komprimieren gerne.

Tun sie das wirklich? Ich glaube nicht.

Bei meiner SSD merke ich keinen Performance-Unterschied zwischen 
Nullbytes und Datenbytes, und zumindest bei SD-Karten laufen die Daten 
am Flash-Controller vorbei, nicht hindurch. Letzterer kümmert sich um 
die Verwaltung, nicht um Kompression.

Außerdem ist "Nullbytes schreiben" eine äußerst seltene Anwendung, da 
wird nicht drauf optimiert (im Gegensatz zu bestimmten Dateisystemen).

Onkel Hotte schrieb:
> Dieser Sandforce-Müll macht das.

Ich hätte gedacht, dass niemand so bescheuert wäre, aber nun gut...

Onkel Hotte schrieb:
> S. R. schrieb:
>> Planlos schrieb:
>>> Nein. Flash-Controler komprimieren gerne.
>>
>> Tun sie das wirklich? Ich glaube nicht.
>
> Dieser Sandforce-Müll macht das.

Wie soll das denn eigentlich überhaupt sinnvoll gehen? Nehmen wir an ich 
hab ne Datei die unkomprimiert in 1000 Sektoren passt, komprimiert passt 
sie in 842 physikalische Sektoren, 158 Sektoren gespart. Aber welche? 
Nehmen wir an ich will jetzt logischen Sektor 500 lesen, zwölf Bytes 
davon ändern und den Sektor wieder schreiben. Dabei wird er nach 
Kompression zufällig größer. Physikalisch liegt der in komprimierter 
Form vielleicht irgendwo ab Mitte Sektor 421 und ging vorher bis erstes 
Drittel Sektor 422. Nach der Änderung würde er 8 Byte länger werden. Wo 
schreibt er den jetzt hin? Und wo merkt er sich daß die zweite Hälfte 
von 421 und das erste Drittel von 422 jetzt belegter aber unbenutzbarer 
Platz ist? Und welchen Vorteil soll dieser Monster-Overhead bringen?

Vorteil von Komprimierung: Höhere Schreibrate, niedrigere 
Flash-Abnutzung.

Bernd K. schrieb:
> Wie soll das denn eigentlich überhaupt sinnvoll gehen? Nehmen wir an ich
> hab ne Datei die unkomprimiert in 1000 Sektoren passt, komprimiert passt
> sie in 842 physikalische Sektoren, 158 Sektoren gespart. Aber welche?

SSDs sind aufgrund ihrer Arbeitsweise sowieso nicht 1:1 von Blocknummer 
auf Flash-Platzierung gemappt. Da lässt sich auch Komprimierung mit 
einbauen.

> Nehmen wir an ich will jetzt logischen Sektor 500 lesen, zwölf Bytes
> davon ändern und den Sektor wieder schreiben. Dabei wird er nach
> Kompression zufällig größer. Physikalisch liegt der in komprimierter
> Form vielleicht irgendwo ab Mitte Sektor 421 und ging vorher bis erstes
> Drittel Sektor 422. Nach der Änderung würde er 8 Byte länger werden.

Flash-Daten werden nicht direkt überschrieben. Das ist technisch 
unmöglich. Wird ein Sektor neu geschrieben, dann landet er woanders, in 
einem noch ganz oder teilweise gelöschten Erase-Block. Die Metadaten in 
der SSD sorgen dafür, dass man ihn dort auch findet. Das skizzierte 
Problem entfällt deshalb.

Einen schlechten Ruf verdienten sich die Sandforce-Controller 
massgeblich aufgrund der teilweise exorbitanten Ausfallrate einiger 
SSD-Baureihen von OCZ.

A. K. schrieb:
> Flash-Daten werden nicht direkt überschrieben. Das ist technisch
> unmöglich. Wird ein Sektor neu geschrieben, dann landet er woanders, in
> einem noch ganz oder teilweise gelöschten Erase-Block. Die Metadaten in
> der SSD sorgen dafür, dass man ihn dort auch findet.

Und was ist mit den beiden angefangenen halben Sektoren?

> Das skizzierte
> Problem entfällt deshalb.

Das akzeptiere ich nicht. Erst wenn Du mir erklärst wie man bei obigem 
Szenario den ganzen entstehenden Verschnitt recyclen kann ohne entweder 
den ganzen nachfolgenden Rest der Datei ab dem geänderten Sektor neu zu 
komprimieren oder in erheblich kleineren physikalischen Einheiten zu 
addressieren ohne daß der dabei entstehende Mehraufwand an 
Verwaltungsdaten die Komprimierung zunichte macht.

Am Besten Du erklärst mir anhand meines Beispiels von oben was dann 
wirklich in der Festplatte ablaufen würde und wieviel Ersparnis dann 
tatsächlich noch übrig bleibt (in Anbetracht der zusätzlichen 
Verwaltungsdaten) wenn frei werdende einzelne Fragmente von Sektoren 
oder Sektoren beliebig kleiner Länge (nach Kompression) noch sinnvoll 
den Platz ausfüllen können sollen.

Bernd K. schrieb:
> Das akzeptiere ich nicht.

Es bleibt dir überlassen, die Erde für eine Scheibe zu halten, die von 
Elefanten getragen wird.

Tatsache ist, dass die Sandforce-Controller recht wirkungsvoll 
komprimierten. Das wurde nicht nur behauptet, sondern anhand des 
Verhalten abhängig von der Art der Daten nachgewiesen.

> Erst wenn Du mir erklärst

Ich habe keinen Einblick in die Firmware dieser Controller. Meine 
Phantasie reicht aber aus, es für möglich zu halten. Auch ohne dir dafür 
ein Beispielprogramm zu schreiben. Wobei ich es für durchaus möglich 
halte, dass bei nichtsequentiellem Schreiben kleiner Einheiten 
Flash-Controller mit Komprimierung schlechter dastehen als welche ohne, 
weil vielleicht etwas mehr am Rand darum herum mitgenommen werden muss.

Beachte, dass es bei die SSDs mit komprimierenden Controllern nicht 
darum geht, mehr Daten unterzubringen. die Kapazität wächst dadurch 
nicht. Aber der mindestens der sequentielle Durchsatz steigt, wenn die 
Daten gut komprimierbar sind. Entstehende "Löcher" zwischen internen 
Organisationseinheiten bleiben dabei einfach ungenutzt.

Peter II schrieb:
> Spare files sind doch eher die Seltenheit.

Nicht für mich. Bei Container-Files von VMs ist das die Regel. Solche 
Systeme profitieren erheblich davon, dass VMs weit mehr Platz zugeordnet 
wird, als sie tatsächlich schreiben. Der ungenutzte Rest existiert dann 
nur in Form adressierbarer aber nicht existenter Blöcke.

oszi40 schrieb:
> Erst wenn Du
> irgendwas.txt >> test.txt anhängst, macht das System eine echte Datei
> daraus und füllt die Platte.

Selbst dann nicht. Spare Files werden nicht "alles oder nichts" 
verwaltet, sondern in Sektoren, Blöcken oder was auch immer an 
Einheiten. Hängst du da echte Bytes hinten dran, wird nur dort dieser 
Platz wirklich geschrieben. Der Rest bleibt unverändert imaginär.

Das funktioniert auch unter Windows. Man kann Files beliebiger Grösse 
anlegen, ohne dass dabei mehr als nur die Metadaten real auf Disk 
geschrieben werden. Wenn man den nie geschriebenen Kram liest kriegt man 
Nullen - in sagenhaftem Tempo.

Interessant wird das bei Backups. Reine Bytekopien können solche Files 
auf dem Ziel vollständig aufblasen, wenn das Backup-Programm nicht 
hinter die Kulissen schaut.

Interessanter ist die Frage, ob den imaginären Bereichen solcher Files 
bereits Platz zugeordnet wird, oder ob das erst dann geschieht, wenn sie 
tatsächlich Inhalt kriegen. In letzterem Fall kann eine Platte platzen, 
wenn man alle eigentlich längst eingeplanten Blöcke auch wirklich 
verwendet.

Peter II schrieb:
> das macht vm-ware aber auch ohne Spare files.

Bei NFS Datastores verlässt sich VMware auf die entsprechende Fähigkeit 
des Storage-Systems.

Peter II schrieb:
> Wenn es nicht gerade im SSDs geht, haben spare files auch Nachteile. Sie
> fragmentieren ja nach Wachstum. Bei uns werden VMs gleich mit voller
> Größe angelegt damit hat man (angeblich) später eine bessere Performace.

Es gibt für beide Strategien ein für und wider. Hab beides.

Verwendet man VMFS Filesysteme auf klassischen SAN-LUNs, dann kann eine 
Fragmentierung des Filesystems von VMware schon eine Rolle spielen. 
Allerdings überschaubar, möchte ich annehmen, denn die 
Allokationseinheiten von VMFS sind mindestens 1MB gross.

Verwendet man allerdings eine NetApp als Datastore, die zwar auch LUNs 
anbieten kann, aber diese auch bloss als Container auf ihre eigenen 
Files abbildet, dann fragmentiert das in jedem Fall. Egal ob thin oder 
thick. Die kann dank ihres COW-Filesystems nicht anders.

Andererseits kann sie aber auch im Hintergrund defragmentieren, und da 
ist es vor grossem Vorteil, wenn die Container-Files der VMs auch 
tatsächlich einzelne Files auf der NetApp sind. Was bei NFS der Fall 
ist. Und dann hat eine vollständige Allokation einzig den Vorteil, dass 
der Datastore nicht platzen kann.

Peter II schrieb:
> das macht vm-ware aber auch ohne Spare files.
>
> Wenn es nicht gerade im SSDs geht, haben spare files auch Nachteile. Sie
> fragmentieren ja nach Wachstum. Bei uns werden VMs gleich mit voller
> Größe angelegt damit hat man (angeblich) später eine bessere Performace.

"spare files" sind etwas anderes als "sparse files".
Sicherlich meinst Du "sparse files", aber dann schreibe den Begriff auch 
so!

oszi40 schrieb:
> 2.Was ist, wenn die neue Datei nur WENIGE Zeichen beinhaltet und den
> Cluster nicht ganz füllt? Wird der Rest immer zuverlässig gelöscht?

Unter Windows XP gar nicht. Deswegen bietet Eraser die Funktion des 
Löschens von "Cluster tips".

Hast Du die Rechte auf Clusterebene zuzugreifen, kannst Du diese Reste 
auslesen.