Erkennungszeit von unlesbaren Bytes verkürzen?

[Kernel32.DLL]

Tach alle zusammen,

Ich bräuchte da mal einen Wink mit dem Zaunpfahl...

Mein Problem ist, dass ich ein Programm schreibe, welches bei fehlerhaften Dateien (z.B. zerkratzte CD) im Gegensatz zum Windows Explorer den Kopiervorgang nicht sofort abbricht, sondern stur weiterkopiert und die unlesbaren Bytes einfach durch "0" ersetzt.

Soweit, so gut. In der Praxis funzt das auch relativ gut, bis auf die kleine, störende Eigenschaft, dass es ziemlich lange dauert, bis das Programm den Dateizeiger bei einem fehlerhaften Block um 2048 Bytes weitersetzt.

Kann man diese Zeit irgendwie reduzieren?

P.S.: Zum Auslesen benutze ich BlockRead/BlockWrite in einer Try-Except Konstruktion

[Kernel32.DLL]

Keiner eine Ahnung? :(

[supermuckl]

das geht wohl nur mit treibern ?!
bei clonecd oder dvd decrypter kann man auch über die fehler "hinweg fliegen" aber die dinger benutzen eigene aspi treiber dafür odersowas

[c113plpbr]

Zitat:

Zitat von supermuckl

bei clonecd oder dvd decrypter kann man auch über die fehler "hinweg fliegen" aber die dinger benutzen eigene aspi treiber dafür odersowas

Dieses "hinwegfliegen" geht aber nur bei lauferken, die dies auch unterstützen ...

ciao, Philipp

[shmia]

Zitat:

Zitat von Kernel32.DLL

Mein Problem ist, dass ich ein Programm schreibe, welches bei fehlerhaften Dateien (z.B. zerkratzte CD) im Gegensatz zum Windows Explorer den Kopiervorgang nicht sofort abbricht, sondern stur weiterkopiert und die unlesbaren Bytes einfach durch "0" ersetzt.
... dass es ziemlich lange dauert, bis das Programm den Dateizeiger bei einem fehlerhaften Block um 2048 Bytes weitersetzt.
Kann man diese Zeit irgendwie reduzieren?
P.S.: Zum Auslesen benutze ich BlockRead/BlockWrite

Zum Lesen und Schreiben von Dateien gibt es versch. Funktionen, die sich durch unterschiedliche
"Nähe" zum Betriebssystem unterscheiden.
Man kann diese Arten als "highlevel" (weit weg vom OS), "lowlevel" (nahe dran am OS) und
"devicelevel" (direkter Zugriff auf Platte, CD-ROM; Umgehung des Filesystems) unterscheiden.

Die Arbeit mit AssignFile, BlockRead, CloseFile ist "highlevel" und ausserdem gepuffert.
Dagegen ist das Arbeiten mit TFileStream ist ungepuffert (der Cache des Betriebssystems ist aber dennoch wirksam) und näher am Betriebssystem.
Direkt am Betriebssystem sind die Windows API Funktionen CreateFile, ReadFile, CloseHandle.
Je näher du am Betriebssystem ansetzt, desto weniger Overhead ist enthalten und desto schwieriger
wird die Programmierung.

Andererseits wäre es möglich, dass man die Anzahl der Leseversuche irgendwo einstellen kann.
Du kannst ja mal die Forschung in Richtung: DeviceIoControl(hDevice, IOCTL_CHANGER_GET_PARAMETERS,..) richten.

[sakura]

Zitat:

Zitat von shmia

Dagegen ist das Arbeiten mit TFileStream ist ungepuffert (der Cache des Betriebssystems ist aber dennoch wirksam) und näher am Betriebssystem.

Sorry, aber die Aussage ist falsch. Auch TFileStream arbeitet mit den gepufferten Versionen. Intern ruft TFileStream die Function FileCreate aus SysUtils auf, welche nicht das Flag FILE_FLAG_WRITE_THROUGH setzt, welches den Dateipuffer umgeht.

Original Delphi-7-SysUtils Code:

Delphi-Quellcode:

function FileCreate(const FileName: string): Integer;
{$IFDEF MSWINDOWS}
begin
  Result := Integer(CreateFile(PChar(FileName), GENERIC_READ or GENERIC_WRITE,
    0, nil, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0));
end;
{$ENDIF}
{$IFDEF LINUX}
begin
  Result := FileCreate(FileName, FileAccessRights);
end;
{$ENDIF}

müsste aussehen wie folgend, um den Cache zu umgehen:

Code:

function FileCreate(const FileName: string): Integer;
{$IFDEF MSWINDOWS}
begin
  Result := Integer(CreateFile(PChar(FileName), GENERIC_READ or GENERIC_WRITE,
    0, nil, CREATE_ALWAYS, [color=#f50000]FILE_FLAG_WRITE_THROUGH or [/color]FILE_ATTRIBUTE_NORMAL, 
    0));
end;
{$ENDIF}
{$IFDEF LINUX}
begin
  Result := FileCreate(FileName, FileAccessRights);
end;
{$ENDIF}

...:cat:...

[sakura]

Zitat:

Zitat von shmia

(der Cache des Betriebssystems ist aber dennoch wirksam)

:oops: Sorry, überlesen :wall:

...:cat:...

[Kernel32.DLL]

Das hieße also, wenn ich die WinAPI Funktion CreateFile nehmen würde, und als zusätzlichen Flag "File_Flag_Write_Through" verwenden würde, könnte ich schonmal den DatenPuffer umgehen?

Kann ich vielleicht dann auf dieser Ebene die Zahl der Leseversuche einstellen?

Oder muss ich DeviceIOControl benutzen? Ich hab mich mit diesem Aufruf schonmal erfolglos rumgeschlagen...

Ne'n kleiner Beispiel-Code wär nicht schlecht bzw. eine Erklärung "How2do".

THX
Daniel

[supermuckl]

du könntest ja mal DVDDecrypter disassemblieren und schauen was der für funktionen bzw DLLs verwendet.. vielleicht is ja direkt was auffälliges dabei was die leute verwenden um sogar bei einem lesefehler überhaupt nicht nochmal zu versuchen zu readen

[Ultimator]

*räusper* Ich glaube nicht, dass das i.O. ist. Die haben sich schließlich auch viel Mühe gegeben, das so hinzubiegen. Und dann kommt einer daher, disassembliert es und alles war wieder (fast) umsonst. Außerdem weiß man ja nicht, ob die da nicht n Patent drauf haben, wie das gemacht wird. Ich denke, dass es rechtlich zumindest bedenklich ist. :?

[supermuckl]

man muss ja nich gleich aus dem fenster springen wenn ich es sage *duck*

[Ultimator]

War ja nicht bös gemeint :wink:

[Kernel32.DLL]

^^ ein klitzekleinesbissel OT? ^^

Öhm...

Nö, ich denke nicht, dass das rechtlich irgendwelche Probleme machen würde.


Man sieht ja, dass sie ASPI-Treiber u.ä. benutzen. Allerdings funzt ASPI nur bei SCSI.
Insofern versuch ich das lieber direkt über die API. Schliesslich soll ja der User, wenn er seine Dateien von einer sehr zerkratzten CD kopieren möchte, nicht dazu genötigt werden, zusätzlich irgendetwas von Drittanbietern benutzen zu müssen. :wink: ,

[Kernel32.DLL]

keine weiteren Ideen?

Ich *push* den Thread nochmal

*push* :lol: