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.

[mael]

Zitat:

Zitat von Luckie

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.

Mit den verschiedenen Vorlieben habe ich keine Probleme, es gibt sicherlich C++ features die ich gerne in Delphi sehen würde. Allerdings sind diese High-Level und helfen hier nicht und ich finde man sollte nicht in einem Delphi Forum permanent (richtet sich ja nicht nur an Olli) andere Sprachen als besser bezeichnen.

Zitat:

Zitat von Luckie

Guck dir das DDK an. Was hatte Nico da noch mal zu geschrieben? Moment:

Ich habe nicht von Treiberentwicklung geschrieben, ich habe auf funktionierenden Delphi-Quellcode verwiesen, man kann ohne Treiber auskommen (siehe RawWrite) oder mit (ist in Assembler geschrieben).
Das heißt direkter Festplattenzugriff braucht keinen Treiber (wenn man unbedingt einen braucht gibt es wie gesagt einen im Code von Alexander Grau) und daher ist Delphi perfekt dazu geeignet.

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) ... )

Darum ging es nicht, sondern man braucht keinen Treiber.

Zitat:

Und zum Schluss: Olli und NicoDE wissen wo von sie sprechen.

Mag sein, aber man braucht keine native API, siehe einfach die in Delphi geschriebene Software an(RawWrite und Software bei Torry). Ich habe es auch schon gemacht und weder C++ noch Assembler gebraucht und mich auch nicht verkünsteln müssen. Also kann ich so eine Behauptung nicht stehen lassen, dazu habe ich auch Links in meinen vorigen Beiträgen geliefert.
Dieses "es geht nicht und Punkt so ist es" ist einfach nicht zutreffend.

[Luckie]

Zitat:

Zitat von mael

Ich habe nicht von Treiberentwicklung geschrieben, ich habe auf funktionierenden Delphi-Quellcode verwiesen, man kann ohne Treiber auskommen (siehe RawWrite) oder mit (ist in Assembler geschrieben).
Das heißt direkter Festplattenzugriff braucht keinen Treiber (wenn man unbedingt einen braucht gibt es wie gesagt einen im Code von Alexander Grau) und daher ist Delphi perfekt dazu geeignet.

Das habe ich in diesem Fall auch nicht bestritten, weil nämlich Window sin diesem fall eine API zur verfügung stellt, die dies erlaubt.

[mael]

Zitat:

Zitat von Luckie

Zitat:

Zitat von mael

Ich habe nicht von Treiberentwicklung geschrieben, ich habe auf funktionierenden Delphi-Quellcode verwiesen, man kann ohne Treiber auskommen (siehe RawWrite) oder mit (ist in Assembler geschrieben).
Das heißt direkter Festplattenzugriff braucht keinen Treiber (wenn man unbedingt einen braucht gibt es wie gesagt einen im Code von Alexander Grau) und daher ist Delphi perfekt dazu geeignet.

Das habe ich in diesem Fall auch nicht bestritten, weil nämlich Window sin diesem fall eine API zur verfügung stellt, die dies erlaubt.

Unter 9x keine API aber durch 16 bit DLL per BIOS und DPMI erreichbar. Naja, egal. Sicherlich gibt es Fälle wo man Treiber braucht, aber die sind doch eher selten (Parallelport vielleicht). Jedenfalls denke ich sind wir uns einig, daß für die im Thread gefragte Aufgabenstellung sehrwohl Delphi geeignet ist.

[Olli]

Zitat:

Zitat von mael

Es gibt dafür BartPE.

Was BartPE damit zu tun hat, weiß ich nun zwar nicht, da IMO ein Defragmentierung- ebenso wie ein Datenrettungstool auch in einem laufenden System einiges können sollte. Aber ist schon okay. Unter BartPE (oder WinPE allgemein) hat man es natürlich leicht, weil man mit SYSTEM-Rechten läuft.

Zitat:

Zitat von mael

Ein Gast hat nicht zu defragmentieren und auch nicht Daten wiederherzustellen. Das ist Adminarbeit, deswegen ist direkter Festplattenzugriff Admins vorbehalten.

Wir reden hier nicht von Gast, sondern davon, daß du als Nichtadmin eingeloggt bist (z.B. Hauptbenutzergruppe) und defragmentieren willst ohne jedesmal mit RunAs zu hantieren.
Es ist auch nicht die Aufgabe von Gast die MMC aufzurufen, warum gibt es dann überhaupt RunAs?

Zitat:

Zitat von mael

Du brauchst keinen Service und unter Windows NT keinen Treiber.

Zum Defragmentieren nicht. Ich weiß auch nicht warum du das immer wieder aufwirfst, denn ich habe es nie behauptet.

Zitat:

Zitat von mael

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

Ähem :gruebel: ... hast du da auch selber mal reingeguckt? Ob ich einen *CTL nun mit der einen oder der anderen Funktion schicke ist oft egal. Die *CTLs sind aber die gleichen wie oben im Artikel von Sysinternals beschrieben. Das ganze läuft wieder durch eine einzige Funktion. So wie man eben nunmal mit Treibern kommuniziert, über IOCTLs, FSCTLs und wie sie alle heißen. Und wenn du genau aufgepaßt hättest, wüßtest du, daß diese Funktionen zwar erst jetzt richtig dokumentiert sind, daß sie aber seit Windows NT 4.0 existieren (siehe Artikel von Sysinternals).

Zitat:

Zitat von mael

"Low-Level <> Delphi" zeugt von Unwissenheit.

Schau dir nochmal meinen Wortlaut an. Und wenn du behauptest, daß "Low Level" mit Delphi empfehlenswert sei, dann frage ich mich umgekehrt was ...

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,

Nur leider ging es hier eben nicht um die GUI und auch nicht um Lesbarkeit und Wartbarkeit (welche sehr subjektiv sind ;) ).

Zitat:

Zitat von mael

einer der Hauptvorteile von Pascal ist die bessere Lesbarkeit und Wartbarkeit.

Hängt vom Programmierer und seinem Stil ab. Gleiches gilt für jede andere Sprache. Ich erinnere nur an die Obfuscated [C/C++/Perl/...]-Wettbewerbe.

Zitat:

Zitat von mael

Früher haben viele Demo-Groups in Pascal programmiert, gerade wo es um low-level Hardware-Zugriffe wegen der Geschwindigkeit ging.

Äpfel und Birnen? Hatten wir nicht eben noch von Delphi und 32bit-Betriebssystemen gesprochen? Früher ... jetzt haben wir aber Sommer.

Zitat:

Zitat von mael

Wenn Meinungen gegen eine Sprache, dann präzise Gründe und nicht diese pauschalen Aussagen!

Wenn ich sage, daß Native API besser nicht mit Delphi und daß es eben nicht um die GUI geht, wo Delphi besser wäre, dann ist das pauschal? Na gut :roll: ... konkrete Fallbeispiele sind pauschal :-|

Zitat:

Zitat von mael

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.

Schon was von Präprozessormakros gehört? Einige sog. Native APIs existieren eigentlich garnicht, sondern sind als Makros deklariert. Da kommt man dann mit Delphi ziemlich ins Schwitzen. Zumal die Implementierung dann teilweise uneffektiver wird. Aber ich bin ja unwissend, von daher ...

Zitat:

Zitat von Luckie

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

Du machst Delphi damit schlecht, Luckie! :mrgreen:

Zitat:

Zitat von Luckie

Ich kenn niemanden im der deutschsprachigen Delphi Community mit so viel Ahnung was die Interna von Windows angeht.

Ich sage nur w3seek. Thomas ist Mitglied im ReactOS-Projekt, als solches kennt er sich natürlicherweise damit aus ;)

Zitat:

Zitat von mael

ich finde man sollte nicht in einem Delphi Forum permanent (richtet sich ja nicht nur an Olli) andere Sprachen als besser bezeichnen.

In meinem Duden von 1967 steht:

permanent (dauernd, anhaltend, ununterbrochen, ständig) <lat>

... hat sich die Bedeutung geändert? Wenn ich mal wenigstens etwas als besser bezeichnet hätte! Ich sehe zwar z.B., um bei einer prominenten Sprache zu bleiben, einige Buchstaben "C" oben im Text, aber vor Luckie hat niemand C++ oder C angesprochen. Es war eine (berechtigte) Kritik an Delphi! (Warum berechtigt? Weil die Erfahrung damit durchaus zu einer solchen Aussage berechtigt. Wir hatten mit Marcel van Brakel auch darüber diskutiert, ob die DDK Header noch übersetzt werden sollten, uns aber dagegen entschieden. Aus naheliegenden Gründen. Machen wir damit Delphi schlecht? Macht man Delphi schlecht, wenn man feststellt, daß man printf() nicht sinnvoll in Delphi nutzen kann? Nein - wir stoßen nur an die Grenzen und zeigen sie auf.)
Warum arbeitet der Uhrmacher nicht mit einer Axt, der Bauer nicht mit einem Schraubenzieher und der Raumfahrer nicht mit einem Taucheranzug? Eben, weil es für jedes Ding das richtige Werkzeug gibt. In manchen Fällen sind es auch mehrere Werkzeuge die zur Verfügung stehen, oder Werkzeuge verschiedener Firmen mit ähnlicher Funktion. Wo ist dein Problem? Wer nicht in der Lage ist das korrekte Werkzeug auszuwählen sollte es sein lassen.

Zitat:

Zitat von mael

Ich habe nicht von Treiberentwicklung geschrieben, ich habe auf funktionierenden Delphi-Quellcode verwiesen, man kann ohne Treiber auskommen (siehe RawWrite) oder mit (ist in Assembler geschrieben).
Das heißt direkter Festplattenzugriff braucht keinen Treiber (wenn man unbedingt einen braucht gibt es wie gesagt einen im Code von Alexander Grau) und daher ist Delphi perfekt dazu geeignet.

Das ist korrekt. Direkt würde ich das zwar nicht nennen, aber man kann zumindest sektorenweise schreiben und lesen. Das ist wiederum aber nur mit bestimmten Privilegien möglich. Um das zu umgehen, muß man den Job an einen Service delegieren. Dazu kann ich dir nur das entsprechende Wiki-Buch (oder das Vorgängerbuch) von Keith Brown empfehlen.

Zitat:

Zitat von mael

Darum ging es nicht, sondern man braucht keinen Treiber.

Hier ging es auch um die verwendeten Funktionen. All diese Funktionen bezeichnet man als Native API. Schau einfach mal in die JwaNative.pas - dort sind sogar die Präfices erklärt.

Zitat:

Zitat von mael

Dieses "es geht nicht und Punkt so ist es" ist einfach nicht zutreffend.

Für die Datenwiederherstellung (und es ging hier eben nicht nur um Defragmentierung) würde ich dann gern Beweise in Form von Code von dir sehen. Danke im Voraus.

Zitat:

Zitat von mael

Jedenfalls denke ich sind wir uns einig, daß für die im Thread gefragte Aufgabenstellung sehrwohl Delphi geeignet ist.

Nein!

[mael]

Zitat:

Zitat von Olli

defragmentieren willst ohne jedesmal mit RunAs zu hantieren.
Es ist auch nicht die Aufgabe von Gast die MMC aufzurufen, warum gibt es dann überhaupt RunAs?

Ob ich jetzt als Admin eingeloggt bin oder RunAS verwende ist hier ja wohl egal. Es ändert nichts daran, das man Adminrechte braucht, also was soll das hier?

Zitat:

Zitat von Olli

Ähem :gruebel: ... hast du da auch selber mal reingeguckt?

aber du verstehst anscheinend immer noch nicht, daß ich hier bestehende Treiber verwende und keine schreiben muß.

Zitat:

Schau dir nochmal meinen Wortlaut an. Und wenn du behauptest, daß "Low Level" mit Delphi empfehlenswert sei, dann frage ich mich umgekehrt was ...

sehe hier den Sinn der Aussage nicht...

Zitat:

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,

Nur leider ging es hier eben nicht um die GUI und auch nicht um Lesbarkeit und Wartbarkeit (welche sehr subjektiv sind ;) ).

Zitat:

Zitat von mael

einer der Hauptvorteile von Pascal ist die bessere Lesbarkeit und Wartbarkeit.

Hängt vom Programmierer und seinem Stil ab. Gleiches gilt für jede andere Sprache. Ich erinnere nur an die Obfuscated [C/C++/Perl/...]-Wettbewerbe.

darauf bin ich schon eingegangen

Zitat:

Äpfel und Birnen? Hatten wir nicht eben noch von Delphi und 32bit-Betriebssystemen gesprochen? Früher ... jetzt haben wir aber Sommer.

Da du ja anscheinend sooo viel Ahnung hast (bitte sagen wenn du angebetest werden willst) solltest du wissen, daß unter Windows 9x DOS gerade noch eine sehr wichtige Rolle spielt. Z.B. der genannte Festplattenzugriff.

Zitat:

Wenn ich sage, daß Native API besser nicht mit Delphi und daß es eben nicht um die GUI geht, wo Delphi besser wäre, dann ist das pauschal? Na gut :roll: ... konkrete Fallbeispiele sind pauschal :-|

Natürlich pauschal, denn du sagst Delphi ist nicht empfehlenswert, wahrscheinlich weil man mit Delphi keine Treiber implementieren kann, ist hier aber nicht notwendig ergo, kein Argument.

Zitat:

Schon was von Präprozessormakros gehört? Einige sog. Native APIs existieren eigentlich garnicht, sondern sind als Makros deklariert. Da kommt man dann mit Delphi ziemlich ins Schwitzen. Zumal die Implementierung dann teilweise uneffektiver wird. Aber ich bin ja unwissend, von daher ...

Du bietest eine Lösung an die schwerer als nötig ist, und sagst dann dies geht nicht mit Delphi. Vielleicht ist dein Ansatz falsch und hier nur Overkill, schonmal darüber nachgedacht?

Oh Gott der Rest ist ja noch schlimmer. Wenn es hier um Status und Ruhm geht, tut mir Leid daß ich hier jemanden kritisiere.

Der Punkt ist Delphi kann es, Code Beispiele habe ich geliefert, setz dich mit der Realität auseinander oder lass es. Durch blosen Status und ich oder jener ist bekannt, wirst du daran nichts ändern. Schade...

[Olli]

Zitat:

Zitat von mael

Zitat:

Zitat von Olli

defragmentieren willst ohne jedesmal mit RunAs zu hantieren.
Es ist auch nicht die Aufgabe von Gast die MMC aufzurufen, warum gibt es dann überhaupt RunAs?

Ob ich jetzt als Admin eingeloggt bin oder RunAS verwende ist hier ja wohl egal. Es ändert nichts daran, das man Adminrechte braucht, also was soll das hier?

Ähem? Habe ich mich auch gefragt. Wer von uns beiden hat Services zur Delegation von Aufgaben aus niedrigprivilegiertem Kontext infragegestellt? Nur aus diesem Grund habe ich Services oben erwähnt. Du hast gleich aus vollen Rohren gegen diese Aussage geschossen.

Zitat:

Zitat von mael

Zitat:

Zitat von Olli

Ähem :gruebel: ... hast du da auch selber mal reingeguckt?

aber du verstehst anscheinend immer noch nicht, daß ich hier bestehende Treiber verwende und keine schreiben muß.

Doch. Ich habe auch nie das Gegenteil geschrieben. Du versteifst dich aus irgendeinem Grund auf Treiber, obwohl ich die nur im Zusammenhang mit Wiederherstellung von Daten erwähnte.

Zitat:

Zitat von mael

Zitat:

Schau dir nochmal meinen Wortlaut an. Und wenn du behauptest, daß "Low Level" mit Delphi empfehlenswert sei, dann frage ich mich umgekehrt was ...

sehe hier den Sinn der Aussage nicht...

Dann werde ich mal nachhelfen. Du unterstellst mir Unwissenheit, wenn ich sage, daß ich Delphi im Zusammenhang mit Native API usw. nicht empfehlen kann. "Nicht empfehlen" heißt nichts anderes, als daß es bessere Alternativen gibt. Es besagt noch nichtmal, daß Delphi dazu nicht in der Lage wäre!

Zitat:

Zitat von mael

(bitte sagen wenn du angebetest werden willst)

Bitte bescheidgeben wenn du unterschwellig oder auch offen beleidigend werden willst.

Zitat:

Zitat von mael

solltest du wissen, daß unter Windows 9x DOS gerade noch eine sehr wichtige Rolle spielt. Z.B. der genannte Festplattenzugriff.

Eben. 32bit-Windows. Davon kann man bei Windows 9x wohl kaum reden. Ich sage nur Thunking.
Abgesehen davon bietet natürlich auch Windows 9x/Me Möglichkeiten zum kontrollierten (aber weniger als in NT) "direkten" Festplattenzugriff.

Zitat:

Zitat von mael

Natürlich pauschal, denn du sagst Delphi ist nicht empfehlenswert, wahrscheinlich weil man mit Delphi keine Treiber implementieren kann, ist hier aber nicht notwendig ergo, kein Argument.

Lies lieber nochmal nach.
Wenn ich "Treiber" und "Delphi" im selben Beitrag benutze und du das als rotes Tuch auffaßt, dann tut es mir leid. In diesem Falle solltest du statt zu unterstellen lieber die gegebenen Aussagen aufgreifen. Das bringt auch dem Fragesteller mehr.

Zitat:

Zitat von mael

und sagst dann dies geht nicht mit Delphi.

... ich wiederum gebe dir bescheid, wenn es dir erlaubt ist mir Worte in den Mund zu legen die ich nie gesagt habe. Du kannst mich gerne für meine Aussagen angreifen, aber Angriff für Sachen die ich nicht gesagt habe (sondern die du mir unterstellst gesagt zu haben), ist grundloser Angriff!

Zitat:

Zitat von mael

Vielleicht ist dein Ansatz falsch und hier nur Overkill, schonmal darüber nachgedacht?

Ja und ja.

Zitat:

Zitat von mael

Oh Gott der Rest ist ja noch schlimmer. Wenn es hier um Status und Ruhm geht, tut mir Leid daß ich hier jemanden kritisiere.

Du mußt mich nicht Gott nennen. Ich bin ja selber nicht sonderlich religiös und hatte auch nicht vor eine neue Religion zu gründen. Es geht hier ums Fachliche, nicht mehr und nicht weniger. Und wenn du mal richtig lesen würdest, würdest du nicht zu solchen Unterstellungen kommen. Klar Treiber sind in Delphi nicht möglich, Native API ist möglich - oft aber nicht empfehlenswert. Der Unterschied scheint allen hier im Thema klar zu sein, außer dir.

Zitat:

Zitat von mael

Der Punkt ist Delphi kann es,

Trotz all der Unterstellungen deinerseits; gegenteiliges habe ich nie behauptet!

Zitat:

Zitat von mael

Code Beispiele habe ich geliefert, setz dich mit der Realität auseinander oder lass es.

Code? Sprechen wir von diesem hier? Ich sagte ich will von dir Code zur Datenwiederherstellung auf einem laufenden System und ohne Treiber sehen. Den hast du noch nicht gebracht. Ich frage mich auch was du dann noch mit "direktem Festplattenzugriff" willst, wenn du die Struktur von NTFS nicht aus dem Effeff kennst (würdest du sie kennen, hättest du ein NDA mit MS unterschrieben und dürftest hier nicht helfen). Schonmal bei DriveImage 8 (aka Norton Ghost 9) unter die Haube geguckt? Kann ich nur empfehlen. Und dann sage mir nochmal "ohne Treiber". Frisch gelöschte Dateien kann man hingegen u.U. auch ohne Treiber wiederherstellen (alles undokumentiert und mit "direktem" Festplattenzugriff wird's schwerer nicht leichter - zumindest auf NTFS). Da hast du ganz recht. Gibt's sogar OpenSource zum Thema.


Aber wenn du hier fixiert bist auf "Längenvergleich", dann laß uns doch das über PN machen. Da kannst du mich dann auch so richtig beleidigen :zwinker: ... aber bitte nur auf Basis meiner Aussagen, nicht auf Basis deiner eigenen.

Nachtrag: Hier nochmal dieses Thema mit dem Wort "Treiber" hervorgehoben. Dann kannst du vielleicht nochmal über deine Unterstellungen nachsinnen.

[alcaeus]

Hallo ihr beiden,

Zitat:

Zitat von Olli

dann laß uns doch das über PN machen.

bitte macht genau das. So bringt das wirklich nichts, und langsam ist das Thema auch OT genug. Das hilft keinem.

Greetz
alcaeus

[generic]

ja unkaputtbar :

Zitat:

Note that the FSCTLs are implemented such that you CANNOT corrupt data on your drive by using them.

[Olli]

Zitat:

Zitat von generic

ja unkaputtbar :

Zitat:

Note that the FSCTLs are implemented such that you CANNOT corrupt data on your drive by using them.

Wenn du es so meinst, stimmt es (alles andere wäre schlimm ;) ). Du sprachst aber von APIs, daher wohl das Mißverständnis. Sorry.

[starY]

Gut danke an alle, auch wenn der Thread mehr zum Streitthema über Delphi geworden ist.
Maels Methode geht und diese finde ich auch einfacher. Aber wie so immer gibt es mehrere Methoden ;)

Delphi-Quellcode:

DeviceIoControl(DeviceHandle, IOCTL_DISK_GET_DRIVE_GEOMETRY, nil, 0,
    @DiskGeometry, sizeof(DiskGeometry), Dummy, nil);

Ich hab nochmal eine Frage zu dieser Funktion... irgendwie will mein Delphi IOCTL_DISK_GET_DRIVE_GEOMETRY und Dummy nicht ;) Welche uses muss ich dafür einbinden?

NTFS läuft außerdem nur unter NT (von haus aus) und höher deswegen bringt es nichts wenn ich 9x Unterstützung mache. ;)

[Olli]

Zitat:

Zitat von starY

Delphi-Quellcode:

DeviceIoControl(DeviceHandle, IOCTL_DISK_GET_DRIVE_GEOMETRY, nil, 0,
    @DiskGeometry, sizeof(DiskGeometry), Dummy, nil);

Dummy muß vom Typ DWORD sein, und wenn in deiner DeviceIoControl()-Deklaration statt "var Returned: DWORD" ein "Returned: PDWORD" steht, dann mußt du "@Dummy" notieren.
BTW: Ab XP gibt es auch IOCTL_DISK_GET_DRIVE_GEOMETRY_EX.

Verrätst du mir bitte noch, wie du die Wiederherstellung der Daten löst? Aktuell waren wir ja da stehen geblieben, daß man mit Administratorrechten sowohl Defragmentierung als auch sektorweises Auslesen durchführen kann. Mehr machst du ja mit maels Beispielcode (noch) nicht (als Auslesen - nicht daß es wieder zu Mißverständnissen kommt).

Nachtrag: Ich bezweifle, daß die IOCTLs irgendwo deklariert sind im Standard-Delphi. Entweder behilfst du dir, indem du sie selber übersetzt, oder du schaust mal in DelphiWorks von Codehunter - er hat IMO Code zum Thema drin. Ansonsten wären die JEDI JCL und ApiLib (JwaWinIoctl.pas - dort ist der gesuchte Code definitiv drin, aber SF ist grad down) noch eine Anlaufstelle.


PS: Habe mal CVS-Version 1.6 von der JwaWinIoctl.pas anghangen, damit du nicht auf SF.net angewiesen bist, wenn es doch grad down ist ;)

[starY]

NTFS speichert ja die gelöschten Dateien (bzw. den Zeiger auf den Datenbereich) in einem Log file record. Ich weiß zwar gerade nicht wieviele Dateien dort gespeichert bleiben aber ich wollte mich erstmal darauf beschränken. Danach mich dann wohl mit MBR bzw Partitionstable recovery beschäftigen und dann vielleicht Datenstrukturen analysieren, wobei ich davon noch keine Ahnung habe.

Die IOCTLs sind wirklich nicht in Standard Delphi deklariert. Nur ist SF.net leider wirklich down und die pas Datei, die du angehängt hast, braucht leider noch ein paar mehr pas Dateien, welcher aber wohl wieder andere pas Dateien brauchen. :(

PS: 7z-Format ist vielleicht ein wenig exotisch aber darüber lässt sich ja bekannterweise streiten ;D

[Olli]

Die anderen PAS-Dateien solltest du nicht brauchen. Ansonsten mußt du mir nochmal sagen welche du brauchst. Habe eine lokale Kopie. Dauert aber dann eine Weile, weil ich gleich weg muß.

[generic]

Zitat:

Zitat von starY

PS: 7z-Format ist vielleicht ein wenig exotisch aber darüber lässt sich ja bekannterweise streiten ;D

nix, ist cool, ist free und hat eigendlich jeder ;-)

ich weiss nicht welche version von der jwa ich hier ab.
aber es ist immer noch besser als keine, oder?

[generic]

ups hier gibts was neueres:
http://members.chello.nl/m.vanbrakel2/

[Olli]

Zitat:

Zitat von generic

ups hier gibts was neueres:
http://members.chello.nl/m.vanbrakel2/

Ist definitiv nicht neuer (May, 2004?!). Glaub mir einfach.

Marcel hat seine Header ja für das JEDI AiLib-Projekt spendiert. Ich persönlich arbeite am meisten an der JwaNative.pas (ist inzwischen >70% größer als Marcels Ursprungsversion). Also alles im ApiLib-Projekt ist neuer.

[Daniel G]

@StarY:

Ich weiß ja net, was du für eine Internetverbindung hast. Aber, wenn du DSL hast, würde ich mir an deiner Stelle das PSDK von der Microsoft - HP herunterladen. Da hast du dann auch gleich Headerdateien dabei (allerdings in C). Aber die Werte für die IOCTL - Konstanten stehen da drinne, also eine unschätzbare Hilfe ;)

[Olli]

Notfalls kann ich's dir auch auf CD zuschicken, wenn du kein DSL hast. Einfach PN an mich ;)

Übrigens sind die meisten IOCTLs keine festen Werte, sondern vielmehr Makros. Die können sich leider auch irgendwann mal ändern *schnief* ... das wird ein Wartungsalptraum.

[Christian Seehase]

Moin Olli,

Zitat:

Zitat von Olli

Die können sich leider auch irgendwann mal ändern *schnief*

gehst Du wirklich davon aus? (kann ich mir eigentlich nicht vorstellen ;-))
Dann würden "ältere" Programme, schlagartig, nicht mehr funktionieren.

Zitat:

Zitat von Olli

Übrigens sind die meisten IOCTLs keine festen Werte, sondern vielmehr Makros.

So wie die aufgebaut sind, macht das auch Sinn, denn dann kann man die Werte leichter um neue ergänzen.

[starY]

Ja DSL hab ich aber es geht schon mit der JwaWinIoctl.pas.

Nochmals danke für die Hilfe. ;)

Bin mal weiter testen und probieren ;D

MfG

starY

[Olli]

Zitat:

Zitat von Christian Seehase

Zitat:

Zitat von Olli

Die können sich leider auch irgendwann mal ändern *schnief*

gehst Du wirklich davon aus? (kann ich mir eigentlich nicht vorstellen ;-))
Dann würden "ältere" Programme, schlagartig, nicht mehr funktionieren.

Wahrscheinlich hast du recht. Nur, als C-Programmierer würdest du's ja garnicht bemerken, weil der Wert vom Präprozessor jedesmal neu berechnet wird. Aber bei diesen speziellen Werten dürfte eine Änderung dank der resultierenden Rückwärtsinkompatibilität so gut wie ausgeschlossen sein. Hast schon recht ;)