Jeg tror, at du, ligesom jeg, har set stier som !!! Vigtigt____Nyt____!!! Må ikke slettes!!! Påbud nr. 98819-649-B fra 30. februar 1985 om udnævnelse af Ivan Alexandrovich Kozlov som midlertidig leder af afdelingen for støtte af virksomhedens VIP-kunder og organisering af forretningsmøder i kulisserne.doc.
Og ofte kan man ikke straks åbne sådan et dokument i Windows. Nogle bruger workaround ved at mappe drev, andre bruger filhåndterere, der kan arbejde med lange stier: Far Manager, Total Commander og lignende. Mange har også trist set, hvordan deres PS-script, som der var lagt meget arbejde i, og som fungerede perfekt i testmiljøet, i produktionsmiljøet hjælpeløst klagede over en uoverkommelig opgave: Den angivne sti, filnavn eller begge dele er for lange. Det fuldt kvalificerede filnavn skal være mindre end 260 tegn, og mappenavnet skal være mindre end 248 tegn.
Det viste sig, at 260 tegn ikke er nok for «alle». Hvis du er interesseret i at overskride grænserne - værsgo under cut.
Her er nogle af de triste konsekvenser af begrænsningen af filstien:
- på serveren er der en mappe, for eksempel D:DataSharedAccounting, som er delt via SMB og monteres af brugere som det netværksdrev S; brugere opretter filer, som administratorer/scripts ikke kan læse ved lokal adgang fra serveren, da den absolutte sti bliver længere end den netværksmæssige;
- ;
- ;
- ved migration af data fra andre systemer, som har mindre strenge begrænsninger på længden af stien, bliver dele af dem utilgængelige i det nye miljø uden en del besvær;
- ;
- osv...
Lidt uden for emnet, vil jeg bemærke, at for DFS Replication er det problem, der omtales i artiklen, ikke så skræmmende, og filer med lange navne rejser sig succesfuldt fra server til server (hvis selvfølgelig, at du har gjort alt andet ).
Jeg vil også gerne fremhæve et meget nyttigt værktøj, som ofte har reddet mig. . Den er heller ikke bange for lange stier, og hun kan meget. Så hvis opgaven går ud på at kopiere/flytte fildata, kan man holde sig til hende. Hvis det handler om at eksperimentere med adgangskontrolister i filsystemet (DACL), skal man se mod . På trods af sin respektable alder har den klaret sig godt på Windows 2012 R2. er anvendelsesmetoder blevet overvejet.
Jeg var dog interesseret i at lære at arbejde med lange stier i PowerShell. Det er næsten som i den oldgamle vittighed om Ivan Tsarevich og Vasillisa den Skønne.
Hurtig metode
Skift til Linux og bekymr dig ikke om Windows 10/2016/2019, og aktivér den relevante gruppepolitikl eller tweak registreringsdatabasen. Jeg vil ikke gå i dybden med denne metode, da der allerede er mange artikler om emnet på nettet, for eksempel .
I betragtning af at mange virksomheder har, for at sige det mildt, mange ikke-nyere versioner af operativsystemer, er denne metode hurtig kun på papiret, medmindre du selvfølgelig er blandt de heldige, der har få legacy-systemer og kører Windows 10/2016/2019.
Langsom metode
Her skal vi straks gøre det klart, at ændringerne ikke vil påvirke Windows Stifinder, men give mulighed for at bruge lange stier i PowerShell-cmdlets som Get-Item, Get-ChildItem, Remove-Item osv.
Først opdaterer vi PowerShell. Det gøres på et-to-tre.
- Vi opdaterer .NET Framework til version 4.5 eller højere. Operativsystemet skal være mindst Windows 7 SP1/2008 R2. Den aktuelle version kan downloades , læs yderligere information .
- og installere Windows Management Framework 5.1
- Genstart maskinen.
Flittige personer kan udføre de ovenfor beskrevne trin manuelt, mens dovne får hjælp fra SCCM, politikker, scripts og andre automatiseringsværktøjer.
Den aktuelle version af PowerShell kan findes i variablen $PSVersionTable. Efter opdateringen skal det se nogenlunde sådan her ud:
Nu, når du bruger cmdlets Get-ChildItem og lignende, i stedet for den sædvanlige Sti vil vi bruge LiteralPath.
Formatet af stierne vil være lidt anderledes:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
For nem konvertering af stier fra det sædvanlige format til formatet LiteralPath kan du bruge denne funktion:
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"}
}
Bemærk, at når du angiver parameteren LiteralPath man kan ikke bruge wildcard-tegn (*, ? etc.).
Udover parameteren LiteralPath, i den opdaterede version af PowerShell har cmdlet Get-ChildItem modtaget parameteren Depth, som gør det muligt at angive dybden af neste niveau for rekursiv søgning. Jeg har brugt det et par gange og været tilfreds.
Nu behøver man ikke længere at frygte, at dit PS-script mister den lange og snoede vej og ikke kan finde fjerne filer. For eksempel har denne tilgang hjulpet mig meget, da jeg skrev et script til at nulstille attributten "temporær" for filer i DFSR-mapper. Men det er en anden historie, som jeg vil forsøge at fortælle i en anden artikel. Jeg ser frem til interessante kommentarer fra dig og foreslår, at du deltager i en afstemning.
Nyttige links:
Kun registrerede brugere kan deltage i undersøgelsen. , please.
Er problemet med lange stier relevant for dig?
Ja
Det var relevant, men jeg har allerede løst det
Generer, men ikke meget
Har ikke tænkt på det, ser ud til at alt fungerer
Nej
Andet (angiv i kommentarerne)
155 brugere har stemt. 25 brugere har undladt at stemme.
Kilde: habr.com
