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;

[p80286]

Soo groß ist der Unterschied zwischen TFileStream und Blockwrite ja nun auch nicht:

Delphi-Quellcode:

const
  maxbuffsize=1024;
var
  buffer : array [0..maxbufsize-1];
  f : file;


assignfile(f,'Myfile');
reset(f,1);
repeat
  readed:=blockread(f,buffer,maxbuffsize); {bei nicht dyn arrays geht das! }
  if readed>0 then machwasdamit;
until readed<maxbufsizes;
closefile(f);

Delphi-Quellcode:

const
  maxbuffsize=1024;
var
  buffer : array [0..maxbufsize-1];
  f : tfilestream;

f:=tfilestream.Create('Myfile',fmopenread or fmsharedenynone);
repeat
  readed:=f.read(buffer,maxbuffsize); {bei nicht dyn arrays geht das! }
  if readed>0 then machwasdamit;
until readed<maxbufsizes;
f.free;

Ich hab auch lange einen Bogen darum gemacht.

Gruß
K-H

[Schwedenbitter]

Zitat:

Zitat von himitsu (Beitrag 1182373)

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.

[Mavarik]

Zitat:

Zitat von p80286 (Beitrag 1182376)

Soo groß ist der Unterschied zwischen TFileStream und Blockwrite ja nun auch nicht:
Gruß
K-H

Unterschied? Beide Aufrufe laufen doch sowieso über die gleiche Kernel32 FileIO Routinen. Ich Denke, wenn ich mir den ASM Code anschaue ist die Blockread Variante noch etwas kürzer...

Mavarik

[himitsu]

Es ist nicht wirklich identisch.

Die alten Pascalfunktionen besitzen teilweise ein eigenes Caching und das ist noch nichtmal annähernd optimal eingestellt.
Die Sache mit dem OOP und der Codevervollständigung braucht man wohl nicht mehr zu erwähnen.
Die alten Funktionen greifen auf gloable Variablen zu. Oder hast du etwa erwartet, daß Reset die Datei wirklich nur ReadOnly öffnet? (dieses wird über eine globale Variable FileMode geregelt, mit sehr netten Nebenwirkungen)

[p80286]

Nicht das wir uns mißverstehen, ich wollte nur sagen, daß für den Codierer sich nicht viel ändert.
Und seit XP SP2 ist die Stream-Variante nie langsamer als das alte Blockread.

Gruß
K-H

[BUG]

Ehrlich gesagt fand ich die "klassischen" Dateioperationen immer etwas unübersichtlich. Streams sind (imho) irgendwie übersichtlicher.

Zitat:

Zitat von Schwedenbitter (Beitrag 1182386)

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

Schaden kann es nicht :wink: