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

Om du arbetar tillräckligt länge med Windows, speciellt med mappar och filer med långa namn, kommer du att bli ett bisarrt fel: Windows kommer att rapportera att mappvägen eller filnamnet är för långt för att flytta till en ny destination eller till och med ta bort. 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 och anger att den resulterande mappbanan skulle vara för lång. Jag var förvirrad. Jag vet att varje operativsystem sedan DOS stöder Långa Filnamn, men Windows hävdar att banan är för lång? Varför händer detta?

Med vänlig hälsning,

Herr Disorganized

Problemet 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 även känd som kort filnamn( SFN).Som du kan tänka 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 och de äldre SFN: erna att leka bra med varandra. Om du någonsin 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 långt från mitten av 1990-talet, men 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 'Long Filename-system 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: \ din-256-tecken-sökvägen \ .

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 fleraav dessa kataloger 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 för 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 är det som Windows länge har angett att det 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 titelnav 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 sökväg och du inte vill redigera dem alla( eller om du vill radera ett ton gammal kataloger som är för långa för Windows att hantera när de begränsas avMAX_PATH-variabeln), det finns ett kommandoradsarbete. 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 utnyttja 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-mapp-namn-schema \

Nyckeln är tillägget av \\? \ delenföre början av filbanan;Detta instruerar Windows att ignorera begränsningarna som införs 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 bana).Som alltid, var försiktig vid kommandotolken för att undvika att oavsiktligt radera filer eller kataloger som du tänkte 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 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.