ProHoster > Blog > Adminisztráció > Windows, PowerShell és Long Paths

Windows, PowerShell és Long Paths

Windows, PowerShell és Long Paths

Azt hiszem, te, akárcsak én, gyakran láttad a forma ösvényeit !!! Fontos____Új____!!! Ne törölje!!!98819. február 649-i 30-1985-B rendelési szám Ivan Alekszandrovics Kozlov kinevezéséről a vállalati VIP ügyfelek támogatásával és üzleti találkozók pályafutásával foglalkozó osztály megbízott vezetőjévé.doc.

És gyakran nem fog tudni azonnal megnyitni egy ilyen dokumentumot a Windows rendszerben. Valaki a megoldást a lemezleképezés formájában gyakorolja, valaki pedig olyan fájlkezelőket használ, amelyek hosszú útvonalakkal működnek: Far Manager, Total Commander és hasonlók. És még sokan szomorúan nézték, ahogy az általuk megalkotott PS-szkript, amelybe rengeteg munkát fektettek, és amely a tesztkörnyezetben, harci környezetben is döcögősen működött, tehetetlenül panaszkodott egy lehetetlen feladatra: A megadott elérési út, fájlnév vagy mindkettő túl hosszú. A teljes képzésű fájlnévnek 260 karakternél, a könyvtárnévnek pedig 248 karakternél rövidebbnek kell lennie.
Mint kiderült, 260 karakter elég "nem csak mindenkinek". Ha érdekli, hogy túllépjen a megengedett határokon, kérem a kat.

Íme néhány sajnálatos következménye a fájl elérési út hosszának korlátozásából:

Kissé eltérve a témától megjegyzem, hogy a DFS-replikáció esetében a cikkben tárgyalt probléma nem vészes, és a hosszú nevű fájlok sikeresen eljutnak szerverről szerverre (kivéve persze, ha másként jól csinálták).

Szeretném felhívni a figyelmet egy nagyon hasznos segédprogramra is, amely már nem egyszer segített robocopy. Ő sem fél a hosszú utaktól, és sokat tud. Ezért, ha a feladat a fájladatok másolására/átvitelére irányul, megállhat ennél. Ha bajlódnia kell a fájlrendszer-hozzáférési listákkal (DACL), nézzen félre subinacl. Jelentős kora ellenére tökéletesen megmutatta magát Windows 2012 R2-n. Itt alkalmazási módokat mérlegeljük.

Az is érdekelt, hogy megtanuljam, hogyan kell dolgozni hosszú PowerShell-útvonalakkal. Vele, szinte úgy, mint egy szakállas viccben Ivan Tsarevicsről és Szép Vasziliszáról.

Gyorsan

Váltson Linuxra, és ne aggódjon a Windows 10/2016/2019 miatt, és engedélyezze a megfelelő csoportházirend-beállítást / beállításjegyzék-beállítást. Ezt a módszert nem részletezem, mert. már sok cikk van a neten ebben a témában, pl. ezt.

Tekintettel arra, hogy a legtöbb cégnél sok, finoman szólva nem friss operációs rendszer létezik, ez a módszer csak papírra íráshoz gyors, kivéve persze, ha Ön azon szerencsések közé tartozik, akiknek kevés régi rendszerük és Windows-uk van. 10/2016/2019 uralkodás .

hosszú út

Itt azonnal leszögezzük, hogy a változtatások nem befolyásolják a Windows Intéző működését, de lehetővé teszik a hosszú elérési utak használatát a PowerShell-parancsmagokban, például Get-Item, Get-ChildItem, Remove-Item stb.

Először frissítsük a PowerShellt. Elkészült egy, kettő, három.

  1. A .NET-keretrendszert legalább 4.5-ös verzióra frissítjük. Az operációs rendszernek legalább Windows 7 SP1/2008 R2-nek kell lennie. Az aktuális verzió letölthető ittolvassa el a további információkat itt.
  2. Töltse le a és telepítse a Windows Management Framework 5.1-et
  3. Újraindítjuk a gépet.

A szorgalmasak a fenti lépéseket manuálisan, a lusták SCCM, házirendek, szkriptek és egyéb automatizálási eszközök segítségével tehetik meg.

A PowerShell aktuális verziója megtalálható a változóból $PSVersionTable. A frissítés után így kell kinéznie:

Windows, PowerShell és Long Paths

Most, amikor parancsmagokat használ Get-ChildItem és mások is hozzá hasonlók a megszokott helyett Útvonal használni fogjuk LiteralPath.

Az útvonalak formátuma kissé eltérő lesz:

Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"

Az útvonalak szokásos formátumról a formátumba való konvertálásának kényelme érdekében LiteralPath használhatja ezt a funkciót:

Function ConvertTo-LiteralPath 
Param([parameter(Mandatory=$true, Position=0)][String]$Path)
    If ($Path.Substring(0,2) -eq "") {Return ("?UNC" + $Path.Remove(0,1))}
    Else {Return "?$Path"}
}

Kérjük, vegye figyelembe, hogy a paraméter beállításakor LiteralPath helyettesítő karakterek nem használhatók (*, ? és így tovább).

A paraméter mellett LiteralPath, a frissített PowerShell-parancsmagban Get-ChildItem fogadott paraméter Mélység, mellyel be lehet állítani a rekurzív kereséshez a beágyazási mélységet, párszor használtam és elégedett voltam.

Most már nem félhet attól, hogy a PS-szkriptje eltéved egy hosszú, bonyolult útról, és nem fog látni távoli fájlokat. Ez a megközelítés például sokat segített, amikor olyan szkriptet írtam, amely visszaállítja a DFSR mappákban lévő fájlok „ideiglenes” attribútumait. De ez egy másik történet, amelyet megpróbálok elmondani egy másik cikkben. Várom érdekes észrevételeiteket, és javaslom egy felmérés kitöltését.

Hasznos linkek:
docs.microsoft.com/en-us/dotnet/api/microsoft.powershell.commands.contentcommandbase.literalpath?view=powershellsdk-1.1.0
docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-5.1
stackoverflow.com/questions/46308030/handling-path-too-long-exception-with-new-psdrive/46309524
luisabreu.wordpress.com/2013/02/15/theliteralpath-parameter

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

A hosszú utak problémája aktuális az Ön számára?

  • Igen

  • Lényeges volt, de már eldöntött

  • Zavar, de nem sokat

  • Nem gondoltam rá, úgy tűnik, minden működik

  • Nincs

  • Egyéb (jelölje meg a megjegyzésekben)

155 felhasználó szavazott. 25 felhasználó tartózkodott.

Forrás: will.com

Hozzászólás