none
Auslesen der Pfade die aktuell im Windows Explorer geöffnet sind, diese zwischenspeichern und später wieder öffen (ohne Admin-Rechte) RRS feed

  • Frage

  • Hallo Gemeinschaft.

    Inzwischen habe ich bestimmt schon einen Tag gesucht und stoße nur auf entweder vollkommen irrelevantes oder in anderen Skript-Sprachen die Installationen oder Admin-Rechte fordern - beides DARF jedoch nicht nötig sein!

    Wie der Titel schon aussagt, möchte ich die Im Explorer (oder auch weiteren Programme) geöffneten Pfade bzw. Dateien zwischenspeichern und diese dann nach einem Neustart des Rechners manuell, zeitverzögert oder an ein event gebunden wieder starten.

    Da es üblich ist, dass man immer hinterfragt wird, hier der Grund:

    Auf meinen Firmen-Notebook verliere ich die Explorer-Fenster, wenn ich mich per VPN anmelde, da die VPN-Verbindung leider erst nach dem Anmelden erfolgt.
    Ergo - Bei Anmeldung existieren nur die lokalen Pfade und somit findet Windows die Netzwerkpfade nicht.

    Nun möchte ich quasi diesem Problem entgegnen, indem ich die Pfade der geöffneten (ich habe immer viele auf) speichere und NACH dem VPN-Aufbau wiederherstelle/öffne.

    Wäre super, wenn hier jemand eine Lösung oder wenigstens richtweisende Code-Schnipsel für mich PowerShell-Laien hätte. ;)

    Danke!


    • Bearbeitet ACX_Com Freitag, 18. Oktober 2019 08:12 Schreibfehler
    Freitag, 18. Oktober 2019 08:11

Alle Antworten

  • Moin,

    also die Liste bekommst Du mit Handle. Das ist zwar schon ein externes Programm, muss aber nicht installiert werden; es lässt sich auch ohne Adminrechte starten.

    Ansonsten sind hier Beispiele (allerdings in C++), wie man native Windows NT-APIs dafür ansprechen kann. Die Übersetzung nach .NET und somit auch nach PowerShell erleichtert https://www.pinvoke.net/.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 18. Oktober 2019 09:11
  • Moin,

    hier ist noch ein schöner Fingerzeig, direkt für PowerShell: https://devblogs.microsoft.com/scripting/weekend-scripter-determine-process-that-locks-a-file/


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 18. Oktober 2019 09:48
  • Hallo und vielen Dank Evgenij.

    Mit "Handle" habe ich es probiert, aber ich komme nicht bis zum Finale, dass ich wirklich (mir aktuell am wichtigsten) nur die Pfade der "aktuell offenen" Windows Explorer erhalte.

    Angeblich basiert der Process Explorer ja auf Handle - oder umgekehrt oder auf die gleiche Funktionsweise.

    Aber selbst im Process Explorer finde ich unter explorer.exe nur den Pfad des zuletzt aktiven Windows Explorers unter "Window Title".
    Sobald ich das Explorer-Fenster wechsle, wird dieser Wert in den Pfad des neuen Fensters geändert.

    Leider ist der download-Link zu PInvoke offline.

    BG

    Freitag, 18. Oktober 2019 10:32
  • Ich glaube, Ihr redet "ein klein wenig" aneinander vorbei. Der TO will den Ordner wieder öffnen, den der Explorer grad anzeigt. Der taucht in "Handles" nirgends auf... Der TO sucht https://stackoverflow.com/questions/20960316/get-folder-path-from-explorer-window

    Da bin ich aber raus, ob und wenn ja wie das in Powershell native geht. PInvoke ist mir zu hoch :-)


    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Freitag, 18. Oktober 2019 14:36
  • Der TO will den Ordner wieder öffnen, den der Explorer grad anzeigt. Der taucht in "Handles" nirgends auf... 

    doch, natürlich :-) 

    handle -p explorer | findstr \Device\Mup\FILESERVER
    liefert alles, was auf dem Fileserver "\\FILESERVER" durch den Prozess "explorer" geöffnet ist.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 18. Oktober 2019 14:51
  • Ok, stimmt - taucht auf. Nur "wie identifizieren"? Das "Grundrauschen" von handle ist so groß, das halte ich mal für unmöglich.

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Freitag, 18. Oktober 2019 15:10
  • Ok, stimmt - taucht auf. Nur "wie identifizieren"? Das "Grundrauschen" von handle ist so groß, das halte ich mal für unmöglich.


    Komfortabel ist es nicht, das steht fest. Und für lokale Pfade würde ich das niemals auch nur erwägen. Bei Remote-Pfaden hingegen, und um die ging's ja dem TO, könnte es gerade so funktionieren...

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 18. Oktober 2019 15:21
  • Vielen Dank für Eure Hilfe.

    Inzwischen bin ich zwar schon weiter, aber mich stört noch UNC statt Laufwerks-Buchstabe.

    Aufgrund der zwei Handles (3BB0 und 558C) bekomme ich immer zwei Mal das gleiche, aber das kann ich ja vergleichend abfangen - außer es gäbe auch hier noch was vernünftigeres (k.A. was die Nummern aussagen). ;)

    Hier erst mal mein aktuelles-Auslese-Script:

    $Pfade = D:\Downloads\temp\Handle\handle -p explorer | findstr "Mup"
    foreach($i in $Pfade)
    {
        $Ausgabe += "handle-Path: $i`r`n"
        $x = $i.LastIndexOf("Mup") + 3
        $Ausgabe += "Mup-Pos: $x`r`n"
        $Ausgabe += "Path: \$($i.Substring($x))" + "`r`n"
        $Ausgabe += "`r`n"
    }
    $Ausgabe > expl-Mup-paths.txt

    Ausgabe expl-Mup-paths.txt (vorübergehend):

    handle-Path:  3BB0: File          \Device\Mup\192.168.2.4\temp\
    Mup-Pos: 32
    Path: \\192.168.2.4\temp\

    handle-Path:  558C: File          \Device\Mup\192.168.2.4\temp\
    Mup-Pos: 32
    Path: \\192.168.2.4\temp\

    Was mich also stört:
    Ich habe leider viele verschiedene UNC's zu nutzen und die merke ich mich mir nicht gerne/nur schwer. :/

    Nun wär's noch besser, wenn eben der verbundene Laufwerksbuchstabe anstatt die IP bzw. UNC-Pfad zum Öffnen verwendet werden könnte - wie eben ursprünglich.

    (Obiges Beispiel basiert auf mein lokales zuhause)

    Hat hierzu noch jemand eine Idee?

    Ich habe es mal bei WinLister von http://www.nirsoft.net/ angesehen, der zeigt mir die Pfade wie benötigt, hat aber scheinbar keinen Command-Line-Zugriff /-Schnittstelle.

    Samstag, 19. Oktober 2019 12:15
  • Bei den Handles liegt es in der Natur der Sache, dass nach einem Open das Ursprungslaufwerk nicht mehr benötigt wird.
    Du könntest dir da noch die aktuelle Drives-Liste mit dem Pfad dazu holen und dann eben abgleichen.
    https://docs.microsoft.com/de-de/dotnet/api/system.io.driveinfo?view=netframework-4.8

    Alternativ kannst du ja ein kleines C#-Programm schreiben und als PS-Addin bereitstellen.
    https://stackoverflow.com/questions/7268302/get-the-titles-of-all-open-windows

    Samstag, 19. Oktober 2019 13:50
  • Nach etwas Sucherei bin ich auf eine Idee gekommen PowerShell etwas zu "durchtesten" und bin auf "Get-PSDrive" gestoßen.

    Dies listet alle Laufwerke inkl. UNC auf - muss halt nur noch weiter basteln, filtern etc., dann sollte eine Kombination mit obigem Script möglich sein.

    ...braucht halt für einen wie mich, der 1x im Jahr ein wenig coded lange. ;)

    UPDATE:

    Leider musste ich jetzt feststellen, dass "handle" nicht "nur" die aktuell offenen Pfade listet, sondern wohl deutlich hinterher hinkt und auch alle Ebenen unter einem aktuellen Ordner jeweils als eigene Instanz aufführt.

    Beispiel:
    Offen ist \\IP\Freig\Ordner1\Ordner2\Ordner3

    handle spuckt mir aus:

    \\IP\Freig\
    \\IP\Freig\Ordner1\
    \\IP\Freig\Ordner1\Ordner2\
    \\IP\Freig\Ordner1\Ordner2\Ordner3\

    So kann ich das nicht brauchen, da habe ich am Ende mehr Arbeit als alles manuell zu öffnen - Misst! :(

    Sobald ich aber dieses eine Explorer-Fenster schließe, wird gar kein Eintrag mehr von oben mit angezeigt.
    U.U. merkt sich handle die History (Vor - Zurück)

    • Bearbeitet ACX_Com Samstag, 19. Oktober 2019 15:08
    Samstag, 19. Oktober 2019 14:20