Windows, PowerShell och Long Paths

Windows, PowerShell och Long Paths

Jag tror att du, precis som jag, har sett sådana här stigar mer än en gång !!! Viktigt____Ny____!!! Ta inte bort!!! Beställningsnummer 98819-649-B daterad 30 februari 1985 om utnämningen av Ivan Aleksandrovich Kozlov till tillfällig tillförordnad chef för avdelningen för att stödja företags VIP-kunder och organisera affärsmöten vid sidan av.doc.

Och ofta kommer du inte att kunna öppna ett sådant dokument i Windows direkt. Vissa övar på en lösning i form av diskmappning, andra använder filhanterare som kan fungera med långa vägar: Far Manager, Total Commander och liknande. Och många fler såg med sorg när PS-manuset de skapade, som mycket arbete lades på och som fungerade med råge i testmiljön, i en produktionsmiljö hjälplöst klagade över en omöjlig uppgift: 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 katalognamnet måste vara mindre än 248 tecken.
Som det visar sig räcker 260 tecken "inte bara för alla." Om du är intresserad av att gå utanför gränserna för vad som är tillåtet, hänvisa gärna till katten.

Här är bara några av de olyckliga konsekvenserna av att begränsa filsökvägslängden:

Avviker något från ämnet, noterar jag att för DFS-replikering är problemet som diskuteras i artikeln inte hemskt och filer med långa namn reser framgångsrikt från server till server (om, naturligtvis, allt annat är gjort rätt).

Jag skulle också vilja uppmärksamma er på ett mycket användbart verktyg som har hjälpt mig mer än en gång Robocopy. Hon är inte heller rädd för långa vägar, och hon kan mycket. Därför, om uppgiften handlar om att kopiera/överföra fildata, kan du sluta där. Om du behöver trixa med filsystemåtkomstkontrollistor (DACL), titta bort subinakl. Trots sin höga ålder presterade den utmärkt på Windows 2012 R2. Här tillämpningsmetoder övervägs.

Jag var intresserad av att lära ut hur man arbetar med långa PowerShell-vägar. Med honom är det nästan som i ett skäggigt skämt om Ivan Tsarevich och Vasilisa den vackra.

Snabbt sätt

Byt till Linux och oroa dig inte för Windows 10/2016/2019 och aktivera lämplig grupppolicyinställning/justera registret. Jag kommer inte att uppehålla mig i detalj vid denna metod, eftersom... Det finns redan många artiklar om detta ämne på Internet, t.ex. detta.

Med tanke på att de flesta företag har många, milt sagt, inte de senaste versionerna av operativsystem, är den här metoden snabb endast för att skriva på papper, såvida du naturligtvis inte är en av de lyckliga som har få äldre system och Windows 10 /2016/2019 regerar högst .

Den långa vägen

Låt oss omedelbart göra en reservation här att ändringarna inte kommer att påverka beteendet hos Windows Explorer, utan kommer att göra det möjligt att använda långa sökvägar i PowerShell-cmdlets, som Get-Item, Get-ChildItem, Remove-Item, etc.

Låt oss först uppdatera PowerShell. Det har gjorts en, två, tre gånger.

  1. Vi uppdaterar .NET Framework till version som inte är lägre än 4.5. Operativsystemet måste vara minst Windows 7 SP1/2008 R2. Du kan ladda ner den aktuella versionen här, läs mer information här.
  2. Laddar ner och installera Windows Management Framework 5.1
  3. Vi startar om maskinen.

Hårt arbetande människor kan göra stegen som beskrivs ovan manuellt, lata människor kan göra det med hjälp av SCCM, policyer, skript och andra automatiseringsverktyg.

Den aktuella versionen av PowerShell kan hittas från variabeln $PSVersionTable. Efter uppdateringen borde det se ut ungefär så här:

Windows, PowerShell och Long Paths

Nu när du använder cmdlets Get-ChildItem och liknande istället för det vanliga Bana vi kommer använda bokstavligPath.

Banformatet kommer att vara något annorlunda:

Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"

För bekvämligheten med att konvertera sökvägar från det vanliga formatet till formatet bokstavligPath du kan använda denna 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 när du ställer in parametern bokstavligPath Du kan inte använda jokertecken (*, ? och så vidare).

Förutom parametern bokstavligPath, i den uppdaterade versionen av PowerShell cmdlet Get-ChildItem fick parametern Djup, med vilken du kan ställa in häckningsdjupet för rekursiv sökning, jag använde den ett par gånger och var nöjd.

Nu behöver du inte oroa dig för att ditt PS-skript kommer att hamna på avvägar längs den långa taggiga vägen och inte kommer att kunna se filer på avstånd. Till exempel, detta tillvägagångssätt hjälpte mig mycket när jag skrev ett skript för att återställa det "tillfälliga" attributet för filer i DFSR-mappar. Men det är en annan historia, som jag ska försöka berätta i en annan artikel. Jag ser fram emot intressanta kommentarer från dig och föreslår att du deltar i undersökningen.

Användbara länkar:
docs.microsoft.com/ru-ru/dotnet/api/microsoft.powershell.commands.contentcommandbase.literalpath?view=powershellsdk-1.1.0
docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-5.1
stackoverflow.com/questions/46308030/handling-path-too-long-exception-with-new-psdrive/46309524
luisabreu.wordpress.com/2013/02/15/theliteralpath-parameter

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Är problemet med långa vägar relevant för dig?

  • Ja

  • Var relevant, men redan bestämt

  • Det stör, men inte mycket

  • Jag tänkte inte på det, allt verkar fungera

  • Ingen

  • Annat (ange det i kommentarerna)

155 användare röstade. 25 användare avstod från att rösta.

Källa: will.com

Lägg en kommentar