🥇Windows, PowerShell ja pikad teed

Arvan, nagu mina, olete ka teinud teid, mis näevad välja sellised !!! Oluline____Uus____!!! Ärge kustutage!!! Käsk nr 98819-649-B 30. veebruar 1985. a Kaczynski Ivan Aleksandrovitš ajutiselt täitma juhtimise kohustusi ettevõtte VIP-klientide teenindamisel ja ärikohtumiste korraldamisel kulisside taga.doc.

Ja tihti ei saa sellist dokumenti Windowsis kohe avada. Keegi kasutab töö ümber, näiteks kettamapimist, keegi kasutab failihaldureid, mis suudavad töötada pikkade teedega: Far Manager, Total Commander ja sarnased. Paljud jälgivad ka kurvana, kuidas nende loodud PS-skript, kuhu oli investeeritud palju vaeva ja mis testkeskkonnas töötas suurepäraselt, tootmisääris kurbusega kaebas talumatute ülesannete üle: Määratud tee, faili nimi või mõlemad on liiga pikad. Täielik faili nimi peab olema vähem kui 260 märki ja katalooge nimi peab olema vähem kui 248 märki.
Selgus, et 260 märki ei piisa "kõigile". Kui teid huvitab väljuda lubatud piiridest - palun lugege allapoole.

Siin on vaid mõned kurvad tagajärjed failitee pikkuse piiramise kohta:

serveris on kaust, näiteks D:DataSharedAccounting, mis on jagatud SMB kaudu ja montaaž kasutajatele võrgu kettaks S; kasutajad loovad faile, mida administraatorid / skriptid ei saa lugeda kohalikult juurdepääsuga serverist, kuna absoluutne tee osutub pikemaks kui võrgu-;
süncroniseerimisel kantud profilide vead;
probleemid varukoopiatest taastamisega;
andmete migreerimisel teistest süsteemidest, kus tee pikkuse piirangud on vähem ranged, osa neist muutub uues keskkonnas kättesaamatuks ilma erilise pingutuseta;
vale teave kaustade failide suuruste ja arvu arvestamisel;
jne...

Veidi teemast kõrvale, märgin, et DFS replikatsiooni jaoks ei ole artiklis käsitletav probleem hirmutav ja pikad nimed failid rändavad serverist serverisse edukalt (kui, muidugi, olete kõik muu tegid õigesti).

Samuti sooviksin tähelepanu juhtida väga kasulikule ja korduvalt aitavale utiliidile robocopy. Sellele pole ka pikad teed hirmutavad, ja ta oskab palju. Nii et kui ülesanne on failide andmete kopeerimine / liigutamine, saab peatuda tema peal. Kui peate töötama failisüsteemi juurdepääsu kontrollil (DACL), vaadake suunas subinacl. Vaatamata soliidsele vanusele on see Windows 2012 R2-s suurepäraselt töötanud. Siin on kaalutletud rakendamisviise.

Mulle aga oli huvitav õpetada PowerShelli kasutama pikaid teid. See on peaaegu nagu vanas naljas Ivani ja Vassilisa kohta.

Kiire viis

Minna Linuxile ja mitte muretseda Windows 10/2016/2019 ning lubada vastav rühmapoliitika parameeter/vihkuda registrit. Selle meetodi üle pikalt ei peatuks, kuna internetis on juba selle kohta palju artikleid, näiteks, see.

Kuna enamikes ettevõtetes on palju, õrnalt öeldes, mitte värskeid operatsioonisüsteemi versioone, on see meetod kiire vaid paberil, kui te ei ole üks neist õnnelikest, kellel on vähe pärandvorme ja kus valitseb Windows 10/2016/2019.

Pikk viis

Koheselt tuleb selgitada, et muudatused ei mõjuta Windows Explorer'i käitumist, vaid annavad võimaluse kasutada pikemaid teid PowerShelli käskudes, nagu Get-Item, Get-ChildItem, Remove-Item jne.

Alustame PowerShelli uuendamisest. See käib kiiresti.

Uuendame .NET Frameworki versioonini 4.5 või kõrgem, operatsioonisüsteem peab olema vähemalt Windows 7 SP1/2008 R2. Aktuaalse versiooni saab alla laadida siin, täiendavat teavet lugeda siit.
Laadime alla ja paigaldame Windows Management Frameworki 5.1.
Taaskäivitame masina.

Töökad saavad ülalkirjeldatud sammud käsitsi teha, laisad aga SCCM-i, poliitikate, skriptide ja muude automatiseerimiseks mõeldud tööriistadega.

Praegust PowerShelli versiooni saab teada muutuja abil $PSVersionTable. Pärast uuendamist peaks see välja nägema umbes nii:

Nüüd, kui kasutame käsklusi Get-ChildItem ja sarnaseid, kasutame tavapärase Path asemel LiteralPath.

Teede formaat on veidi erinev:

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

Mugavuseks teede konverteerimiseks tavapärasest formaadist formaati LiteralPath saab kasutada järgmist funktsiooni:

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

Pange tähele, et parameetri määramisel ei saa kasutada asendussümboleid ( LiteralPath jne.).*, ? Lisaks parameetrile

, on uuendatud PowerShelli versioonis käsklusele LiteralPathlisatud parameeter Get-ChildItem Depth , millega saab määrata sügavust rekursiivseks otsinguks; olen seda paar korda kasutanud ja jäänud rahule., mille saad määrata sügavuse taset rekurssiivse otsingu jaoks, olen seda paar korda kasutanud ja jäänud rahule.

Nüüd ei pea kartma, et teie PS-skript eksib pika ja keerulise tee pealt ning ei tuvasta kaugeid faile. Mind on näiteks see lähenemine tõeliselt aidanud, kui kirjutasin skripti, et eemaldada atribuut „ajutine” DFSR-kaustade failidelt. Kuid see on juba teine lugu, millest püüan rääkida teises artiklis. Ootan teie huvitavaid kommentaare ja pakun osaleda küsitlusel.

Kasulikud lingid:
docs.microsoft.com/et-ee/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

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.