GetDriveType liefert anderes Ergebnis wenn EXE als Dienst gestartet

nalor

Hi!
Bastle noch immer an meinem Programm herum welches erkennen soll wenn ein Netzlaufwerk und ein physikalisches Laufwerk den gleichen Buchstaben verwenden.

Wenn ich genau diesen Fall habe und mit GetDriveType diesen speziellen Laufwerksbuchstaben überprüfe erhalte ich wenn das Programm einfach per Doppelklick gestartet wurde "DRIVE_REMOTE" als Ergebnis.
Wenn ich mein Programm über SRVANY.EXE als Dienst starten lasse bekomme ich für den gleichen Fall wie oben beschrieben "DRIVE_FIXED" als Ergebnis, also den Status des physikalischen Laufwerks und nicht des Netzlaufwerks.
Auch wenn ich den Dienst über ein Benutzerkonto und nicht als Systemkonto starte bleibt das Ergebnis das gleiche.

Jemand eine Ahnung warum das GetDriveType verschiedene Ergebnisse liefert?

Oder eine Idee womit ich überprüfen könnte ob ein Laufwerksbuchstabe ein Netzlaufwerk ist?

Danke schon im voraus, Roland

nalor

Also ich habs jetzt mit WNetGetConnection probiert, aber praktisch gleiches Ergebnis: lokal gestartet kriege ich meine Netzlaufwerke zurückgeliefert, über SRVANY.EXE als Dienst gestartet kriege ich die Meldung zurück das meine Laufwerke keine Netzlaufwerke sind...

Vorschläge??

Roland

flenders

Hatte es mit FindFirstVolume und GetVolumePathNamesForVolumeName nicht schon geklappt

nalor

Na prinzipiell funktioniert das ganze ja jetzt schon die längste Zeit, nur will ich es eigentlich als Service im Hintergrung laufen lassen.
Also hab ich hier im Forum ein bisserl gestöbert und bin über Source gestolpert welcher ein Popup bringt wenn eine CD eingelegt wurde. Das ganze hab ich jetzt so modifiziert das meine Funktion gestartet wird wenn sich was an den Laufwerken ändert.
Und als Abschluß wollte ich das ganze eben noch als Service starten damit das ganze auch noch Benutzerunabhängig ist.
Leider reagieren da jetzt die genannten Funktionen etwas anders als wenn man das Programm normal startet, daher lese ich jetzt gerade die Dokumentation zu einem "richtigen" Dienst

mfg, Roland

nalor

Also für heute hab ich genug, folgenden Code hab ich jetzt mal in einen "richtigen" Dienst eingefügt:

if((datei= fopen("C:\\service.log","a+"))!=NULL)
      {
      error=WNetGetConnection("O:",RemoteName,&length);
      switch (error)
         {
         case NO_ERROR: fprintf(datei,"RemoteName: %s\n",RemoteName); break;
         case ERROR_BAD_DEVICE: fprintf(datei,"FEHLER: The string pointed to by the lpLocalName parameter is invalid.\n"); break;
         case ERROR_NOT_CONNECTED: fprintf(datei,"FEHLER: The device specified by lpLocalName is not a redirected device.\n"); break;
         case ERROR_MORE_DATA: fprintf(datei,"FEHLER: The buffer is too small. The lpnLength parameter points to a variable that contains the required buffer size. More entries are available with subsequent calls.\n"); break;
         case ERROR_CONNECTION_UNAVAIL: fprintf(datei,"FEHLER: The device is not currently connected, but it is a persistent connection. For more information, see the following Remarks section.\n"); break;
         case ERROR_NO_NETWORK: fprintf(datei,"FEHLER: The network is unavailable.\n"); break;
         case ERROR_EXTENDED_ERROR: fprintf(datei,"FEHLER: A network-specific error occurred. To obtain a description of the error, call the WNetGetLastError function.\n"); break;
         case ERROR_NO_NET_OR_BAD_PATH: fprintf(datei,"FEHLER: None of the providers recognize the local name as having a connection. However, the network is not available for at least one provider to whom the connection may belong.\n"); 
         }
      DriveType=GetDriveType("O:\\");
     switch (DriveType)
         {
         case DRIVE_UNKNOWN: fprintf(datei,"DriveType: The drive type cannot be determined.\n"); break;
         case DRIVE_NO_ROOT_DIR: fprintf(datei,"DriveType: The root path is invalid. For example, no volume is mounted at the path.\n"); break;
         case DRIVE_REMOVABLE: fprintf(datei,"DriveType: The disk can be removed from the drive.\n"); break;
         case DRIVE_FIXED: fprintf(datei,"DriveType: The disk cannot be removed from the drive.\n"); break;
         case DRIVE_REMOTE: fprintf(datei,"DriveType: The drive is a remote (network) drive.\n"); break;
         case DRIVE_CDROM: fprintf(datei,"DriveType: The drive is a CD-ROM drive.\n"); break;
         case DRIVE_RAMDISK: fprintf(datei,"DriveType: The drive is a RAM disk.\n"); 
         }
         fclose (datei);
      }

Starte ich diesen Code lokal erhalte ich folgendes Ergebnis:

RemoteName: \\dagobert\schrott
DriveType: The drive is a remote (network) drive.

Und über den erwähnten Dienst kriege ich:

FEHLER: The device specified by lpLocalName is not a redirected device.
DriveType: The root path is invalid. For example, no volume is mounted at the path.

WIESO???????????

Bin echt ratlos...

mfg, Roland

nalor

Hab das ganze jetzt nochmal unter W2K getestet, da schauts leicht anders aus (wobei mir die Erkenntnis im wesentlichen auch nix bringt)

Lokal gestartet gehts klarerweise wie oben, und als Dienst folgendes Ergebnis:

FEHLER: The device specified by lpLocalName is not a redirected device.
DriveType: The drive is a remote (network) drive.

Wie man sieht liefert unter W2K der GetDriveType auch als Dienst ein richtiges Ergebnis, WNetGetConnection versagt auch da.

Hab noch immer keine Ahnung woher das kommt... dachte eigentlich die WinAPI setzt so tief an das solche Ungereimtheiten nicht mehr vorkommen können.

Bin von daher noch immer für jeden Hinweis dankbar, Roland

illuminator

hm,
ich kann dir kein genaue Erklärung liefern nur einen Ansatz:
Dienste laufen standmäßig mit der Berchtigung "LocalSystem", was bedeutet, das sie keinerlei Zugriffsrechte auf Laufwerke haben, die z.B. nur für den angemeldeten Nutzer freigegen sind. D.h. wenn du als "User" angemeldet bist, und ein Netzlaufwerk wie "x:\Userhome\" auf nem server gemappt hast, das für deinen Benutzeraccount freigegeben wurde, oder für eine Benutzergruppe/Domäne, in der du Mitglied bist, dann hat dein Dienst da keinerlei Berechtigungen.
Daher könnts kommen. Man kann Dientse auch mit anderen Berechtigungen starten, dann muss man aber auch ein Passwort übergeben.

nalor

Hatte ich leider schon alles getestet, selbst wenn ich den Dienst mit meinem eigenen User starte, mit dem eben lokal alles wunderbar klappt, gehts nicht.

Deswegen hätte ich jetzt eben probiert das ganze mal mit dem aktuellen SDK von Microsoft zu compilieren, hatte dabei jedoch ein paar Probleme diese mit meinem Borland C++ Builder 6 zu verwenden (siehe Posting in dieser Sektion).

Aber Danke für den Hinweis!

mfg, Roland