Powershell Test-Path gibt False zurück, wenn eine Netzwerkfreigabe getestet wird

Der Benutzer verfügt über die entsprechenden Berechtigungen, die Freigabe zu lesen, und die Freigabe wird ordnungsgemäß zugeordnet. Dieses Problem scheint nur in Powershell v2.0 passierenPowershell Test-Path gibt False zurück, wenn eine Netzwerkfreigabe getestet wird

Wenn ich alle zugeordneten Laufwerke entfernen, ein Laufwerk neu zuzuordnen, und führen Sie Test-Path:

net use /delete * /y 
net use G: \\somefileserver\share 
Test-Path G:\

Test-Path gibt False zurück, auch wenn das Laufwerk ist eindeutig zugeordnet, und ich kann über Windows Explorer darauf zugreifen. Wenn ich die Powershell-Sitzung schließe und eine neue Sitzung öffne, gibt Test-Path True zurück, wie es sollte. Irgendwelche Ideen zu (A): was könnte das verursachen und wie man es richtig arbeiten lässt, oder (B): Eine andere Möglichkeit, neben dem Test-Path die Existenz eines Netzwerk-Laufwerks zu testen. Ich versuche, ein Anmeldeskript zu schreiben, um die Netzlaufwerke des Benutzers zuzuordnen, und dieses Verhalten macht mich wahnsinnig.

Quelle

2014-03-14 user3418092

Nur für den Rekord: das funktioniert gut in PS v3.0. Das Starten des PS als Administrator erhöht den Unterschied in jeder Version. Laufwerke, die als Standardbenutzer zugeordnet sind, sind in der erhöhten PS nicht sichtbar. –

Wenn das Test-Path Cmdlet wirklich fehlerhaft ist, würde ich vorschlagen, die Exists()-Methode für die .NET-Klasse System.IO.Directory zu verwenden.

[System.IO.Directory]::Exists('G:\'); # This returns $true for me

Quelle

2014-03-14 02:22:09

Wo verliere ich, wenn ich das oben heraus versuche? Habe es ausprobiert und es hat nicht mit einem UNC-Pfad funktioniert, aber lokaler Patch hat funktioniert Aber ich denke, dass ich die Q und A nicht vollständig verstehe ...? –

Um UNC zu validieren:

[bool]([System.Uri]$path).IsUnc

Quelle

2014-11-19 13:28:45 Sager

Für mich den einzigen Weg, um es zu beheben war die vollständige UNC zu verwenden, anstatt die Freigabenamen

Also statt \\server\share habe ich \\server\c$\sharedir

Ein weiteres Problem, das ich lief, war bei der Verwendung Import-Module sqlps musste ich sicherstellen, CD zurück in die Datei sys und dann funktionierten die PS-Befehle normal.

Quelle

2017-03-01 14:02:19 blizz

Ich bin schon seit einiger Zeit auf der Suche nach einer Antwort auf dieses Thema. Ich glaube ich es mit dieser gefunden:

Test-Path $('filesystem::\\Server\share$\install.wim')

Hoffnung aus anderen Ländern :-)

Quelle

2017-04-10 13:52:22

Danke Daniel. Genau das, was ich gesucht habe. – Coding101

Jederzeit @ Coding101. Froh, dass es für andere nützlich ist. –

Danke für diese Frage verwenden können. Obwohl es vor ein paar Jahren war. Aber ich dachte, es könnte anderen Leuten helfen, das gleiche Problem zu haben.

So hatte ich genau das gleiche Problem 2 Netzwerkpfade wie diese versuchen:

$verif_X = Test-Path "X:\" 
$verif_S = Test-Path "S:\" 
if($verif_X -and $verif_S){ 
    Write-Host "X: and S: network paths found" 
} else{ 
    Write-Host "Not all netowrk paths found" 
}

.. Zuerst bekam ich immer> „Nicht alle netowrk Wege gefunden“, die mir wirklich seltsam schien .. als ich diese Pfade in einfache Anführungszeichen (') und suchten nach einem vorhandenen Ordner in denen beide Netzwerkpfade wie folgt zu setzen versucht:

$verif_X = Test-Path 'X:\ISOs' 
$verif_S = Test-Path 'S:\Scripts'

und dann

if($verif_X -and $verif_S){[..]}

Zustand akzeptiert wird ..

ich denke, die Test-Path-Cmdlets ein bisschen buggy ist, da wir nur den ersten Buchstaben eines Netzwerkpfad eingeben .. aber wie dieses ich Fehler nicht mehr bekommen ..

Quelle

2017-11-07 15:28:42

Powershell Test-Path gibt False zurück, wenn eine Netzwerkfreigabe getestet wird

Antwort

Verwandte Themen