Ik denk dat je net als ik wel eens paden hebt gezien zoals !!! Belangrijk____Nieuw____!!! Niet verwijderen!!! Bevel №98819-649-B van 30 februari 1985 over de benoeming van Ivan Alexandrovich Kozlov als tijdelijk waarnemend hoofd van de afdeling voor de ondersteuning van zakelijke VIP-klanten en de organisatie van zakelijke bijeenkomsten in de wandelgangen.doc.
En vaak kun je zo'n document in Windows niet meteen openen. Sommigen gebruiken een workaround door schijven te mappen, anderen gebruiken bestandsbeheerders die met lange paden kunnen omgaan: Far Manager, Total Commander en soortgelijke. En veel mensen hebben met verdriet gekeken hoe hun PS-script, waarvan ze veel moeite hadden gestoken en dat in de testomgeving prima werkte, in de productieomgeving hulpeloos klaagde over een onmogelijke taak: Het opgegeven pad, bestandsnaam of beide zijn te lang. De volledig gekwalificeerde bestandsnaam moet korter zijn dan 260 tekens en de directorynaam moet korter zijn dan 248 tekens.
Het blijkt dat 260 tekens niet voor "iedereen" voldoende zijn. Als je geïnteresseerd bent om de grenzen te overschrijden, lees dan verder.
Hier zijn slechts enkele van de treurige gevolgen van de beperking van de bestandspadlengte:
- op de server is er een map, bijvoorbeeld D:DataSharedAccounting, die via SMB is gedeeld en voor gebruikers als netwerkstation S wordt gemonteerd; gebruikers creëren bestanden die beheerders/scripts bij lokaal toegang vanaf de server niet kunnen lezen, omdat het absolute pad langer blijkt te zijn dan het netwerkpad;
- ;
- ;
- bij het migreren van gegevens uit andere systemen waar de padlengte minder strikt is, zullen sommige ervan in de nieuwe omgeving onbeschikbaar zijn zonder gedoe;
- ;
- enzovoort...
Ik ga even van het onderwerp af, maar ik merk op dat voor DFS Replication het probleem dat in het artikel wordt besproken, niet eng is en bestanden met lange namen succesvol van server naar server reizen (tenzij je natuurlijk verder alles ).
Ik wil ook graag wijzen op een zeer handige utility die me meermaals heeft geholpen . Het is ook niet bang voor lange paden en het kan veel. Daarom, als de taak bestaat uit het kopiëren/verplaatsen van bestandsgegevens, kan je hierop focussen. Als je met de toegangscontrolelijsten in het bestandssysteem (DACL) wilt aan de slag gaan, kijk dan naar . Ondanks zijn behoorlijke leeftijd, deed hij het uitstekend op Windows 2012 R2. de toepassingen zijn besproken.
Ik was vooral benieuwd hoe ik met lange paden in PowerShell kon werken. Het is bijna zoals in de oude grap over Ivan de Tsarevich en Vasilisa de Mooie.
Snelle manier
Schakel over naar Linux en maak je geen zorgen over Windows 10/2016/2019 en schakel de juiste groepsbeleid-instelling in/trim het register. Ik zal hier niet gedetailleerd op ingaan, want er zijn al veel artikelen op internet over dit onderwerp, bijvoorbeeld, .
Gelet op het feit dat veel bedrijven, zachtjes gezegd, verouderde versies van besturingssystemen gebruiken, is deze methode snel alleen op papier, tenzij je één van die gelukkigen bent die weinig legacy-systemen hebben en waar Windows 10/2016/2019 heerst.
Langzame manier
Hier moeten we meteen vooropstellen dat de wijzigingen het gedrag van de Windows Verkenner niet zullen beïnvloeden, maar de mogelijkheid bieden om lange paden te gebruiken in PowerShell cmdlets zoals Get-Item, Get-ChildItem, Remove-Item en anderen.
Laten we beginnen met het bijwerken van PowerShell. Dat gaat heel snel.
- Werk het .NET Framework bij naar versie 4.5 of hoger. Het besturingssysteem moet minimaal Windows 7 SP1/2008 R2 zijn. De actuele versie kan worden gedownload , lees aanvullende informatie .
- en installeer Windows Management Framework 5.1
- Herstart de machine.
Vijandige werknemers kunnen de bovenstaande stappen handmatig uitvoeren, terwijl luiere werknemers gebruikmaken van SCCM, beleidsregels, scripts en andere automatiseringshulpmiddelen.
De huidige versie van PowerShell kan worden achterhaald uit de variabele $PSVersionTable. Na de update zou het ongeveer zo moeten zijn:
Nu, bij het gebruik van cmdlets Get-ChildItem en soortgelijke in plaats van de gebruikelijke Pad zullen we gebruiken LiteralPath.
Het padformaat zal hierbij iets anders zijn:
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Voor het gemak van het converteren van paden van het gebruikelijke formaat naar het formaat LiteralPath kun je deze functie gebruiken:
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 op dat je bij het opgeven van de parameter LiteralPath geen wildcard-tekens kunt gebruiken (*, ? enzovoort).
Naast de parameter LiteralPath, heeft de bijgewerkte versie van PowerShell de cmdlet Get-ChildItem de parameter Depth, waardoor je de diepte van de nesteling voor een recursive zoekopdracht kunt instellen. Ik heb het een paar keer gebruikt en ben er tevreden over.
Nu hoeft u zich geen zorgen te maken dat uw PS-script van het lange en moeilijke pad afgaat en de verre bestanden niet kan zien. Dit heeft me namelijk enorm geholpen bij het schrijven van een script om het attribuut 'tijdelijk' van bestanden in DFSR-mappen te verwijderen. Maar dat is weer een ander verhaal, waarover ik in een ander artikel zal proberen te vertellen. Ik kijk uit naar uw interessante opmerkingen en nodig u uit om de enquête in te vullen.
Nuttige links:
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. , alstublieft.
Is het probleem van lange paden relevant voor u?
Yes
Het was relevant, maar ik heb het al opgelost
Het hindert, maar niet veel
Ik heb er niet over nagedacht, alles lijkt te werken
No
Anders (geef details in de opmerkingen)
155 gebruikers hebben gestemd. 25 gebruikers hebben zich onthouden.
Bron: habr.com
