Beschädigte Datei retten ?

[WM_CLOSE]

Kann es vielleicht sein, dass die Datei von einem anderen Rechner als deinem auf die Platte kopiert wurde? ODer dass die Platte FAT(32) formatiert ist?
FAT kann mit Dateien>4GB nicht umgehen, da braucht es schon NTFS.

[himitsu]

Nee, find es nicht mehr, aber hier mal eine ganz einfache Konstruktion:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  i, o: TStream;
  p, l: Int64;
  b: array[0..511] of Byte;
begin
  o := nil;
  i := TFileStream.Create(Edit1.Text, fmOpenRead or fmShareDenyNone);
  try
    o := TFileStream.Create(Edit2.Text, fmCreate);
    l := i.Size;
    p := 0;
    while p < l do
      try
        i.Position := p;
        o.Position := p;
        o.Write(b, i.Read(b, SizeOf(b)));
        Inc(p, SizeOf(b));
      except
        Inc(p, SizeOf(b));
      end;
  finally
    o.Free;
    i.Free;
  end;
end;

Für CD/DVD kann/sollte man aus dem 511 ein 2047 machen (es geht aber auch so, nur eben bis zu 4 Mal langsamer, bei den fehlerhaften Sektoren, aber immernoch schneller, als der Unstoppable ).

Alternativ gibt es auch noch den Unstoppable Copier, aber ganz im Ernst, das Programm funktioniert zwar, ist allerdings total schrottig und scheinbar ohne das geringste Wissen über Dateizugriffe programmiert wurden und demnach extrem lahm.
(Byteweiser Zugriff, wo die Laufwerke doch nur Sektorweise arbeiten ... Seit ich weiß, wie das im Inneren arbeitet, kann ich das Teil eigentlich nicht mehr wirklich empfehlen)



Kannst'e ja mit 2 TEdits und einem TButton zum Laufen bekommen (eventuell auch noch je ein TButton mit TOpenDialog, bzw. TSaveDialog an die Edits dran)
oder direkt die Dateinamen/-pfade angeben.

[Cicaro]

Zitat von himitsu:

Nee, find es nicht mehr, aber hier mal eine ganz einfache Konstruktion:
...

Hab mir auch schon überlegt, mir in Delphi nen "Kopierer" zu programmieren. Aber mit VirtualDub gibgs schneller ^^ (hm mal testen, ob der Code funktioniert. Wenn Delphi "meinen" Fehler auch als Exception abfängt, sollte es eigentlich)

[himitsu]

Nja, es werden nicht alle Fehler als Exception zurückgemeldet.

Einige sagen nur 0, bzw -1 oder "weniger als man lesen wollte" ("0 Byte verarbeitet", bzw. INVALID_FILE_irgendwas oder "konnte nicht alles verarbeiten")
und geben zusätzlich einen Fehlercode (GetLastError) zurück.
TFileStream.Read wertet diese Fehlermeldungen allerdings nicht aus (im Gegensatz zu TFileStream.ReadBuffer), womit an solchen Stellen nichts geschrieben wird.
In Windows NT-Systemen werden unbeschriebene Teile einer Datei automatisch mit Nullen gefüllt.



Wie gesagt, ist ein sehr einfacher Code.
Richtiger/Besser wäre es, wenn sich das Ganze selber an die Sektorgröße der Datenträger anpaßt, wenn man eventuell noch die WindowsFileCache umgeht und wenn man noch die eine oder andere Fehlermeldung des Systems (von Windows) deaktivert.

[Cicaro]

Also dein Code funktioniert nicht. Bleibt in etwa an der Fehlerstelle stecken und reagiert nicht mehr. Man sollte wohl noch näher an WinAPI programmieren oder mir Assembler ran. Aber ich hab da gerade keine Lust drauf, da ich die beschädigte Datei bereits entfernt habe und nicht mehr testen kann.

[himitsu]

Tja, dann hast du ein kleines Problemchen ... scheinbar stürtzt de Treiber dort ab, bzw. bleibt hängen, und wenn die Leseoperationen nicht zurückkommen, dann war's das.

Welches Windowsversion nutzt du denn,
wie reagieren die Programme, wenn man sie beenden will? (lassen sie sich "leicht" über [X] oder den Taskmanager beenden)

Wie gesagt, das ist ein sehr ein einfacher Code und ein/zwei Ecken gibt es noch, wo man was drehen kann, aber ob man so am Treiber vorbei kommt...
Darum die Frage nach dem Beendeverhalten des Programms ... also ob es sich lohnt das jetzt noch "schnell" umzuschreiben und es dann nochmal zu versuchen.

[DelphiSecurity]

HIER KLICKEN, IST DAS BESTE

[Luckie]

Wie willst du an dem Treiber vorbeikommen? Der Treiber ist die einzige Schnittstelle zur Hardware.

[p80286]

Ich habe auch schon mal defekte DVDs oder CDs auslesen müssen, da funktionierte der code aus #5 allerdings.
(Gut ich hatte einen Buffer dazwischen gepackt und massig Zeit)

Gruß
K-H

[Cicaro]

Zitat von himitsu:

Tja, dann hast du ein kleines Problemchen ... scheinbar stürtzt de Treiber dort ab, bzw. bleibt hängen, und wenn die Leseoperationen nicht zurückkommen, dann war's das.

Welches Windowsversion nutzt du denn,
wie reagieren die Programme, wenn man sie beenden will? (lassen sie sich "leicht" über [X] oder den Taskmanager beenden)

Wie gesagt, das ist ein sehr ein einfacher Code und ein/zwei Ecken gibt es noch, wo man was drehen kann, aber ob man so am Treiber vorbei kommt...
Darum die Frage nach dem Beendeverhalten des Programms ... also ob es sich lohnt das jetzt noch "schnell" umzuschreiben und es dann nochmal zu versuchen.

Ich sag mal so viel, dass der Kopiervorgang NICHT schnell beendet werden kann. Windows hat ja selber Probleme die Datei zu kopieren und meldet den Fehler erst nach langer Wartezeit. Wenn du den Code ändern willst, schau dass du Fehler schneller ignorierend übergehen kannst. Am besten gleich GetLastError ohne Exceptions usw. Aber da verlässt du dich immer noch auf WinAPI. Also könnte auch das nichts bringen. Leider musst du dir irgendwo anders fehlerhafte Sektoren suchen. Meine Datei ist schon weg und ich weiß, wie ich meinem Problem in Zukunft aus dem Weg gehen kann (zumindest funktioniert es noch).