Ek dink jy, soos ek, het al meer as een keer sulke paaie gesien !!! Belangrik____nuut____!!! Moenie uitvee nie!!! Bestelling nr. 98819-649-B gedateer 30 Februarie 1985 oor die aanstelling van Ivan Aleksandrovich Kozlov as tydelike waarnemende hoof van die departement vir die ondersteuning van korporatiewe BBP-kliënte en die organisering van sakevergaderings op die kantlyn.doc.
En dikwels sal jy nie dadelik so 'n dokument in Windows kan oopmaak nie. Sommige mense oefen oplossings in die vorm van skyfkartering, ander gebruik lêerbestuurders wat met lang paaie kan werk: Far Manager, Total Commander en dies meer. En baie meer het met hartseer gekyk hoe die PS-draaiboek wat hulle geskep het, waarin baie werk belê is en wat met 'n knal in die toetsomgewing gewerk het, in 'n produksie-omgewing hulpeloos gekla het oor 'n onmoontlike taak: Die gespesifiseerde pad, lêernaam of albei is te lank. Die volledig gekwalifiseerde lêernaam moet minder as 260 karakters wees, en die gidsnaam moet minder as 248 karakters wees.
Soos dit blyk, is 260 karakters genoeg "nie net vir almal nie." As jy belangstel om oor die grense te gaan van wat toegelaat word, verwys asseblief na die kat.
Hier is net 'n paar van die ongelukkige gevolge van die beperking van lêerpadlengte:
- daar is 'n vouer op die bediener, byvoorbeeld D:DataSharedAccounting, wat via SMB gedeel word en aan gebruikers gemonteer word as 'n netwerkaandrywer S; gebruikers skep lêers wat admins/skrifte nie kan lees wanneer dit plaaslik vanaf die bediener verkry word nie, want die absolute pad is langer as die netwerkpad;
- ;
- ;
- wanneer data van ander stelsels migreer wat minder streng beperkings op padlengte het, sal sommige van hulle in die nuwe omgewing ontoeganklik word sonder om met 'n tamboeryn te dans;
- ;
- ens ...
As ek effens van die onderwerp afwyk, merk ek op dat vir DFS-replikasie die probleem wat in die artikel bespreek word nie vreeslik is nie en dat lêers met lang name suksesvol van bediener na bediener beweeg (as, natuurlik, alles anders is ).
Ek wil ook u aandag vestig op 'n baie nuttige hulpmiddel wat my al meer as een keer gehelp het . Sy is ook nie bang vir lang paaie nie, en sy kan baie doen. Daarom, as die taak daarop neerkom om lêerdata te kopieer/oor te dra, kan jy daar stop. As jy truuks met lêerstelseltoegangsbeheerlyste (DACL's) moet speel, kyk weg . Ten spyte van sy gevorderde ouderdom het dit uitstekend gevaar op Windows 2012 R2. metodes van toediening oorweeg word.
Ek was geïnteresseerd om te leer hoe om met lang PowerShell-paaie te werk. By hom is dit amper soos in 'n bebaarde grap oor Ivan Tsarevich en Vasilisa die Mooie.
Vinnige manier
Skakel oor na Linux en moenie bekommerd wees oor Windows 10/2016/2019 nie en aktiveer die toepaslike groepbeleidinstelling/tweak die register. Ek sal nie in detail oor hierdie metode stilstaan nie, want ... Daar is reeds baie artikels oor hierdie onderwerp op die internet, bv. .
As in ag geneem word dat die meeste maatskappye baie, om dit sagkens te stel, nie die nuutste weergawes van bedryfstelsels het nie, is hierdie metode net vinnig om op papier te skryf, tensy jy natuurlik een van daardie gelukkiges is wat min erfenisstelsels het en Windows 10 /2016/2019 heers .
Die lang pad
Kom ons maak dadelik 'n bespreking hier dat die veranderinge nie die gedrag van Windows Explorer sal beïnvloed nie, maar dit moontlik sal maak om lang paaie in PowerShell-cmdlets te gebruik, soos Get-Item, Get-ChildItem, Remove-Item, ens.
Kom ons werk eers PowerShell op. Dit word een, twee, drie keer gedoen.
- Ons werk die .NET Framework op na weergawe nie laer as 4.5 nie. Die bedryfstelsel moet ten minste Windows 7 SP1/2008 R2 wees. Jy kan die huidige weergawe aflaai , lees meer inligting .
- en installeer Windows Management Framework 5.1
- Ons herlaai die masjien.
Hardwerkende mense kan die stappe wat hierbo beskryf word met die hand doen, lui mense kan dit doen met behulp van SCCM, beleide, skrifte en ander outomatiseringsinstrumente.
Die huidige weergawe van PowerShell kan gevind word vanaf die veranderlike $PSVersionTable. Na die opdatering behoort dit so iets te lyk:
Nou wanneer jy cmdlets gebruik Kry-kind-item en dies meer in plaas van die gewone Path ons sal gebruik letterlike Pad.
Die padformaat sal effens anders wees:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Vir die gerief om paaie van die gewone formaat na die formaat om te skakel letterlike Pad jy kan hierdie funksie gebruik:
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"}
}
Let asseblief daarop dat wanneer u die parameter stel letterlike Pad Jy kan nie jokertekens gebruik nie (*, ? en so aan).
Benewens die parameter letterlike Pad, in die opgedateerde weergawe van PowerShell cmdlet Kry-kind-item het die parameter gekry Diepte, waarmee jy die nesdiepte vir rekursiewe soektog kan stel, het ek dit 'n paar keer gebruik en was tevrede.
Nou hoef jy nie bekommerd te wees dat jou PS-skrif langs die lang doringpad sal afdwaal en nie veraf lêers sal kan sien nie. Hierdie benadering het my byvoorbeeld baie gehelp met die skryf van 'n skrip om die "tydelike" kenmerk van lêers in DFSR-vouers terug te stel. Maar dit is 'n ander storie, wat ek in 'n ander artikel sal probeer vertel. Ek sien uit na interessante kommentaar van jou en stel voor dat jy die opname neem.
Nuttige skakels:
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Is die probleem van lang paaie vir jou relevant?
-
Ja
-
Was relevant, maar reeds besluit
-
Dit meng in, maar nie veel nie
-
Ek het nie daaraan gedink nie, dit lyk of alles werk
-
Geen
-
Ander (spesifiseer asseblief in kommentaar)
155 gebruikers het gestem. 25 gebruikers het buite stemming gebly.
Bron: will.com