ProHoster > Dienoraštis > Administravimas > Windows, PowerShell ir Long Paths

Windows, PowerShell ir Long Paths

Windows, PowerShell ir Long Paths

Manau, jūs, kaip ir aš, ne kartą matėte tokius kelius !!! Svarbu____Naujiena____!!! Neištrinti!!!98819 m. vasario 649 d. užsakymas Nr. 30-1985-B dėl Ivano Aleksandrovičiaus Kozlovo paskyrimo laikinai laikinai einantis pareigas verslo VIP klientų aptarnavimo ir verslo susitikimų organizavimo skyriaus vadovu.doc.

Ir dažnai negalėsite iš karto atidaryti tokio dokumento sistemoje "Windows". Kai kurie žmonės praktikuoja problemos sprendimą naudodami disko atvaizdavimą, kiti naudoja failų tvarkykles, kurios gali dirbti su ilgais keliais: Far Manager, Total Commander ir panašiai. Ir daugelis kitų su liūdesiu stebėjo, kaip jų sukurtas PS scenarijus, į kurį buvo įdėta daug darbo ir kuris su kaupu veikė bandomojoje aplinkoje, gamybinėje aplinkoje bejėgiškai skundėsi neįmanoma užduotimi: Nurodytas kelias, failo pavadinimas arba abu yra per ilgi. Visiškai apibrėžtas failo pavadinimas turi būti trumpesnis nei 260 simbolių, o katalogo pavadinimas turi būti trumpesnis nei 248 simboliai.
Pasirodo, 260 simbolių pakanka „ne tik visiems“. Jei norite peržengti leistinas ribas, kreipkitės į katę.

Štai tik keletas nemalonių pasekmių ribojant failo kelio ilgį:

Šiek tiek nukrypstant nuo temos, pastebiu, kad DFS replikacijos atveju straipsnyje aptarta problema nėra baisi ir failai ilgais pavadinimais sėkmingai keliauja iš serverio į serverį (jei, žinoma, visa kita yra padaryta teisingai).

Taip pat norėčiau atkreipti jūsų dėmesį į labai naudingą priemonę, kuri man padėjo ne kartą robokopija. Ji taip pat nebijo ilgų kelių, be to, gali daug ką. Todėl, jei užduotis apsiriboja failo duomenų kopijavimu / perkėlimu, galite sustoti. Jei jums reikia gudrauti su failų sistemos prieigos kontrolės sąrašais (DACL), žiūrėkite į šalį subinacl. Nepaisant didelio amžiaus, jis puikiai veikė „Windows 2012 R2“. Čia Atsižvelgiama į taikymo būdus.

Man buvo įdomu išmokyti dirbti su ilgais „PowerShell“ keliais. Su juo tai beveik kaip barzdotame pokšte apie Ivaną Carevičių ir Vasilisą Gražiąją.

Greitas būdas

Perjunkite į „Linux“ ir nesijaudinkite dėl „Windows 10/2016/2019“ ir įjunkite atitinkamą grupės strategijos nustatymą / pakoreguokite registrą. Detaliau apie šį metodą nekalbėsiu, nes... Internete jau yra daug straipsnių šia tema, pvz. tai.

Atsižvelgiant į tai, kad dauguma įmonių turi daug, švelniai tariant, ne naujausias operacinių sistemų versijas, šis metodas greitas tik rašant popieriuje, nebent, žinoma, esate vienas iš tų laimingųjų, kurie turi nedaug senų sistemų ir Windows 10. /2016/2019 karaliauja .

Ilgas kelias

Iš karto padarykime išlygą, kad pakeitimai neturės įtakos „Windows Explorer“ veikimui, tačiau leis naudoti ilgus „PowerShell“ cmdlet kelius, tokius kaip „Get-Item“, „Get-ChildItem“, „Remove-Item“ ir kt.

Pirmiausia atnaujinkime „PowerShell“. Tai daroma vieną, du, tris kartus.

  1. Atnaujiname .NET Framework į ne žemesnę nei 4.5 versiją. Operacinė sistema turi būti bent Windows 7 SP1/2008 R2. Galite atsisiųsti dabartinę versiją čia, skaitykite daugiau informacijos čia.
  2. Atsisiųsti ir įdiegti Windows Management Framework 5.1
  3. Perkrauname mašiną.

Darbštūs žmonės aukščiau aprašytus veiksmus gali atlikti rankiniu būdu, tingūs – naudodami SCCM, politiką, scenarijus ir kitus automatizavimo įrankius.

Dabartinę „PowerShell“ versiją galite rasti iš kintamojo $PSVersionTable. Po atnaujinimo jis turėtų atrodyti maždaug taip:

Windows, PowerShell ir Long Paths

Dabar, kai naudojate cmdlet Get-ChildItem ir panašiai vietoj įprastų Kelias mes naudosime literalPath.

Kelio formatas šiek tiek skirsis:

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

Patogumui konvertuoti kelius iš įprasto formato į formatą literalPath galite naudoti šią funkciją:

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

Atkreipkite dėmesį, kad nustatydami parametrą literalPath Jūs negalite naudoti pakaitos simbolių (*, ? ir tt).

Be parametro literalPath, atnaujintoje PowerShell cmdlet versijoje Get-ChildItem gavo parametrą Gylis, su kuria galima nustatyti lizdo gylį rekursinei paieškai, naudojau porą kartų ir likau patenkinta.

Dabar jūs neturite jaudintis, kad jūsų PS scenarijus suklys ilgu dygliuotu keliu ir negalės matyti tolimų failų. Pavyzdžiui, šis metodas man labai padėjo rašant scenarijų, skirtą iš naujo nustatyti „laikiną“ failų atributą DFSR aplankuose. Bet tai jau kita istorija, kurią pabandysiu papasakoti kitame straipsnyje. Laukiu įdomių jūsų komentarų ir siūlau dalyvauti apklausoje.

Naudingos nuorodos:
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

Apklausoje gali dalyvauti tik registruoti vartotojai. Prisijungti, Prašau.

Ar jums aktuali ilgų kelių problema?

  • Taip

  • Buvo aktualu, bet jau nuspręsta

  • Tai trukdo, bet nelabai

  • Apie tai negalvojau, atrodo, kad viskas veikia

  • Ne

  • Kita (nurodykite komentaruose)

Balsavo 155 vartotojų. 25 vartotojai susilaikė.

Šaltinis: www.habr.com

Добавить комментарий