MĂ« duket se ju, ashtu si edhe unĂ«, keni parĂ« disa herĂ« rrugĂ« tĂ« tilla !!! E rĂ«ndĂ«sishme____E re____!!! Mos e fshini!!! Urdhri â98819-649-Đ nga 30 Shkurt 1985 pĂ«r emĂ«rimin e Kozlov Ivan Aleksandrovich si pĂ«rkohĂ«sisht drejtor pĂ«r mbĂ«shtetje tĂ« klientĂ«ve VIP dhe organizimin e takimeve tĂ« biznesit nĂ« kulisa.doc.
Dhe shpesh, nuk do të arrini ta hapni një dokument të tillë menjëherë në Windows. Disa praktikojnë një zgjidhje përmes hartimit të disqeve, disa përdorin menaxherë skedari që dinë të punojnë me rrugë të gjatë: Far Manager, Total Commander dhe të ngjashme. Dhe shumë e kanë parë me trishtim se skripti PS që ata krijuan, në të cilin kishin investuar shumë punë dhe që punonte shkëlqyeshëm në ambientin testues, në mjedisin real ankohej pa fund për një detyrë të pamundshme: Rruga e specifikuar, emri i skedarit, ose të dyja janë shumë të gjata. Emri i plotë i skedarit duhet të jetë më pak se 260 karaktere, dhe emri i dosjes duhet të jetë më pak se 248 karaktere.
Siç është zbuluar, 260 karaktere nuk janë "të mjaftueshme për të gjithë". Nëse jeni të interesuar të kaloni kufijtë e lejuar - ju lutem kaloni më poshtë.
Këtu janë disa nga pasojat e trishtueshme të kufizimit të gjatë të rrugëve të skedarëve:
- në server ka një dosje, për shembull, D:DataSharedAccounting, e cila është e ndarë përmes SMB dhe fshihet për përdoruesit si një disk rrjetik S; përdoruesit krijojnë skedarë që administratorët/dokumentet nuk do të jenë në gjendje t'i lexojnë me akses lokal nga serveri, pasi rruga absolute bëhet më e gjatë se ajo e rrjetit;
- ;
- ;
- kur migrohen të dhënat nga sisteme të tjera, që kanë kufizime më të lehta ndaj gjatësi të rrugëve, në ambientin e ri, disa prej tyre do të bëhen të parehurshem pa ndihmën e duarve;
- ;
- etj...
Duke u larguar pak nga tema, do të theksoj se për replikimin DFS problemi i diskutuar në këtë artikull nuk është shqetësues dhe skedarët me emra të gjatë udhëtojnë me sukses nga serveri në server (nëse natyrisht, ju keni bërë gjithçka siç duhet) ).
Do doja të theksoja një utilitet shumë të dobishëm, i cili më ka ndihmuar shpesh . Edhe për të, rrugët e gjata nuk janë problem, dhe ai bën shumë gjëra të tjera. Prandaj, nëse detyra është të kopjoni/transportoni të dhënat e skedarëve, mund të qëndroni me të. Nëse duhet të shkoni më thellë me listat e kontrollit të aksesit në sistemin e skedarëve (DACL), shikoni drejt . Megjithëse është mjaft i vjetër, ka treguar performancë të shkëlqyer në Windows 2012 R2. janë shqyrtuar metodat e përdorimit.
Ishim të interesuar të mësonim të punonim me rrugë të gjata në PowerShell. Me të, është pak si në anekdotën e vjetër për Ivan-Czar dhe Vasilisa të Bukur.
Një mënyrë e shpejtë
Kaloni në Linux dhe mos u shqetësoni për Windows 10/2016/2019 dhe aktivizoni parametrin përkatës të politikës së grupit/ndryshoni regjistrin. Nuk do të ndalem gjatë në këtë metodë, pasi në internet ka shumë artikuj mbi këtë temë, për shembull, .
Duke pasur parasysh se në shumicën e kompanive ka shumë versione të sistemi operativ, për të thënë të vërtetën, këto metodat janë të shpejta vetëm në letër, përveç nëse nuk jeni nga ata fatlum që keni pak sisteme legado dhe Windows 10/2016/2019 mbizotërojnë.
Një metodë e gjatë
Këtu menjëherë sqarojmë se ndryshimet nuk do të ndikojnë në sjelljen e eksploruesit të Windows, por do të mundësojnë përdorimin e rrugëve të gjata në komandlet PowerShell, si Get-Item, Get-ChildItem, Remove-Item etj.
Fillimisht, të përditësojmë PowerShell. Kjo bëhet shpejt.
- Të përditësojmë .NET Framework në versionin 4.5 ose më të lartë. Sistemi operativ duhet të jetë të paktën Windows 7 SP1/2008 R2. Mund të shkarkoni versionin aktual , dhe lexoni informacionin shtesë .
- dhe instaloni Windows Management Framework 5.1
- Ribashkoni makinën.
Ata që janë të përkushtuar mund të bëjnë hapat e përmendur më sipër manualisht, ata të lenë - me SCCM, politika, skripte dhe mjetet tjera të automatizimit.
Versions aktuale të PowerShell mund të dihet nga variabla $PSVersionTable. Pas përditësimit duhet të duket si më poshtë:

Tani, gjatë përdorimit të komandlet Get-ChildItem dhe të ngjashme në vend të zakonshmes Path do të përdorim LiteralPath.
Formati i rrugëve do të jetë pak ndryshe:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Për lehtësi, për transformimin e rrugëve nga formati i zakonshëm në formatin LiteralPath mund të përdorni këtë funksion:
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"}
}
Kujdes, që kur jepni parametrin LiteralPath nuk mund të përdoren karaktere zëvendësimi (*, ? etj.).
Përveç parametrin LiteralPath, në versionin e përditësuar të PowerShell komandlet Get-ChildItem ka marrë parametrin Depth, me anë të të cilit mund të përcaktoni thellësinë e shpërndarjes për kërkimin rekurziv, unë e kam përdorur disa herë dhe kam qenë shumë i kënaqur.
Tani tani mund të mos frikësoheni se skripti juaj PS do të humbasë rrugën e gjatë të tij dhe nuk do të shohë skedarët e largët. Për shembull, kjo qasje më ndihmoi shumë kur shkrova një skript për të hequr atributin "temporary" nga skedarët në dosjet DFSR. Por kjo është një histori tjetër, të cilën do përpiqem ta ndaj në një artikull tjetër. Pres komentet tuaja interesante dhe ju ftoj të merrni pjesë në anketë.
Linke të dobishme:
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutemi.
A është problemi i rrugëve të gjata relevant për ju?
Po
Ishin të rëndësishme, por tani e kam zgjidhur
Pengon, por jo shumë
Nuk kam menduar për të, duket se gjithçka funksionon
Jo
Diçka tjetër (shkruani në komentet)
155 përdorues votuan. 25 përdorues abstenuan.
Burimi: habr.com
