Dateien ohne Inhalt (leere Dateien) finden

[himitsu]

Joar, ich kenn das.
Hatte vor Jahren mal beim Backup probleme bekommen, wo es mir auch noch die Backupplate zerschoß.

Bei der Datenwiederherstellung und vorallem nach Checkdisk waren dann plötzlich viele Dateien 0 Byte groß und oftmals waren ganze Dateien oder nur einer/mehrere Cluster innerhalb von Dateien mit 0 gefüllt.
Hatte mir da auch ein suchprogrämmchen geschrieben, aber ich glaub das Progrämmchen hab'sch inzwischen gelöscht.

[Bummi]

Delphi-Quellcode:

implementation
{$R *.dfm}

type
 TBuff=Array[0..1023] of Byte;
var
 EmptyBuff:TBuff;

procedure TForm6.Button2Click(Sender: TObject);
var
 fs:TFileStream;
begin
   fs:=TFileStream.Create('C:\temp\log.txt',fmCreate);
   fs.Write(EmptyBuff[0],200);
   fs.Free;
end;

procedure TForm6.FormCreate(Sender: TObject);
begin
  ZeroMemory(@EmptyBuff[0],1023)
end;

Function FileIsEmpty(fn:String):Boolean;
var
 fs:TFileStream;
 Buff:TBuff;
 read:Integer;
 i:Integer;
begin
  ZeroMemory(@Buff[0],1023);
  fs:=TFileStream.Create(fn, fmOpenread);
  try
  read := fs.Read(Buff[0],1024);
  Result := true;
  for I := 0 to read-1 do Result := Result and  (EmptyBuff[i]= Buff[i]);

  finally
    fs.Free;
  end;
end;

[Schwedenbitter]

Zitat von himitsu:

Joar, ich kenn das.
Hatte vor Jahren mal beim Backup probleme bekommen, wo es mir auch noch die Backupplate zerschoß.

Bei der Datenwiederherstellung und vorallem nach Checkdisk waren dann plötzlich viele Dateien 0 Byte groß und oftmals waren ganze Dateien oder nur einer/mehrere Cluster innerhalb von Dateien mit 0 gefüllt.
Hatte mir da auch ein suchprogrämmchen geschrieben, aber ich glaub das Progrämmchen hab'sch inzwischen gelöscht.

Dann muss ich doch mal ausholen:

Mein Fileserver basiert auf openSUSE 11.4 mit Samba. Das Filesystem ist laut fsck in Ordnung. Die Dateien sind bemerkenswerter Weise auf nicht 0 Bytes groß. Dass wäre unter Linux ohne Verrenkungen ein Einzeiler mit dem schönen Befehlt grep.

Nach dem Crash haben die Dateien dieselbe Größe. Nur eben alles voller sinnloser Nullen. Den Code muss ich noch etwas ändern. Ich habe gerade festgestellt, dass iso-Dateien am Anfang auch "leer" sind und erst nach ca. 32KB etwas sinnvolles kommt. Ich habe daher meinen Puffer mal sicherheitshalber auf 524288 Bytes erhöht. Das kostet nicht soviel Zeit, macht aber die Ergebnisse sicherer.

Die ersten Durchläufe sind Dank Eurer Hilfe schon erledigt. Ich weiß jetzt, dass ich eine Menge Datenmüll habe. Glücklicherweise hat aber mein Backup-Server das getan, was er tun soll, nämlich die laufenden Daten zu sichern. Dass mein wöchentliches Backup Schrott ist, kann ich damit verkraften. Zudem ist der Crash am Wochenende passiert, so dass nicht soviel Daten betroffen sind. Arbeit macht es trotzdem.

Soll ich das fertige Produkt nochmal hochladen, für den Fall, dass eines fernen Tages jemand dasselbe Problem hat?

Gruß, Alex

[himitsu]

Dateisysteme sind ja oftmals in Cluster aufgeteilt.

Wenn bei der Reparatur ein Cluster nicht gelesen werden kann, oder wenn die Vrlinkung der Cluster nicht mehr korrekt ist, dann ersetzen viele Reparaturprogramme diese Cluster durch "Neue", welche eben "leer" sind.

Darum hatte ich mein Programm eben auch so geschrieben, daß jeder Cluster einzeln geprüft wird (bzw. mehrere Cluster einlesen, aber auch einzeln prüfen, damit es schneller geht).
Wenn die Festplate selber defekt ist/war, dann sollte man besser Anhand der Sektorgröße prüfen. (z.B. 512 Byte bei HDDs und Speicherkarten / 4 KB bei CDs und DVDs)

[hathor]

@Schwedenbitter

Ich habe den Eindruck, dass Du nur Symptome suchst und Dir den HDD-Inhalt "schön kopierst".
Ob die Daten nicht korrupt sind, erfährst Du vielleicht nur zufällig, wenn KEIN Backup von einzelnen Files existiert.

Was ist denn der Grund für den Crash?
Kann er wieder auftreten?
Wie lässt er sich vermeiden?
Wie sind die SMART-Werte der HDD?
Auf eine gecrashte HDD sollte NIE wieder etwas geschrieben werden,
selbst das Lesen ist KEINE vertrauenswürdige Aktion!

Manche "Rettungsprogramme" (besonders die von Microsoft!) machen noch mehr kaputt.