Կարծում եմ, դուք, ինչպես ինձ, մեկ անգամ չէ, որ տեսել եք նման ճանապարհներ !!! Կարևոր ____Նոր____!!! Մի ջնջեք!!!98819թ. փետրվարի 649-ի թիվ 30-1985-Բ հրամանը Իվան Ալեքսանդրովիչ Կոզլովին կորպորատիվ VIP հաճախորդների աջակցության և կուլիսներում գործնական հանդիպումներ կազմակերպելու բաժնի ղեկավարի ժամանակավոր պաշտոնակատար նշանակելու մասին:doc.
Եվ հաճախ Windows-ում նման փաստաթուղթ հնարավոր չէ բացել անմիջապես։ Որոշ մարդիկ կիրառում են լուծումներ սկավառակի քարտեզագրման տեսքով, մյուսներն օգտագործում են ֆայլերի կառավարիչներ, որոնք կարող են աշխատել երկար ուղիների հետ՝ Far Manager, Total Commander և այլն: Եվ շատ մարդիկ տխուր հետևում էին, թե ինչպես են իրենց ստեղծած PS-ի սցենարը, որի վրա մեծ ջանքեր էին գործադրել և որը հիանալի էր աշխատում թեստային միջավայրում, անօգնական դժգոհում էր արտադրական միջավայրում անհնարին առաջադրանքից. Նշված ուղին, ֆայլի անունը կամ երկուսն էլ չափազանց երկար են: Լիովին որակավորված ֆայլի անունը պետք է լինի 260 նիշից պակաս, իսկ գրացուցակի անունը պետք է լինի 248 նիշից պակաս:
Ինչպես պարզվում է, 260 նիշը բավարար է «ոչ միայն բոլորի համար»: Եթե դուք հետաքրքրված եք դուրս գալ թույլատրելիի սահմաններից, խնդրում ենք կարդալ:
Ահա ֆայլի ուղու երկարությունը սահմանափակելու դժբախտ հետևանքներից մի քանիսը.
- սերվերի վրա կա թղթապանակ, օրինակ՝ D:DataSharedAccounting, որը համօգտագործվում է SMB-ի միջոցով և տեղադրվում է օգտվողների կողմից որպես ցանցային սկավառակ S; օգտվողները ստեղծում են ֆայլեր, որոնք ադմինիստրատորները/սկրիպտները չեն կարող կարդալ սերվերից տեղական մուտքի դեպքում, քանի որ բացարձակ ուղին ավելի երկար է, քան ցանցի ուղին.
- ;
- ;
- այլ համակարգերից տվյալների տեղափոխման ժամանակ, որոնք ունեն ուղու երկարության ավելի քիչ խիստ սահմանափակումներ, դրանցից մի քանիսը նոր միջավայրում անհասանելի կդառնան առանց մեծ ջանքերի.
- ;
- եւ այլն ...
Թեմայից մի փոքր շեղված, ես կնշեմ, որ DFS Replication-ի համար հոդվածում քննարկված խնդիրը խնդիր չէ, և երկար անուններով ֆայլերը հաջողությամբ անցնում են սերվերից սերվեր (եթե, իհարկե, մնացած ամեն ինչում ամեն ինչ ճիշտ է) ).
Ես նաև կցանկանայի ուշադրություն հրավիրել մի շատ օգտակար ծրագրի վրա, որն ինձ օգնել է ավելի քան մեկ անգամ . Նա նաև չի վախենում երկար ճանապարհորդություններից և շատ բան կարող է անել։ Հետևաբար, եթե խնդիրը հանգում է ֆայլի տվյալների պատճենմանը/փոխանցմանը, կարող եք այնտեղ կանգ առնել: Եթե Ձեզ անհրաժեշտ է խաղալ ֆայլային համակարգի մուտքի վերահսկման ցուցակներով (DACL), փնտրեք այլ տեղ . Չնայած իր զգալի տարիքին, այն գերազանց կատարեց Windows 2012 R2-ում: Դիտարկվում են կիրառման եղանակները:
Ինձ հետաքրքրում էր սովորել, թե ինչպես աշխատել երկար PowerShell ուղիների հետ: Նրա հետ դա գրեթե նման է հին կատակի Իվան Ցարևիչի և Վասիլիսա Գեղեցիկի մասին:
Արագ ձեւ
Անցեք Linux-ին և մի անհանգստացեք Windows 10/2016/2019-ով և միացրեք համապատասխան խմբի քաղաքականության կարգավորումը/կսմթեք ռեեստրը: Այս մեթոդին մանրամասն չեմ անդրադառնա, քանի որ... Համացանցում արդեն կան բազմաթիվ հոդվածներ այս թեմայով, օրինակ. .
Հաշվի առնելով, որ ընկերությունների մեծամասնությունը օպերացիոն համակարգերի, մեղմ ասած, շատ հնացած տարբերակներ ունի, այս մեթոդը արագ է միայն թղթի վրա գրելու համար, եթե, իհարկե, դուք այն հաջողակներից չեք, ովքեր քիչ ժառանգական համակարգեր ունեն, և Windows 10/2016/2019-ը գերիշխում է:
Երկար ճանապարհը
Անմիջապես պարզենք, որ փոփոխությունները չեն ազդի Windows Explorer-ի վարքագծի վրա, այլ հնարավորություն կտան օգտագործել երկար ուղիներ PowerShell cmdlet-ներում, ինչպիսիք են Get-Item, Get-ChildItem, Remove-Item և այլն:
Նախ, եկեք թարմացնենք PowerShell-ը: Կատարվում է մեկ-երկու-երեք:
- Թարմացրեք .NET Framework-ը 4.5-ից ոչ ցածր տարբերակին: Օպերացիոն համակարգը պետք է լինի առնվազն Windows 7 SP1/2008 R2: Ընթացիկ տարբերակը կարելի է ներբեռնել , կարդացեք լրացուցիչ տեղեկություններ .
- և տեղադրել Windows Management Framework 5.1-ը
- Վերագործարկեք մեքենան:
Աշխատասեր մարդիկ կարող են ձեռքով անել վերը նշված քայլերը, ծույլերը կարող են դա անել SCCM-ի, քաղաքականության, սցենարների և ցանկացած այլ ավտոմատացման գործիքների միջոցով:
PowerShell-ի ընթացիկ տարբերակը կարելի է գտնել փոփոխականից $PSVersionTable. Թարմացումից հետո այն պետք է նման լինի հետևյալին.

Հիմա cmdlet-ներ օգտագործելիս Get-ChildItem և ուրիշները նրա նման սովորականի փոխարեն Ճանապարհ մենք կօգտագործենք LiteralPath.
Ուղու ձևաչափը մի փոքր այլ կլինի.
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Ճանապարհները սովորական ձևաչափից ձևաչափի փոխակերպելու հեշտության համար LiteralPath Դուք կարող եք օգտագործել այս գործառույթը.
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"}
}
Խնդրում ենք նկատի ունենալ, որ պարամետրը սահմանելիս LiteralPath Դուք չեք կարող օգտագործել wildcards (*, ? եւ այլն):
Բացի պարամետրից LiteralPath, PowerShell cmdlet-ի թարմացված տարբերակում Get-ChildItem ստացել է պարամետր Խորություն, որով դուք կարող եք սահմանել բույնի խորությունը ռեկուրսիվ որոնման համար, ես մի երկու անգամ օգտագործեցի և գոհ էի։
Այժմ դուք չպետք է անհանգստանաք, որ ձեր PS սկրիպտը կշեղվի իր երկար ու փշոտ ճանապարհից և չի տեսնի հեռավոր ֆայլերը: Օրինակ, այս մոտեցումն ինձ իսկապես օգնեց DFSR պանակներում ֆայլերի «ժամանակավոր» հատկանիշը վերականգնելու սցենար գրելիս: Բայց դա այլ պատմություն է, որը ես կփորձեմ պատմել մեկ այլ հոդվածում: Ակնկալում եմ ձեզանից հետաքրքիր մեկնաբանություններ և առաջարկում եմ մասնակցել հարցմանը։
Օգտակար հղումներ
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Արդյո՞ք երկար ճանապարհների խնդիրը ձեզ համար տեղին է։
Այո
Դա տեղին էր, բայց ես արդեն որոշել եմ
Դա խանգարում է, բայց ոչ շատ:
Ես չեմ մտածել այդ մասին, ամեն ինչ կարծես թե ստացվում է
Ոչ
Այլ (նշեք մեկնաբանություններում)
Քվեարկել է 155 օգտատեր։ 25 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com
