🥇Windows, PowerShell ja pikad teed

Usun, et olete, nagu mina, korduvalt näinud teed, mis näeb välja nagu !!! Oluline____Uus____!!! Ärge eemaldage!!! Käsk nr 98819-649-B 30. veebruaril 1985 määramise kohta Kozlov Ivan Aleksandrovitš ajutiseks kohusetäitjaks ettevõtte VIP-klientide toe ja äritegevuste korraldamise osakonnas.doc.

Ja sageli ei saa sellist dokumenti Windowsis kohe avada. Keegi praktiseerib töö ümberkorraldamist kettale, keegi kasutab failihaldureid, mis saavad töötada pikkade teedega: Far Manager, Total Commander ja sarnased. Ja paljudele on kurb näha, kuidas nende loodud PS-skripts, millele on kulutatud palju vaeva ja mis testimiskeskkonnas töötas probleemideta, tootmiskeskkonnas abituna ilma abita kurtis liiga keerulise ülesande üle: Määratud tee, failinimi või mõlemad on liiga pikad. Täielikult kvalifitseeritud failinimi peab olema lühem kui 260 tähemärki ja kaustanimi peab olema lühem kui 248 tähemärki.
Nagu selgus, ei piisa 260 märgist "kõigile eluküsimiseks". Kui soovite minna lubatud piiridest kaugemale, palun lugege edasi.

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

serveris on kaust, näiteks D:DataSharedAccounting, mis on jagatud SMB kaudu ja monteeritakse kasutajatele kui võrgudisk S; kasutajad loovad faile, mida adminnid/skriptid ei saa kohaliku juurdepääsu korral serverilt lugeda, kuna absoluutne tee on pikem kui võrgutee;
sünkroonimise vead liigutatavates profiilides;
probleemid varikoopiatest taastamisega;
andmete migratsiooni korral teistest süsteemidest, kus teede pikkusele on vähem ranged piirangud, osad neist uues keskkonnas ei ole enam kättesaadavad ilma lisatööta;
vale teave kaustades failide suuruste ja arvu arvestamisel;
jne…

Kuid veidi teemast kõrvale kaldudes, märkida, et DFS Replication'i puhul ei ole käesolevas artiklis käsitletud probleem hirmutav ning failid pikkade nimedega liiguvad serverist serverisse edukalt (kui muidugi olete kõik muus õigesti teinud) tegid õigesti).

Sooviksin veel juhtida tähelepanu väga kasulikule ja korduvalt mind abistavale utiliidile robocopy. Ka tema ei karda ka pikki teid ning ta oskab palju. Seega, kui ülesanne seisneb failide andmete kopeerimises / liikumises, võib temaga piirduda. Kui on vaja mängida failisüsteemi juurdepääsuloenditega (DACL), vaadake tema poole. subinacl. Hoolimata oma muljetavaldavast vanusest toimib ta suurepäraselt Windows 2012 R2-s. Siin on vaatlemiseks.

Mulle oli huvitav õpetada PowerShelli töötama pikkade teedega. See on nagu vanas anekdoodis Ivani ja kauni Vasilissa kohta.

Kiire viis

Mine Linuxi ja ära muretse Windows 10/2016/2019 ja aktiveeri vastav rühmapoliitika parameeter / tee registris muudatus. Täiendavalt ei hakka ma selle meetodi üle peatuma, kuna veebis on selle kohta juba palju artikleid, näiteks seda.

Arvestades, et enamikus ettevõtetes on palju, pehmelt öeldes, mitte kõige uuemaid operatsioonisüsteemide versioone, on see meetod paberil kiire ainult siis, kui sa pole üks neist õnnelikest, kellel on vähe pärand-süsteeme ja valitsevad Windows 10/2016/2019.

Pikk viis

Siinkohal olgu öeldud, et muudatused ei mõjuta Windowsi failihalduri käitumist, vaid võimaldavad kasutada pikki teid PowerShelli käskudes, nagu Get-Item, Get-ChildItem, Remove-Item ja teised.

Alustamiseks uuendame PowerShelli. See käib väga lihtsalt.

Uuendame .NET Frameworki versioonini, mis ei ole madalam kui 4.5. Operatsioonisüsteem peab olema vähemalt Windows 7 SP1/2008 R2. Aktuaalse versiooni saate alla laadida siit, lisainfot saate lugeda siin.
Lae alla ja installige Windows Management Framework 5.1
Taaskäivitage arvuti.

Need, kes soovivad, saavad ülaltoodud samme teha käsitsi, need, kes soovivad, saavad kasutada SCCM-i, poliitikaid, skripte ja muid automatiseerimisvahendeid.

Praeguse PowerShelli versiooni saab teada muutuja kaudu $PSVersionTable. Pärast uuendamist peaks olema umbes nii:

Nüüd, kui kasutate käskusid Get-ChildItem ja sarnaseid, kasutame tuttava Path asemel LiteralPath.

Teede formaat on nüüd veidi erinev:

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

Mugavuse huvides saab teede muutmiseks tuttavast formaadist LiteralPath kasutada järgmise funktsiooni:

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

Pange tähele, et parameetri määramisel LiteralPath ei saa kasutada kadreerimismärke (*, ? jne).

Lisaks parameetrile LiteralPath, sai PowerShelli uuendatud versioon käsu Get-ChildItem uue parameetri Depth, mille abil saab määrata rekursiivse otsingu sügavuse, olen seda paar korda kasutanud ja jäänud rahule.

Nüüd ei pea muretsema, et teie PS-skript eksiks pika ja keerulise tee peale ega märkaks kaugeid faile. Minu jaoks oli see lähenemine väga abiks, kui kirjutasin skripti, et eemaldada 'ajutine' atribuut failidest DFSR-kaustades. Kuid see on juba teine lugu, millest püüan rääkida teises artiklis. Ootan teie huvitavaid kommentaare ja pakun osa võtta küsitlusest.

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