Cred că tu, la fel ca mine, ai văzut astfel de căi de mai multe ori !!! Important____Nou____!!! Nu șterge!!!Ordinul nr. 98819-649-B din 30 februarie 1985 cu privire la numirea lui Ivan Aleksandrovich Kozlov ca șef temporar interimar al departamentului pentru sprijinirea clienților corporativi VIP și organizarea de întâlniri de afaceri pe margine.doc.
Și adesea nu veți putea deschide imediat un astfel de document în Windows. Unii oameni practică soluția sub formă de mapare a discurilor, alții folosesc manageri de fișiere care pot lucra cu căi lungi: Far Manager, Total Commander și altele asemenea. Și mulți alții au urmărit cu tristețe cum scriptul PS creat de ei, în care s-a investit multă muncă și care a funcționat fulgerător în mediul de testare, într-un mediu de producție s-a plâns neputincios de o sarcină imposibilă: Calea specificată, numele fișierului sau ambele sunt prea lungi. Numele de fișier complet calificat trebuie să aibă mai puțin de 260 de caractere, iar numele directorului trebuie să aibă mai puțin de 248 de caractere.
După cum se dovedește, 260 de caractere sunt suficiente „nu doar pentru toată lumea”. Dacă sunteți interesat să depășiți limitele a ceea ce este permis, vă rugăm să consultați pisica.
Iată doar câteva dintre consecințele nefericite ale limitării lungimii căii fișierului:
- există un folder pe server, de exemplu, D:DataSharedAccounting, care este partajat prin SMB și montat utilizatorilor ca o unitate de rețea S; utilizatorii creează fișiere pe care administratorii/scripturile nu le pot citi atunci când sunt accesate local de pe server, deoarece calea absolută este mai lungă decât calea rețelei;
- ;
- ;
- la migrarea datelor din alte sisteme care au restricții mai puțin stricte privind lungimea căii, în noul mediu unele dintre ele vor deveni inaccesibile fără a dansa cu tamburina;
- ;
- etc ...
Depărtând ușor de subiect, observ că pentru replicarea DFS problema discutată în articol nu este teribilă și fișierele cu nume lungi călătoresc cu succes de la server la server (dacă, desigur, totul este ).
De asemenea, aș dori să vă atrag atenția asupra unui utilitar foarte util care m-a ajutat de mai multe ori . De asemenea, nu se teme de căi lungi și poate face multe. Prin urmare, dacă sarcina se rezumă la copierea/transferul datelor fișierului, vă puteți opri aici. Dacă trebuie să jucați trucuri cu listele de control al accesului la sistemul de fișiere (DACL), priviți în altă parte . În ciuda vârstei sale înaintate, a funcționat excelent pe Windows 2012 R2. sunt luate în considerare metodele de aplicare.
Am fost interesat să predau cum să lucrez cu căi PowerShell lungi. Cu el este aproape ca într-o glumă cu barbă despre Ivan Țarevici și Vasilisa cea Frumoasă.
Căi rapide
Treceți la Linux și nu vă faceți griji pentru Windows 10/2016/2019 și activați setarea adecvată a politicii de grup/ajustați registry. Nu mă voi opri în detaliu asupra acestei metode, pentru că... Există deja multe articole pe acest subiect pe Internet, de exemplu, .
Având în vedere că majoritatea companiilor au multe, ca să spunem ușor, nu cele mai recente versiuni de sisteme de operare, această metodă este rapidă doar pentru scris pe hârtie, cu excepția cazului în care, desigur, ești unul dintre acei norocoși care au puține sisteme vechi și Windows 10. /2016/2019 domnește suprem .
Drumul lung
Să facem imediat o rezervare aici că modificările nu vor afecta comportamentul Windows Explorer, dar vor face posibilă utilizarea căilor lungi în cmdleturile PowerShell, cum ar fi Get-Item, Get-ChildItem, Remove-Item etc.
Mai întâi, să actualizăm PowerShell. Se face una, două, trei ori.
- Actualizăm .NET Framework la versiunea nu mai mică de 4.5. Sistemul de operare trebuie să fie cel puțin Windows 7 SP1/2008 R2. Puteți descărca versiunea curentă , citeste mai multe informatii .
- și instalați Windows Management Framework 5.1
- Repornim aparatul.
Oamenii harnici pot face manual pașii descriși mai sus, leneșii o pot face cu ajutorul SCCM, politici, scripturi și alte instrumente de automatizare.
Versiunea curentă de PowerShell poate fi găsită din variabilă $PSVersionTable. După actualizare, ar trebui să arate cam așa:
Acum, când utilizați cmdlet-uri Get-ChildItem și altele asemenea în loc de cele obișnuite Cale noi vom folosi literalPath.
Formatul căii va fi ușor diferit:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Pentru comoditatea conversiei căilor din formatul obișnuit în format literalPath poti folosi aceasta functie:
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"}
}
Vă rugăm să rețineți că atunci când setați parametrul literalPath Nu puteți folosi metacaractere (*, ? și așa mai departe).
Pe lângă parametru literalPath, în versiunea actualizată a cmdlet-ului PowerShell Get-ChildItem a primit parametrul Adâncime, cu care puteți seta adâncimea de imbricare pentru căutarea recursivă, l-am folosit de câteva ori și am fost mulțumit.
Acum nu trebuie să vă faceți griji că scriptul dumneavoastră PS se va rătăci pe calea lungă și spinoasă și nu va putea vedea fișiere îndepărtate. De exemplu, această abordare m-a ajutat foarte mult când scriu un script pentru a reseta atributul „temporar” al fișierelor din folderele DFSR. Dar asta este o altă poveste, pe care voi încerca să o spun într-un alt articol. Aștept cu nerăbdare comentariile dvs. interesante și vă sugerez să participați la sondaj.
Link-uri utile:
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Problema căilor lungi este relevantă pentru tine?
-
Da
-
Era relevant, dar era deja decis
-
Intervine, dar nu prea mult
-
Nu m-am gândit la asta, totul pare să funcționeze
-
Nu
-
Altele (vă rugăm să specificați în comentarii)
Au votat 155 utilizatori. 25 utilizatori s-au abținut.
Sursa: www.habr.com