Als je lang genoeg met Windows werkt, vooral met mappen en bestanden met lange namen, kom je een bizarre fout tegen: Windows zal melden dat het mappad of de bestandsnaam te lang is om naar een nieuwe bestemming te gaan of zelfs te verwijderen. Wat is er aan de hand?
Hey How-To Geek!
Dus onlangs was ik een aantal bestanden op mijn computer aan het reorganiseren, mappen aan het maken, dat soort dingen. Toen ik vervolgens enkele bestanden naar een map aan het verplaatsen was, krijg ik een bericht dat het resulterende mappad te lang zou zijn. Ik was in de war. Ik weet dat elk besturingssysteem sinds DOS lange bestandsnamen ondersteunt, maar Windows beweert dat het pad te lang is? Waarom gebeurt dit?
Met hartelijke groet,
Mr. ongeorganiseerd
Het probleem dat u tegenkomt is een ongelukkige kruising van twee systemen die in dit soort gevallen een fout oplevert. Om precies te begrijpen waar de fout vandaan komt, moeten we ingaan op de geschiedenis van lange bestandsnamen (LFN) en hoe Windows ermee omgaat voordat we ons verdiepen in oplossingen.
Lange bestandsnamen werden geïntroduceerd, via de onderliggende MS-DOS-architectuur, in Windows 95. Het nieuwe LFN-systeem stond bestands- en directorynamen toe van maximaal 255 tekens. Dit was een welkome uitbreiding van het vorige bestandsnaamsysteem, meestal 8.3 bestandsnaam genoemd omdat de naam beperkt was tot acht tekens en een extensie van drie cijfers, maar ook bekend als Short Filename (SFN). Zoals je je kunt voorstellen, waren er toen nog veel op DOS gebaseerde apps en waren er meer dan een paar hoofdpijn om de nieuwere LFN’s en de oudere SFN’s leuk met elkaar te laten spelen. Als je ooit een oudere diskette of cd-rom bent tegengekomen met vreemd afgekapte bestanden erop (zoals abcdef ~ 1.txt), dan werd die bestandsnaam gekapt door een SFN-gebruikende legacy-applicatie van een langere en niet-ondersteunde LFN (zoals abcdefghijk. tekst).
We zijn echter ver verwijderd van het midden van de jaren negentig en het hele ding over de lange bestandsnaam is (voor het grootste deel) stevig gladgestreken. Als je een versie van Windows van de afgelopen 10 jaar gebruikt, ben je waarschijnlijk nog nooit een conflict met bestandsnaamlengte tegengekomen zoals we dat vroeger tegenkwamen in de DOS / Windows 95-dagen. Dat gezegd hebbende, we lopen nog steeds tegen hikken aan, zoals je ontdekte met je schijfopruimingsproject. Maar waarom? Als het lange bestandsnaamsysteem van Windows mappen en bestandsnamen van maximaal 255 tekens per component ondersteunt, tegen welke muur loopt u dan? We kunnen NTFS (het bestandssysteem dat de overgrote meerderheid van moderne Windows-machines gebruiken) niet de schuld geven, aangezien NTFS een aaneenschakeling van mappen en bestandsnamen ondersteunt tot een totale padlengte van 32.767 tekens. Dat is veel groter dan de typische directorystructuur die de meeste gebruikers ooit nodig zouden hebben.
Waar het allemaal uit elkaar valt, is een kunstmatige beperking die Windows bovenop het LFN / NTFS-systeem stapelt: de MAX_PATH-variabele. De variabele MAX_PATH geeft aan dat een volledige directorystructuur in Windows in totaal niet meer dan 260 tekens mag bevatten, inclusief de stationsletter, dubbele punt, backslash en null-backlash aan het einde. Je hebt dus alleen een potentiële echte MAX_PATH van 256 tekens, bijv C: uw-256-karakter-pad .
Dus wat er gebeurde toen u uw computer aan het opschonen was, is dat u een directory had met een al lang pad (ofwel omdat de mapnamen lang waren, de bestandsnamen lang, of beide), en toen u probeerde een of meer van die mappen in een andere map met een lang pad, overschreed de totale lengte van de padnaam de limiet van 260 tekens die is opgelegd door de variabele MAX_PATH.
Nu denk je misschien: “Ah-hah! We veranderen gewoon de variabele MAX_PATH en lossen het probleem op! ” Helaas is het niet zo eenvoudig. De MAX_PATH-variabele is niet alleen in wezen hard gecodeerd in Windows, maar zelfs als je het enorme gedoe zou hebben gehad om het te wijzigen, zou je uiteindelijk zo veel breken dat het het niet waard zou zijn. Te veel toepassingen verwachten dat de padvariabele is wat Windows lang heeft gespecificeerd. We kunnen het niet zomaar veranderen zonder een enorme puinhoop te creëren.
Waar laat je je achter? Welnu, de eenvoudigste oplossing is om gewoon de padgegevens te bewerken. Als u bijvoorbeeld een heleboel artikelen hebt opgeslagen waarvan de toepassing / extensie die u gebruikte om ze van het web op te slaan, een map heeft gemaakt die de volledige titel van het artikel + de artikelleider was, en dan is de bestandsnaam zelf de volledige titel van het artikel + de artikelvoorsprong, zou het heel eenvoudig zijn om de MAX_PATH te bereiken of te overschrijden met een enkele opslag. Het bewerken van die enorme map- en artikeltitels tot een redelijker formaat is een gemakkelijke manier om het probleem op te lossen.
Als je een groot aantal bestanden hebt met een lang pad en je wilt ze niet allemaal bewerken (of als je dat wilt verwijderen een heleboel oude mappen die te lang zijn voor Windows om ermee om te gaan als ze worden beperkt door de MAX_PATH-variabele), er is een opdrachtregel omheen. Hoewel Windows wordt beperkt door de variabele MAX_PATH, realiseerden Windows-ingenieurs zich dat er situaties zouden zijn waarin gebruikers te maken zouden moeten hebben met langere padnamen. Als zodanig heeft de Windows API een functie voor het omgaan met extreem lange paden.
Om van die API te profiteren en opdrachtregelhulpprogramma’s te gebruiken voor uw logge mappen / bestandsnamen, hoeft u alleen maar een paar extra tekens aan de mapnaam toe te voegen. Als u bijvoorbeeld een enorme directorystructuur had die u wilde verwijderen (maar een foutmelding kreeg vanwege de padlengte toen u dit probeerde), kunt u de opdracht wijzigen van:
rmdir c:documentssome-really-super-long-folder-name-scheme
naar:
rmdir \?c:documentssome-really-super-long-folder-name-scheme
De sleutel is de toevoeging van de \? gedeelte voor het begin van het bestandspad; dit instrueert Windows om de beperkingen opgelegd door de MAX_PATH-variabele te negeren en om te interageren met het pad dat u zojuist hebt opgegeven zoals geleverd / begrepen rechtstreeks door het onderliggende bestandssysteem (dat duidelijk een langer pad kan ondersteunen). Wees zoals altijd voorzichtig bij de opdrachtprompt om te voorkomen dat u per ongeluk bestanden of mappen verwijdert die u intact wilde laten.
Als ons overzicht van dit probleem je nieuwsgierig maakt, ga dan zeker naar dit artikel uit de Microsoft Developer Network-bibliotheek, Naming Files, Paths en Namespaces, voor meer informatie over wat er onder de motorkap gebeurt.
Heeft u een prangende technische vraag? Stuur ons een e-mail op ask@howtogeek.com en we zullen ons best doen om deze te beantwoorden.
