Datei sicher löschen

[himitsu]

wenn man genauer sucht, dann findet man bestimmt sogar meinen alten Shreder-Code hier irgendo, welcher auch nicht grad auf dem "aktuellen" Wissensstand ist

Zitat:

// zuerst umbennen, dann später keine Rückschlüsse auf den Dateinamen möglich sind

du weißt aber, daß NTFS sich dennoch den alten Namen merkt?

Bei meiner Datenplatte mit 16-KB-Clustern würde zu 50% was vom Slack-Space übrig bleigen,
bei meiner Systemplatte mit nur 4 KB würde zu 50% mehr, als nötig überschrieben und beim USB-Stick zu 93%, da nur 0,5 KB.

Zitat von oki:

@himitsu: das ist jetzt aber nicht fair Mich so ins Aus zu schicken. Wie ermittel ich die unalokierten Cluster?

ja wie nur ... bei FAT und NTFS könnte man sich das Volumebitmap laden,
und da drin nachsehn.
dann brauchst du noch direkten Schreibzugriff auf den Datenträger, was mindesten Adminrechte verlangt

aber solange du dich nicht mit dem Aufbau der Dateisysteme auskennst, weißt du dann immernoch nicht, welche Sektoren nun zu löschen sind

Zitat von oki:

Was ist, wenn ich Dateien mit geringerer Länge habe?

idealer Weise besorgst du dir die Clustergröße und rundest deine Dateigröße auf das nächste Vielfache davon auf ... ich glaub das konnte mein alter Code schon ... falls den wer findet

[Fridolin Walther]

Zitat von shmia:

Delphi-Quellcode:

const
  Fillchars: array[0..5] of char = (Char($00), Char($FF), Char($00), Char($F0), Char($0F), Char($00));
  BLOCK_SIZE = 8096;
var
   fs : TStream;
   buffer : String;
   i, j : Integer;
begin
   fs := TFileStream.Create(filename, fmOpenReadWrite or fmShareExclusive);
   try
      // Datei auf nächste Blockgrösse verlängern, damit der "Slack" überschrieben
      // wird
      fs.Size := ((fs.Size div BLOCK_SIZE) +2) * BLOCK_SIZE;

Sehr unschöne Lösung, vorallem weil Cluster durchaus größer als 8 KB sein können. Es wäre besser zur Laufzeit die Cluster Größe auf dem Laufwerk zu ermitteln, auf dem geschrieben werden soll: GetDiskFreeSpace

[oki]

Zitat:

Zitat:
// zuerst umbennen, dann später keine Rückschlüsse auf den Dateinamen möglich sind

du weißt aber, daß NTFS sich dennoch den alten Namen merkt?

Nein wußte ich nicht und der Code kommt nicht von mir (Gott sei Dank).

Solange die Datei sicher gelöscht ist kann man zur Not damit leben. Sollte sich da noch ein Weg finden lasse, so währe es dann aber konsequent.

Zitat:

oki hat folgendes geschrieben:
@himitsu: das ist jetzt aber nicht fair Rolling Eyes Mich so ins Aus zu schicken. Wie ermittel ich die unalokierten Cluster?


ja wie nur ... bei FAT und NTFS könnte man sich das Volumebitmap laden,
und da drin nachsehn.
dann brauchst du noch direkten Schreibzugriff auf den Datenträger, was mindesten Adminrechte verlangt

aber solange du dich nicht mit dem Aufbau der Dateisysteme auskennst, weißt du dann immernoch nicht, welche Sektoren nun zu löschen sind

Die Dateien, die bei mir zu löschen sind werden nur für die aktuelle Sitzung auf den Datenträger kopiert und sollen bei Beenden des Programms sicher gelöscht werden. Somit gehe ich davon aus, dass ich das Verschieben der Dateien nicht berücksichtigen brauch. Ich will auch ehlich sagen, dass mir an der Stelle der Aufwand zu übertrieben scheint.

@0x...irgendwas:
Dank für den Hinweis auf GetDiskFreeSpace. Mir schwante schon so was. Um das Thema werd ich mich auf jeden Fall kümmern. Wenn ich schon den Slack Space mit lösche, dann ordentlich.

Ich bin für jede weitere Anregung dankbar. Entscheidend ist für mich nicht die Kürze des Codes, sondern dass die Funktion ordentlich umgesetzt ist.

Dank und Gruß oki

PS: Nicht, dass sich jemand wundert, ich will erst Infos sammeln und dann Coden. Ich werde aber auf jeden Fall die fertige Funktion hier posten.

[OldGrumpy]

Zitat von 0xF30FC7:

Der Einfachheit halber belegen Dateien bei den meisten Dateisystemen immer eine ganze Anzahl an Clustern (Cluster -> eine Ansamlung von Sektoren). Bei NTFS ist die Clustergröße normalerweise 4 KB (also 8 Sektoren). Also wenn eine Datei nur ein Byte groß ist, belegt sie trotzdem einen Cluster und somit 4 KB. Angenommen die Datei war irgendwann mal größer und wurde dann verkleinert, so befinden sich im Rest des letzten belegten Clusters (Slack Space) noch immer die Daten die dort mal waren. Entsprechend musst Du sicher stellen, daß Du bei Dateien deren Größe nicht zufällig durch die Clustergröße teilbar ist, auf die nächste Clustergrenze aufrundest.

Bei NTFS ist das ganze nochmal eine Nummer trickreicher: Files die kleiner als ein Cluster sind, werden innerhalb der MFT abgelegt. Sobald du da dann nachträglich was anfügen willst, wird ein neuer leerer Block reserviert und der ganze Inhalt umgelagert.

[himitsu]

Zitat von OldGrumpy:

Bei NTFS ist das ganze nochmal eine Nummer trickreicher: Files die kleiner als ein Cluster sind, werden innerhalb der MFT abgelegt. Sobald du da dann nachträglich was anfügen willst, wird ein neuer leerer Block reserviert und der ganze Inhalt umgelagert.

ich glaub vor kurzem gelesen zu haben, daß es 1050 Byte sind, also nichtmal ein ganzer Cluster

aber wenn es eh "einfach" sein soll und die betreffenden Dateien nicht verkleinert werden, dann würde es ausreichen, wenn die Dateien in ihrer aktuellen Dateigröße einfach einmal komplett mit 0 überschrieben werden und dabei der Slack Space ignoriert wird, denn da steht ja eventuell nur was "wichtiges" drin, wenn die Datei verkleinert wurde


PS: ich erwähne jetzt hier lieber nicht noch die Sparse-Dateien, komprimierten Dateien, die Junctions und was es sonst noch im NTFS gibt

[oki]

Zitat von OldGrumpy:

Bei NTFS ist das ganze nochmal eine Nummer trickreicher: Files die kleiner als ein Cluster sind, werden innerhalb der MFT abgelegt. Sobald du da dann nachträglich was anfügen willst, wird ein neuer leerer Block reserviert und der ganze Inhalt umgelagert.

Bleibt dann der originale "kleine" Bestandteil der Datei in der MFT? Und wie bekomme ich den da weg?

Dank für deinen Beitrag OldGumpy und Gruß

oki

[himitsu]

die MFT auslesen, direkten Zugriff auf Datenträger erlangen, MFT suchen, alle Mapping-LCNs der MFT besorgen, die MFT nach der Datei durchsuchen, die Position in der MFT berechnen, über die LCNs die Postition auf der Platte bestimmen und dann da löschen


Legst du die Dateien selber an?
dann reservier Anfangs volle ihre Dateigröße und schreib erst danach die Daten da rein.

bzw. müssen die Dateien unbedingt auf den Datenträger?
notfalls direkt im RAM behalten.



PS: vergiß nicht, wenn du die Dateien verarbeitest und etwas da rauslädst, dann könnten diese Daten über die Auslagerungsdatei auch auf der Platte landen.


Datensicherheit ist schon ein schlimmes Thema

[oki]

Zitat von himitsu:

Datensicherheit ist schon ein schlimmes Thema

Vorallem, wenn man das liest.

Ich erstelle die Dateien nicht, leider. Ich entpacke sie und speichere sich temporär zwischen. Z.B. um sie durch eine Anwendung zu öffnen. Somit hab ich erst mal keinen Einfluss auf die Länge. Der Rest wird mir dann aber nicht erpart bleiben. Das Thema Auslagerung uf die Platte ist mir noch gar nicht in den Sinn gekommen
Noch ne Baustelle.

Thema nur in den RAM laden. Würde ich gerne, das Problem ist aber, dass die Dateien durch externe Anwendungen geöffnet werden sollen (Word, AcrobatReader, IE etc.). Bis jetzt habe ich noch nichts gefunden, was das Laden einer Datei in eine Anwendung ermöglicht, ohne diese als physisches File zur Verfügung zu stellen. Ich denke mal RAM fällt damit aus, so schön es auch sein könnte.

Gruß oki

[isilive]

Ich hab die erste Version mal weitergeschrieben und das ganze läuft sehr gut - mit AssignFile.
Hat ein "Filestream mit fs.WriteBuffer" Vorteile gegenüber "AssignFile und Blockwrite"? (Performance?)
Kann ich bei AssignFile auch ein FlushFileBuffers umsetzen (Dazu brauch ich aber ein Filehandle) ?

Delphi-Quellcode:

  
AssignFile(f, Name3);
Reset(f, 1);
...
Buffer[j] := random(256);           //Buffer mit Random Data füllen
BlockWrite (f, Buffer, Buffersize);

Delphi-Quellcode:

fs := TFileStream.Create(filename, fmOpenReadWrite or fmShareExclusive);
...   buffer := StringofChar(Fillchars[i], BLOCK_SIZE);
...   fs.WriteBuffer(buffer[1], BLOCK_SIZE);
...   FlushFileBuffers(fs.Handle);

[XoRiC]

Der Thread ist zwar nun 2 Monate alt, aber falls es noch von Interesse ist siehe hier.

Gruß Xoric