Jag tror att du, precis som jag, har sett sökvägar av typen !!! Viktigt____Nytt____!!! Ta inte bort!!! Order №98819-649-B från 30 februari 1985 om utnämning av Ivan Alexandrovich Kozlov som tillförordnad chef för avdelningen för hantering av företags VIP-kunder och organisering av affärsmöten i kularna.doc.
Och ofta går det inte att öppna ett sådant dokument i Windows direkt. Någon praktiserar workaround i form av disk-mappning, någon använder filhanterare som kan hantera långa sökvägar: Far Manager, Total Commander och liknande. Många har också beklagat sig över hur deras PS-script, som har lagts ner mycket arbete på och som fungerade bra i testmiljön, oförmöget klagat över en övermäktig uppgift i produktionsmiljön: Den angivna sökvägen, filnamnet eller båda är för långa. Det fullständiga filnamnet måste vara mindre än 260 tecken, och mappnamnet måste vara mindre än 248 tecken.
Som det visade sig räcker 260 tecken 'inte bara för alla'. Om du är intresserad av att gå över gränserna - vänligen läs mer.
Här är några av de sorgliga följderna av begränsningen av filvägens längd:
- det finns en mapp på servern, exempelvis D:DataSharedAccounting, som är delad via SMB och monterad som en nätverksdisk S; användare skapar filer som inte kan läsas av administratörer/scripting vid lokal åtkomst från servern, eftersom den absoluta sökvägen blir längre än nätverksvägen;
- ;
- ;
- vid migrering av data från andra system, där det finns mindre strikta begränsningar för sökvägens längd, blir en del av dem otillgängliga i den nya miljön utan extra arbete;
- ;
- osv…
Lite avvikande från ämnet vill jag nämna att för DFS Replication är problemet som diskuteras i artikeln inte så skrämmande, och filer med långa namn reser framgångsrikt från server till server (förutsatt att du har gjort allt annat rätt) ).
Jag vill också påpeka ett mycket användbart verktyg som jag har fått hjälp av flera gånger . Det är inte heller rädd för långa sökvägar och kan mycket. Så om uppgiften handlar om att kopiera/flytta fildata, kan du stanna vid det. Om det behöver magiska trick med åtkomstkontrollister i filsystemet (DACL), titta på . Trots sin solida ålder presterade den utmärkt på Windows 2012 R2. tillämpningsmetoder har diskuterats.
Jag var intresserad av att lära mig använda långa sökvägar med PowerShell. Det känns nästan som i det gamla skämtet om Ivan Tsarevitj och Vasilisa den Underbara.
Snabb metod
Gå över till Linux och slipp Windows 10/2016/2019 och aktivera motsvarande gruppolicy/justera registret. Jag kommer inte att gå in på detta tillvägagångssätt i detalj, eftersom det redan finns många artiklar om det på nätet, till exempel, .
Mot bakgrund av att många företag använder, milda sagt, inte så färska versioner av operativsystem, är denna metod snabb endast på papper, om du inte är en av de lyckliga med få legacy-system och har Windows 10/2016/2019.
Lång metod
Vi klargör här att förändringarna inte påverkar beteendet hos Windows Utforskaren, utan ger möjlighet att använda långa sökvägar i PowerShell-kommandon som Get-Item, Get-ChildItem, Remove-Item och andra.
Låt oss börja med att uppdatera PowerShell. Det görs på ett, två, tre.
- Uppdatera .NET Framework till version 4.5 eller högre. Operativsystemet ska vara minst Windows 7 SP1/2008 R2. Den aktuella versionen kan laddas ner , läs mer information .
- och installera Windows Management Framework 5.1
- Starta om maskinen.
De flitiga kan utföra stegen ovan manuellt, de lata - med hjälp av SCCM, policyer, skript och andra automatiseringsmedel.
Den aktuella versionen av PowerShell kan kontrolleras med variabeln $PSVersionTable. Efter uppdatering ska det se ut ungefär så här:

Nu, när du använder kommandon Get-ChildItem och liknande, istället för den vanliga Path ska vi använda LiteralPath.
Formatet för sökvägar kommer att vara något annorlunda:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
För att enkelt konvertera vägar från det vanliga formatet till formatet LiteralPath kan du använda följande 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"}
}
Observera att vid angivande av parametern LiteralPath kan inga jokertecken användas (*, ? etc.).
Förutom parametern LiteralPath, har ett kommando i den uppdaterade versionen av PowerShell fått parametern Get-ChildItem Depth , som gör att du kan ställa in sökdjupet för rekursiv sökning. Jag har använt den ett par gånger och var nöjd., с помощью которого можно задавать глубину вложенности для рекурсивного поиска, я пару раз его использовал и остался доволен.
Nu kan du sluta oroa dig för att ditt PS-script tappar bort sig på den långa snåriga vägen och missar avlägsna filer. Jag har till exempel haft stor nytta av denna metod när jag skrev ett script för att ta bort attributet "tillfällig" från filer i DFSR-mappar. Men det är en annan historia, som jag ska försöka berätta om i en annan artikel. Jag ser fram emot intressanta kommentarer från er och föreslår att ni deltar i en undersökning.
Nyttiga länkar:
Endast registrerade användare kan delta i omröstningen. , tack.
Är problemet med långa vägar aktuellt för dig?
Ja
Det var aktuellt, men jag har redan löst det
Det stör, men inte så mycket
Jag har inte tänkt på det, allt verkar fungera
Ingen
Annat (ange i kommentarerna)
155 användare har röstat. 25 användare avstod.
Källa: habr.com
