Defragmentier- oder datenrecovery programm realisieren?

[starY]

Ich wollte mir eigentlich ein Defragmentier programm so wie DiskKeeper schreiben und auch ein Datenrecovery tool für NTFS so wie GetDataBack. Nur weiß ich nicht wie ich low level read und write mit delphi realisieren. nun meine frage: Ist dies überhaupt möglich und wenn ja welche befehle brauche ich?

Danke schon mal im vorraus ;)

MfG
starY

[Olli]

Zitat:

Zitat von starY

Ich wollte mir eigentlich ein Defragmentier programm so wie DiskKeeper schreiben und auch ein Datenrecovery tool für NTFS so wie GetDataBack. Nur weiß ich nicht wie ich low level read und write mit delphi realisieren. nun meine frage: Ist dies überhaupt möglich und wenn ja welche befehle brauche ich?

Ich will dir ja jetzt nicht die Butter vom Brot nehmen, aber bei diesen Sachen ist es eben nicht damit getan, daß man "Low Level" Schreib-/Lesezugriff hat. Desweiteren solltest du wissen wie NTFS arbeitet - und zwar genauestens sonst - fabrizierst du das Gegenteil von "data back" :mrgreen:

Außerdem würde ich dir Delphi da nicht empfehlen, das aber nur nebenbei. Ansonsten werden dir die Funktionen, welche wir mit Marcel van Brakel in unserer Native API Unit zusammengetragen haben, helfen. In einem älteren Post von mir findest du die entsprechenden Infos wo du das alles findest:
http://www.delphipraxis.net/internal...=358285#358285

DiskKeeper hat außerdem noch einen Service, der mit SYSTEM-Rechten agiert. Also auch dahingehend mußt du dich kundig machen. Ansonsten findet sich in Gary Nebbetts "Windows NT/2000 Native API Reference" ganz am Ende des Buches ein Kapitel zur Wiederherstellung gelöschter Daten mit Beschreibung der internen NTFS-Strukturen.

Auch diverse OpenSource-Projekte setzen sich mit den Interna von NTFS auseinander. Aber ich denke ohne ein NDA mit Microsoft wirst du qualitativ nie an DiskKeeper und ähnliche Produkte herankommen. Und mit qualitativ ist hier durchaus auch gemeint wie sicher dein Produkt seinen Job tut!

[Daniel G]

Nur für Windows NT:

von Sakura

Und wenn du das Kätzchen ganz lieb' fragst, darfst du vllt. sogar einen Blick in den Source werfen. :mrgreen:

(generell gilt: sofern irgendwas mit Treibern anfängt, kannst du Delphi Language knicken.)

[starY]

Erstmal danke für die Antworten ;)

Ich weiß, dass ich dafür die NTFS Spezifikationen brauche ;) aber da diese mir relativ logisch vorkamen, dachte ich mir, dass diese nicht so das Hindernis darstellen. Ich habe mir nun die Native API gezogen. Kann mir wer vielleicht sagen welche *.pas ich einbinden muss und mit welchen Befehlen ich dann Bytes auslese und schreibe?

Sakura habe ich eine PM geschickt und warte noch auf Antwort.

MfG
starY

[mael]

Ersteinmal: Treiber sind nicht notwendig, jedenfalls nicht unter Windows NT. Unter Windows 9x braucht man eine 16 Bit DLL oder einen Treiber, aber ich glaube der Aufwand lohnt nicht Windows 9x zu unterstützen.

Was das direkte Lesen/Schreiben von Festplatten angeht, was für Datenwiederherstellung sinnvoll wäre, habe ich hier schon mal einen Beitrag gepostet:
http://www.delphipraxis.net/internal...=310776#310776

Zweitens

Zitat:

Zitat von Olli

Außerdem würde ich dir Delphi da nicht empfehlen, das aber nur nebenbei

:roll: warum machen Delphi-Programmierer Delphi immer schlecht???

Es gibt ein sehr gutes (in Delphi geschriebenes) Tool namens Drive Rescue von Alexander Grau. War eine Zeit lang Freeware mit Quelltext, bei http://www.torry.net/authorsmore.php?id=3277 gibt es aber noch seinen Kode um auf die Festplatte zuzugreifen und mit ein bisschen Glück findest du noch eine alte Version von Drive Rescue.

[Olli]

Zitat:

Zitat von starY

Ich weiß, dass ich dafür die NTFS Spezifikationen brauche ;) aber da diese mir relativ logisch vorkamen, dachte ich mir, dass diese nicht so das Hindernis darstellen.

:-|

Zitat:

Zitat von starY

Ich habe mir nun die Native API gezogen. Kann mir wer vielleicht sagen welche *.pas ich einbinden muss

JwaNative.pas und alle Abhängigkeiten (uses/INCLUDE).

Zitat:

Zitat von starY

und mit welchen Befehlen ich dann Bytes auslese und schreibe?

Guck dir doch mal die Importtabelle von sakuras Tool an! Außerdem habe ich dir weiter oben Quellen genannt (ich sage nur Nebbett).

Zitat:

Zitat von mael

Ersteinmal: Treiber sind nicht notwendig, jedenfalls nicht unter Windows NT. Unter Windows 9x braucht man eine 16 Bit DLL oder einen Treiber, aber ich glaube der Aufwand lohnt nicht Windows 9x zu unterstützen.

Für die Wiederherstellung von Daten denke ich schon. Zumindest wenn du ernstzunehmenden Code schreiben willst.
Ansonsten brauchst du noch einen Service - wenn das nicht wäre, wäre mein komplettes Vertrauen in Windows erschüttert, da du dann auch als Gast mal eben Dateien des Admins wiederherstellen oder "defragmentieren" kannst.

Zitat:

Zitat von mael

Zweitens

Zitat:

Zitat von Olli

Außerdem würde ich dir Delphi da nicht empfehlen, das aber nur nebenbei

:roll: warum machen Delphi-Programmierer Delphi immer schlecht???

Erstens: wer sagt ich sähe mich als Delphiprogrammierer. Zweitens: schreib doch was du willst in Delphi. Es ist und bleibt meine Ansicht. Schließlich ist hier nicht die GUI das Problem sondern der Unterbau. Einige Sachen, besonders bei Nutzung der Native API, sind in Delphi zwischen unmöglich und "unangenehm" zu realisieren.

[generic]

defragmentierer einfach - da gibts ne api welche unkaputtbar ist.
schau mal bei sysinternals "inside diskdefragment" oder so hiess der artikel

[Olli]

Zitat:

Zitat von generic

defragmentierer einfach - da gibts ne api welche unkaputtbar ist.
schau mal bei sysinternals "inside diskdefragment" oder so hiess der artikel

Unkaputtbar? Eine Native API? Da hat wohl einer was nicht begriffen in Sachen Native API. Diese APIs sind so mit das zerbrechlichste was es in Windows gibt. Die können sich potentiell mit jedem Patch oder Servicepack oder mindestens OS ändern. Das ist bekannt und wird deshalb auch immer gesondert behandelt. Von unkaputtbar würde ich da kaum sprechen.

Diesen Artikel meinst du wohl?:
http://www.sysinternals.com/Informat...agmenting.html

[mael]

Zitat:

Zitat von Olli

Für die Wiederherstellung von Daten denke ich schon. Zumindest wenn du ernstzunehmenden Code schreiben willst.
Ansonsten brauchst du noch einen Service - wenn das nicht wäre, wäre mein komplettes Vertrauen in Windows erschüttert, da du dann auch als Gast mal eben Dateien des Admins wiederherstellen oder "defragmentieren" kannst.

Es gibt dafür BartPE. Sonst wie gesagt der sehr gute Quelltext zum direkten Festplattenzugriff von Drive Rescue auf den ich oben verwiesen habe. Ein Gast hat nicht zu defragmentieren und auch nicht Daten wiederherzustellen. Das ist Adminarbeit, deswegen ist direkter Festplattenzugriff Admins vorbehalten. Du brauchst keinen Service und unter Windows NT keinen Treiber. Das macht das System unstabil und ist nicht nötig! Ein Service könnte sich höchstens noch anbieten damit möglichst wenige Dateien in Benutzung sind und sie somit sicher verschoben werden können. Das ist mit Delphi problemlos möglich.
Falls Du einen Treiber für Windows 9x brauchst nimm den der bei dem genannten Quelltext von Alexander Grau drin ist (sehr gut geschriebener Assembler).

NativeAPI sind genauso wenig nötig! Ab Windows 2000 gibt es ziemlich bequeme Funktionen um zu Defragmentieren File Defragmentation

Zitat:

Zitat von Olli

Erstens: wer sagt ich sähe mich als Delphiprogrammierer.

Dann schreib doch in eines der vielen nicht Delphi-Foren. Delphi Kritik ist in Ordnung wo gerechtfertigt, aber "Low-Level <> Delphi" zeugt von Unwissenheit.

Zitat:

Zitat von Olli

Zweitens: schreib doch was du willst in Delphi.
Es ist und bleibt meine Ansicht. Schließlich ist hier nicht die GUI das Problem sondern der Unterbau.

Delphi hat andere Vorzüge als die GUI-Programmierung, einer der Hauptvorteile von Pascal ist die bessere Lesbarkeit und Wartbarkeit. Früher haben viele Demo-Groups in Pascal programmiert, gerade wo es um low-level Hardware-Zugriffe wegen der Geschwindigkeit ging. Wenn Meinungen gegen eine Sprache, dann präzise Gründe und nicht diese pauschalen Aussagen!

Zitat:

Zitat von Olli

Einige Sachen, besonders bei Nutzung der Native API, sind in Delphi zwischen unmöglich und "unangenehm" zu realisieren.

Abgesehen davon, daß ich keinen Vorteil darin sehe jede Windows Haupt-, Unter- und Nebenversion extra unterstützen zu müssen, wüßte ich jetzt nicht was mir eine andere Sprache dabei erleichtert. Header alleine bringen einem herzlich wenig.

[Luckie]

Zitat:

Zitat von mael

Zitat:

Zitat von Olli

Zweitens: schreib doch was du willst in Delphi.
Es ist und bleibt meine Ansicht. Schließlich ist hier nicht die GUI das Problem sondern der Unterbau.

Delphi hat andere Vorzüge als die GUI-Programmierung, einer der Hauptvorteile von Pascal ist die bessere Lesbarkeit und Wartbarkeit. Früher haben viele Demo-Groups in Pascal programmiert, gerade wo es um low-level Hardware-Zugriffe wegen der Geschwindigkeit ging. Wenn Meinungen gegen eine Sprache, dann präzise Gründe und nicht diese pauschalen Aussagen!

Früher gab es auch noch kein Windows NT, wo Windows NT selber keine direkten Hardwarezugriffe erlaubt und APIs bereitstellt, führt kein Weg an einem Treiber vorbei, denn nur der darf direkt auf die Hardware zugreifen. Was die Lesbarkeit und Wartbarkeit angeht ist Geschmackssache. Frag mal einen C++ Programmierer der noch nie mit Delphi gearbeitet hat, der wird dir deine begins und ends um die Ohren hauen.

Zitat:

Zitat von Olli

Einige Sachen, besonders bei Nutzung der Native API, sind in Delphi zwischen unmöglich und "unangenehm" zu realisieren.

Abgesehen davon, daß ich keinen Vorteil darin sehe jede Windows Haupt-, Unter- und Nebenversion extra unterstützen zu müssen, wüßte ich jetzt nicht was mir eine andere Sprache dabei erleichtert. Header alleine bringen einem herzlich wenig.[/quote]
Guck dir das DDK an. Was hatte Nico da noch mal zu geschrieben? Moment:

Zitat:

...selbst wenn sich jemand die Arbeit macht das Device Driver Kit (DDK) in Delphi Language zu 'übersetzen', wird er feststellen, das selbige Sprache einige Features nicht hat, die dort ausgiebig benutzt werden ( z.B. Makros, 'fastcall' (Microsoft-spezifische Aufrufkonvention, vergleichbar mit 'register' in Pascal) und Unions (bedingt übersetzbar) ... )

Nach zu lesen hier: Wo hat Delphi seine Grenzen

Und zum Schluss: Olli und NicoDE wissen wo von sie sprechen. Ich kenn niemanden im der deutschsprachigen Delphi Community mit so viel Ahnung was die Interna von Windows angeht.