Device-Treiber erstellen?



  • Hallo,

    Ich möchte sowas wie mit dem SUBST-Befehl erreichen. Also einen Laufwerksbuchstaben auf ein Verzeichnis setzen.

    Allerdings muss ich über JEDE Aktion auf dem Laufwerk (muss im Netzwerk freigegeben sein) informiert werden (ähnlich API ReadDirectoryChangesW()). Verwenden möchte ich das ganze später in einem VB6-Programm.

    Aber jetzt kommts: Ich muss auch merken wenn eine Datei nicht gefunden wird und dann eine eigene Fehlermeldung zurückgeben (zB statt 53 für Datei nicht gefunden zB den Fehlercode 101 mit eigener Bedeutung) oder die Datei erst erstellen können (also eine nicht existierende Datei wird angefordert und ich muss die Daten erst generieren und dann übergeben).

    Kann das jemand? Wenn ja, dann bitte hier im Forum melden. Wäre ein kommerzielles Projekt.

    Grüsse,

    Volker



  • Hm, deine eigenen Fehlercodes willst du die von eigenen Funktionen zurückbekommen oder von den Standardsuchfunktionen von Windows?



  • Hi dEUs,

    Hm, deine eigenen Fehlercodes willst du die von eigenen Funktionen zurückbekommen oder von den Standardsuchfunktionen von Windows?

    Wenn eine Anwendung auf einem Laufwerk eine Datei nicht findet, liefert Windows einen Fehlercode (53?). Ich würde in diesem Fall mit meinem Laufwerk gerne einen anderen Code liefern können (zB 101 oder sowas).
    Es geht darum, dass eine Anwendung diesen Code erhält und ggfs speziell darauf reagieren kann (zB später nochmals versuchen) oder eine spezielle Meldung ausgeben kann.
    Wichtig ist aber auch, dass ich die Meldung verzögern kann um zB die Daten erst zu generieren und dann zu sagen: ja, die ist da und hier hast Du sie.

    Oder anderst: Die Lösung soll ein Laufwerk simulieren bei dem ICH bei jeder aktion (Neuerstellung, Überschreiben, Löschen, nicht finden) wählen kann wie das Laufwerk reagiert.

    Grüsse,

    Volker



  • wenn's für windoof nt/2000/xp sein soll wär' dieses buch vielleicht hilfreich: http://www.oreilly.com/catalog/wininternals/chapter/ch04.html



  • Würde es sich von der Bezahlung her denn lohnen, sich in dieses Thema einzuarbeiten?



  • dEUs schrieb:

    Würde es sich von der Bezahlung her denn lohnen, sich in dieses Thema einzuarbeiten?

    wenn man nicht vorbelastet ist zum thema 'windoof device drivers' dann kann das wohl keiner bezahlen



  • Wieso? Wenn die Bezahlung halbwegs anständig ist, würde ich mich in das Thema einarbeiten und wenn ich denke, ich könnte es schaffen, würde ich Bescheid geben. Nicht umgekehrt: Sagen ich mach's und dann hoffen, dass ich das Thema kapier.

    Btw: Es heisst Windows nicht windoof, ja?



  • Hi,

    mit dem einfügen von eigenen Fehlermeldungen währ ich etwas vorsichtig.

    1. ggf Handelst du dier inkompatibilitäten zu noch erscheinenden windows versionen ein ( windows liefert selber die gleiche fehler id, was passiert dann???)

    2. Wie reagiert windows auf neue Fehlercods die es selber nicht kennt? einfach weiterreichen durch die eigene API, absturtz, einfach unterbinden ???

    3. Wie soll sich eigentlich windows verhalten wenn aus versehen ein benutzer auf dein im netzwerk freigegebenes laufwerk zugreift und einen solchen fehler produziert? Es kennt ja den Fehlercode nicht und kann auch nicht entsprechend drauf reagieren. ( wie ferhält sich dann dein treiber? )

    also wenn ich das jetzt richtig verstanden hab. dein treiber will mitbekommen was auf dem laufwerk gelesen und geschrieben wird. Fehlschläge werden vom Treiber abgefangen und gegebenenfals zu einem spähteren zeitpunkt nachgeholt werde. Werden daten angefordert die z.B. in einer Datenbank existieren aber momentan nicht verfügbar sind ( z.B. gelockt ) wird deine besondere Fehlermeldung zurückgegeben, Dein Treiber versucht dann zum nächstmöglichen zeitpunkt die daten in einer datei bereitzustellen, damit die applikation drauf zugreifen kann.

    Allein punkt 3 würde mich eher veranlassen eine art eigenes netzwerk protokoll zu implementieren. anstelle windows neue fehlercods beizubringen.

    gruss Termite



  • wenn man keinen eigenen filesystem driver entwickeln will, weil's zuviel aufwand bedeutet etc. dann könnte man auch die funktion 'CreateFile' systemweit 'hooken'.
    guckt ihr hier: http://research.microsoft.com/~galenh/Publications/HuntUsenixNt99.pdf



  • @dEUs: Den Preis weiss ich noch nicht. Ich wollte zuerst wissen wie gross der Aufwand ist. Es ist schon richtig, dass sowas am besten von jemandem gemacht wird der sowas Ähnliches schonmal realisiert hat. Ich will definitiv nur für das Entwickeln bezahlen und nicht für das Einarbeiten in's Thema. 🙄

    @Termite: Was Du verstanden hast ist soweit korrekt. Windows selbst soll sich nicht anderst verhalten. Ich weiss nur, wenn ich mit I/O-Funktionen auf ein Laufwerk zugreife, dann erhalte ich meistens 53 wenn die Datei nicht da ist. Ich möchte diese Zahl eben beeinflussen können. Ebenso möchte ich die Fehlermeldung herauszögern können da ich die Datei evtl. noch schnell erstellen kann. Danach kann Sie ja ganz normal geliefert werden.
    Ein eigenes Protokoll würde nur ganz speziellen Anwendungen erlauben mit diesem 'Laufwerk' zu arbeiten. Es muss aber allgemein zugänglich bleiben.

    @Net: Schon. Kann man auch einen 'FileNotFound' hooken? Soweit ich weiss nicht. Sonst könnte ich auch mit dem API Befehl ReadDirectoryChangesW() und GetOverlappedResult() arbeiten. Da fehlen mir aber die angesprochenen Funktionen.

    Wer traut sich das Zu und mit welchem Aufwand müsste ich rechnen? Evtl. eine Stundenschätzung? 😕

    Grüsse,

    Volker



  • Volker Schmid schrieb:

    @Net: Schon. Kann man auch einen 'FileNotFound' hooken? Soweit ich weiss nicht.

    doch, ungefähr so

    HANDLE MyCreateFile (...
    {
        HANDLE h = CreateFile (....
        if (h != INVALID_HANDLE_VALUE)
           return h;
        /*
         *  hier fehler behandeln
         */
    }
    


  • brauchste doch eigentlich nur eine Wrapper DLL, die die Dateizugriffsfunktionen enthält (weiß grad nicht, welche das ist).

    Damit kann man sogar leicht ein Laufwerk simulieren. Ich weiß nur nicht, in wie weit der Dateiexplorer auf diese Funktionen zugreift, müsste er aber eigentlich.



  • Loggy schrieb:

    brauchste doch eigentlich nur eine Wrapper DLL, die die Dateizugriffsfunktionen enthält (weiß grad nicht, welche das ist).

    kernel32.dll. die heisst aber nur so, hat wohl historische gründe. ist nicht der kernel von windows.

    Loggy schrieb:

    Ich weiß nur nicht, in wie weit der Dateiexplorer auf diese Funktionen zugreift, müsste er aber eigentlich.

    letztendlich gehen alle windoof-proggis über CreateFile/ReadFile/WriteFile, egal ob sie 'fopen', 'ostream' oder sonstwas benutzen.



  • dann ist es doch kein Problem...



  • Hi

    @Volker Schmid

    Genau diese neuen Fehlermeldungen machen mir am meisten kopfzerbrechen. Du solltest sicherstellen, das dann der normale zugriff auf das laufwerk fehlerfrei funktioniert.

    anders herum könnte man auch bei einem eigenen netzwerk protokoll einen eigenen kleinen treiber schreiben, der ein Windowslaufwerk auf das netzwerkprotokoll mapt. diser treiber versteht deine ganz speziellen fehlermeldungen und kann daraus dan windows konforme generieren. Problem dabei ist, das nur rechner die den treiber installiert haben auf das laufwerk zugreifen können.

    gruss Termite



  • Ok,

    Ich mache es nochmals kurz. Ich möchte folgendes Erreichen:

    1. Anforderung
    Ich mappe ein Verzeichnis auf einen Laufwerksbuchstaben (alternativ würde auch die Überwachung eines Verzeichnisses incl. Unterverzeichnissen ausreichen wenn ich denn dann vor allem den FileNotFound hooken könnte).

    2. Anforderung
    Ich muss ALLES mitbekommen was hier passiert. Dazu zählt vor allem, dass ich mitbekommen muss wenn eine Datei erstellt oder nicht gefunden wird. Im zweiten Fall muss ich etwas tun können:
    a. Die Datei generieren und dann normal liefern
    b. oder einen Fehlercode liefern der sich vom normalen 'file not found' unterscheidet.

    3. Anforderung
    Nutzbar unter VB6. Ich kann ja eine Callback-Routine angeben oder eine Art Messagepuffer auslesen (zweites wäre mir lieber. Könnte das dann in einem Timer machen).

    Evtl. hilft es, wenn ich den Sinn erkläre. Ich möchte aber nicht zu viel von meiner Programm-Idee preisgeben um Nachahmer zu bremsen (habe da schon schlechte Erfahrung).
    Immer dann wenn in meinem Szenario eine Datei nicht gefunden wird, kann ich diese zu 90% anderst generieren. Das kann aber durchaus auch 10 Minuten dauern. Wenn ich es schnell kann, möchte ich die Datei generieren. Wenn nicht, möchte ich einen Code zurückgeben der es anderen Anwendungsentwicklern erlaubt darauf anderst zu reagieren als auf einen normalen FileNotFound. Der Code könnte bedeuten 'Versuche es in 10 Minuten nochmal' etc. Wenn auch ich die Datei nicht generieren kann, dann darf gerne ein normales FileNotFound kommen.

    Grüsse,

    Volker



  • Wann brauchst du das denn?



  • @loggy: Es ist nicht sehr Eilig. Allerding schon noch dieses Jahr.

    Volker



  • Wenn du bist mitte Oktober niemanden gefunden hast, würde ich es mal versuchen.

    Ich habe Erfahrung im Ausspionieren von Systemaktivitäten (konkret hatte ich das mal für CD-Rom Aktivitäten implementiert). Deine Erweiterungen sollten da kein Problem sein.



  • Loggy schrieb:

    (konkret hatte ich das mal für CD-Rom Aktivitäten

    mit einem filter driver oder mit 'FindFirstChangeNotification'?
    mit letzterem kriegst du's aber erst mit, wenn's schon zu spät ist.


Anmelden zum Antworten