🥇Windows, PowerShell és hosszú utak

Azt gondolom, hogy Önnek, akárcsak nekem, nem egyszer kellett már látnia a következő típusú útvonalakat !!! Fontos____Új____!!! Ne törölje!!! 98819-649-B/1985. február 30-i rendelet K. Ivan Alekszandrovics ideiglenes megbízottként a vállalati VIP-kliensek kíséretéért és az üzleti találkozók megszervezéséért.doc.

Gyakran előfordul, hogy egy ilyen dokumentumot nem tudunk azonnal megnyitni Windows rendszerben. Valaki fájlmegosztásos megoldásokat használ, mások olyan fájlkezelőket alkalmaznak, amelyek képesek kezelni a hosszú útvonalakat: Far Manager, Total Commander és hasonlók. Sokak csalódottan látták, hogy az általuk létrehozott PS-skript, amelybe sok munkát fektettek és a tesztkörnyezetben jól működött, éles környezetben tehetetlenül panaszkodik a teljesíthetetlen feladatra: A megadott útvonal, fájlnév vagy mindkettő túl hosszú. A teljes fájlnévnek kevesebb mint 260 karakteresnek, az útvonalnak pedig kevesebb mint 248 karakteresnek kell lennie.
Kiderült, hogy 260 karakter nem biztos, hogy mindenkinek elegendő. Ha érdekli, hogyan lehet túllépni a megengedetthez, kérem, lapozzon tovább.

Íme néhány szomorú következménye a fájlútvonal hosszának korlátozásának:

a szerveren van egy mappa, például D:DataSharedAccounting, amely SMB-n keresztül meg van osztva, és a felhasználók hálózati meghajtóként S-ként csatlakoznak; a felhasználók olyan fájlokat hoznak létre, amelyeket a rendszergazdák / szkriptek nem tudnak olvasni helyi hozzáférés esetén, mert az abszolút útvonal hosszabb, mint a hálózati;
szinkronizálási hibák a migrált profilokkal;
problémák a shadow copy-ból való helyreállítással;
más rendszerekből történő adatátvitel során, ahol a fájlútvonal hosszúságára vonatkozó korlátozások kevésbé szigorúak, az új környezetben egy részük elérhetetlenné válik különféle trükközés nélkül;
hibás adatok a mappák fájljainek mérete és mennyisége számításakor;
stb...

Kicsit eltérve a témától, megjegyzem, hogy DFS Replikáció esetén a cikkben tárgyalt probléma nem olyan rémisztő, és a hosszú nevű fájlok sikeresen utaznak a szerverről a szerverre (ha persze minden mást rendben csinált) helyesen csináltad).

Szeretném még felhívni a figyelmet egy nagyon hasznos és több alkalommal is megmentő segédprogramra robocopy. Ez is képes kezelni a hosszú útvonalakat, és sok mindenre képes. Tehát ha a feladat fájlok másolására/átvitelére vonatkozik, érdemes megragadni. Ha pedig az Access Control List-ekkel (DACL) akarunk játszadozni, nézzünk a subinaclA tekintélyes életkor ellenére remekül teljesített a Windows 2012 R2-n. Itt a felhasználási módok áttekintése.

Engem azonban érdekelt, hogy megtanuljam, hogyan kell kezelni a hosszú útvonalakat a PowerShell-ben. Olyan ez, mint a régi vicc Ivárról és Vasilisáról.

Gyors mód

Átállni Linuxra és nem foglalkozni a Windows 10/2016/2019-el, valamint aktiválni a megfelelő csoportházirendet/szabályozni a regisztert. Erről a módszerről nem állok meg részletesebben, mert az interneten már sok cikk található a témában, például ez.

Figyelembe véve, hogy a legtöbb cégnél sok, finoman szólva, elavult verzió található az operációs rendszerekkel, ez a módszer csak papíron gyors, hacsak nem számítasz azok közé, akiknek kevés örökölt rendszere van, és jellemzően Windows 10/2016/2019 van.

Hosszú mód

Itt azonnal meg kell jegyezni, hogy a változások nem érintik a Windows fájlkezelő működését, hanem lehetővé teszik a hosszú útvonalak használatát a PowerShell parancsokban, mint például Get-Item, Get-ChildItem, Remove-Item és mások.

Először is frissítsük a PowerShell-t. Ez egy-két-három lépésben elvégezhető.

Frissítjük a .NET Framework-ot legalább 4.5-ös verzióra. Az operációs rendszernek legalább Windows 7 SP1/2008 R2-nek kell lennie. A legfrissebb verziót letöltheted itt, további információért olvass utána itt.
Töltsük le és telepítjük a Windows Management Framework 5.1-et.
Újraindítjuk a gépet.

A szorgalmasak kézi úton elvégezhetik a fent említett lépéseket, míg a lusták SCCM, házirendek, szkriptek és más automatizálási eszközök segítségével végezhetik el.

A jelenlegi PowerShell verziót a következő változóból tudhatod meg: $PSVersionTable. A frissítés után nagyjából így kell kinéznie:

Most, amikor parancsokat használsz, mint például Get-ChildItem és hasonlók, a megszokott Útvonal Belső célú információk tárolásához LiteralPath.

formátum egy kicsit más lesz:

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

A szokásos formátum és a LiteralPath formátum közötti átkonvertálás megkönnyítésére az alábbi funkciót használhatod:

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"}
}

Ne feledd, hogy a paraméter megadásakor LiteralPath nem használhatsz helyettesítő karaktereket (*, ? stb.).

A paraméteren kívül LiteralPath, a frissített verziójú PowerShell parancs Get-ChildItem kapott egy Depthparamétert is, amellyel a rekurzív keresés mélységét határozhatod meg, pár alkalommal használtam és meg voltam elégedve vele.

Most már nem kell attól tartania, hogy a PS-skripte elveszíti a hosszú és nehéz utat, és nem veszi észre a távoli fájlokat. Engem például nagyon segített ez a megközelítés, amikor scriptet írtam a „ideiglenes” attribútum eltávolítására a DFSR mappákban található fájloknál. De ez már egy másik történet, amiről megpróbálok beszélni egy másik cikkben. Öntől érdekes hozzászólásokat várok, és javaslom, hogy vegyen részt a kérdőívben.

Hasznos linkek:
docs.microsoft.com/hu-hu/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

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.