Varför rapporterar Windows denna mapp är för länge att kopiera?

Om du arbetar tillräckligt länge med Windows, särskilt med mappar och filer som har långa namn, kommer du att bli ett bisarrt fel: Windows kommer att rapportera att mappens sökväg eller filnamn är för lång för att flytta till en ny destination eller till och med radera. Vad är grejen?

Hej hur-till-geek!

Så om dagen omorganiserade jag några filer på min dator, skapade mappar, sånt sådant. Sedan när jag rörde vissa filer i en mapp får jag ett meddelande, där det anges att den resulterande mappvägen skulle vara för lång. Jag var förvirrad. Jag vet att varje enskilt operativsystem sedan DOS stöder Långa Filnamn, men Windows hävdar att banan är för lång? Varför händer detta?

sincerly,

Mr. Disorganized

Det problem du löper på är ett olyckligt skärningspunkt mellan två system som i sådana fall ger ett fel. För att förstå exakt var felet kommer ifrån måste vi gräva in i Long File Name (LFN) och hur Windows interagerar med dem innan vi dyker upp i lösningar.

Långa filnamn introducerades, genom den underliggande MS-DOS-arkitekturen, i Windows 95. Det nya LFN-systemet tillåts för fil- och katalognamn på upp till 255 tecken. Detta var en välkommen expansion av det tidigare filnamnssystemet, vanligtvis kallat 8.3 filnamn eftersom namnet var begränsat till åtta tecken och en tresiffrig förlängning men också känd som kort filnamn (SFN). Som du kan föreställa dig, då var det fortfarande många DOS-baserade appar runt och det fanns mer än några huvudvärk som försökte få de nyare LFN: erna och de äldre SFN: erna att leka bra med varandra. Om du någonsin har stött på en äldre diskett eller CD-ROM med ojämnt avkortade filer på den (som abcdef ~ 1.txt) så filnamn skars av vissa SFN-användande äldre program från något längre och icke-stödjande LFN (som abcdefghijk. Text).

Vi är dock långt från mitten av 1990-talet, och hela filen Long Fileename är (för det mesta) hårt utjämnad. Om du kör en version av Windows från de senaste 10 åren har du förmodligen aldrig kommit över en filnamnslängdskonflikt som vi brukade springa in i DOS / Windows 95-dagarna. Med det sagt fortsätter vi fortfarande med hicka, som du upptäckte med ditt diskrensningsprojekt. Men varför? Om Windows 'Lång filnamnssystem stöder mappar och filnamn på upp till 255 tecken per komponent, vilken vägg kör du in? Vi kan inte skylla på NTFS (filsystemet som de allra flesta moderna Windows-maskiner använder) som NTFS kommer att stödja en kedjning av mappar och filnamn upp till en total banlängd på 32.767 tecken. Så långt överstiger den typiska katalogstrukturen de flesta användare någonsin skulle behöva.

Om allt faller isär, är en artificiell begränsning Windows staplar ovanpå LFN / NTFS-systemet: MAX_PATH-variabeln. MAX_PATH-variabeln anger att en komplett katalogstruktur i Windows inte kan överstiga 260 totala tecken, inklusive drivbrevet, kolon, backslash och null backlash i slutet. Således har du bara en potentiell riktig MAX_PATH med 256 tecken, t.ex.. C: \ ditt-256 tecken-path \.

Så vad hände när du städade din dator är att du hade en katalog med en redan lång väg (antingen för att mappnamnen var långa, filnamnen var långa eller båda) och när du försökte flytta en eller flera av de katalogerna till en annan katalog med en lång sökväg överskred den totala längden på söknamnet den 260 teckengräns som infördes av MAX_PATH-variabeln.

Nu kanske du tänker "Ah-hah! Vi ändrar bara MAX_PATH-variabeln och löser problemet! "Okej, det är inte så enkelt. Inte bara är MAX_PATH-variabeln väsentligen svårkodad till Windows, men även om du gick igenom det enorma krånget med att ändra det, skulle du sluta bryta så mycket det skulle inte vara värt det. För många applikationer förväntar sig att variabeln för vägen är vad Windows länge har angivit att den ska vara. Vi kan inte bara gå runt ändra det utan att skapa en enorm röra.

Var lämnar du dig? Jo, den enklaste lösningen är att bara redigera sökdata. Om du till exempel har massor av sparade artiklar där programmet / tillägget du brukade spara från webben skapade en katalog som var den fullständiga titeln på artikeln + artikeln, och då är filnamnet fullständigt titeln av artikeln + artikeln leder, skulle det vara riktigt enkelt att träffa eller överträffa MAX_PATH med en enda spara. Att redigera dessa enorma mapp- och artikeltitlar ner till en mer rimlig storlek är ett enkelt sätt att lösa problemet.

Om du har ett stort antal filer med en lång väg och du inte vill redigera dem alla (eller om du vill radera ett ton gamla kataloger som är för långa för att Windows ska hantera när det är begränsat av MAX_PATH-variabeln), det finns en kommandorad. Trots att Windows är begränsad av MAX_PATH-variabeln, insåg Windows ingenjörer att det skulle finnas situationer där användarna skulle behöva hantera längre sökvägar. Som sådan har Windows API en funktion för att hantera extremt långa vägar.

För att kunna dra nytta av det API: n och använda kommandoradsverktyg på dina obehagliga mappar / filnamn behöver du bara lägga till katalognamnet med några extra tecken. Om du till exempel hade en stor katalogstruktur som du ville radera (men fick ett fel på grund av banlängden när du försökte det) kan du ändra kommandot från:

rmdir c: \ documents \ some-really-super-long-mapp-namn-schema \

till:

rmdir \\? \ c: \ documents \ some-really-super-long-folder-name-scheme \

Nyckeln är tillägget av \\? \ del före början av filbanan; Detta instruerar Windows att ignorera de begränsningar som anges av MAX_PATH-variabeln och att interagera med den sökväg du just har tillhandahållit som levereras / förstås direkt av det underliggande filsystemet (vilket tydligt kan stödja en längre sökväg). Som alltid, var försiktig vid kommandotolken för att undvika att oavsiktligt radera filer eller kataloger som du tänkt lämna intakt.

Om vår översikt över den här frågan har du nyfiken, gräva dig definitivt i den här artikeln i biblioteket Microsoft Developer Network, Namnge filer, sökvägar och namnområden för mer information om vad som händer under huven.

Har du en pressande teknisk fråga? Skjut oss ett mail på [email protected] och vi gör vårt bästa för att svara på det.