Beschädigte Datei retten ?

[Cicaro]

Hallo.

Weiß jemand, wie man am besten 1 Datei kopieren kann, bei dem Windows einen E/A Gerätefehler meldet ?
Es ist ein Video File *.avi und ich habs schon mit VirtualDub angesehen. Es sind vorne, hinten, in der Mitte Frames, die noch in Takt sind (möglicherweise nur ein paar Cluster unlesbar). Ich möchte die Datei kopieren und die fehlerhaften Cluster mit Nullen ausfüllt haben. "Dust Signs File Copier" läuft gerade und ist steckengeblieben. Ich fürchte es wird scheitern. Kennt noch wer was Funktionierendes ?

/edit/ Es ist eine 4 GB Datei (mit Fraps erstelt) und liegt auf einer externen Festplatte.

MfG

[himitsu]

Irgendwo hab ich eventuell noch ein altes fehlerüberspringendes Kopierprogramm rumliegen (mal sehn ob ich's finde).

Worauf befindet sich denn diese Datei? (CD/DVD oder HDD ... bei letzerem Checkdisk drüberlaufen lassen)

[Christian Seehase]

Moin Cicaro,

schau mal im Eventviewer, ob dort eventuell Plattenfehler gemeldet werden.

[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 :angle2: ).

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 :wall: ... 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]

Jain, beide Systeme sind NTFS. Ich wollte die Datei mithile einer externen Festplatte von einem PC auf nen anderen kopieren und es ist wohl auf schlechten Sektoren gelandet. Ich hab jetzt meine Datei mit VirtualDub in 2 Teile aufgeteilt und habe 35 unlesbare Frames verloren. Ich kanns verschmerzen. Aber das Problem ist hier nicht wirklich gelöst. Wie rettet man Nicht-VirtualDub-Kompatible-Dateien ?

Ich hab "Dust Sign File Copier" und "unstopcp" ausprobiert. Beide blieben bei der Stelle mit fehlerhaften Clustern hängen (hab sie abgebrochen, vielleicht funktionieren sie ja doch noch, aber es dauerte mir zu lange).

[Cicaro]

Zitat:

Zitat von himitsu (Beitrag 1112264)

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.