22Aug
Hvis du arbejder længe nok med Windows, især med mapper og filer, der har lange navne, kommer du til en bizar fejl: Windows vil rapportere, at mappebanen eller filnavnet er for lang til at flytte til en ny destination eller endda slette. Hvad er der galt?
Hey How-To Geek!
Så den anden dag reorganiserede jeg nogle filer på min computer, oprettede mapper, de slags ting. Derefter, da jeg flyttede nogle filer til en mappe, får jeg en besked, der siger, at den resulterende mappebane ville være for lang. Jeg var forvirret. Jeg ved, at hvert enkelt operativsystem siden DOS understøtter lange filnavne, men Windows hævder, at stien er for lang? Hvorfor sker dette?
Med venlig hilsen
Mr. Disorganized
Det problem, du løber ind, er et uheldigt skæringspunkt mellem to systemer, der i tilfælde som dette giver en fejl. For at forstå præcis, hvor fejlen kommer fra, skal vi grave ind i historien om lange filnavne( LFN) og hvordan Windows interagerer med dem, før vi dykker ind i løsninger.
Lange filnavne blev introduceret gennem den underliggende MS-DOS-arkitektur i Windows 95. Det nye LFN-system tillod fil- og katalognavne på op til 255 tegn. Dette var en vellykket udvidelse af det tidligere filnavnssystem, der normalt kaldes 8,3 filnavnet, fordi navnet var begrænset til otte tegn og en trecifret udvidelse, men også kendt som Short Filename( SFN).Som du kan forestille dig, var der stadig mange DOS-baserede apps rundt, og der var mere end et par hovedpine, der forsøgte at få de nyere LFN'er og de arvede SFN'er til at lege godt sammen. Hvis du nogensinde har stødt på en ældre diskette eller cd-rom med mærkeligt afkortede filer på den( som abcdef ~ 1.txt), blev filnavnet nedskåret af nogle SFN-bruger gamle programmer fra længere og ikke-understøttet LFN( som abcdefghijk.txt).
Vi er imidlertid langt fra midten af 1990'erne, og hele filen Long Fileename er( for det meste) stramt ud. Hvis du kører en version af Windows fra de sidste 10 år, har du sandsynligvis aldrig engang på tværs af et filnavn længde konflikt som vi plejede at løbe ind i DOS / Windows 95 dage. Når det er sagt, løber vi stadig ind i hikke, som du opdagede med dit diskoprydningsprojekt. Men hvorfor? Hvis Windows 'Long Filename-system understøtter mapper og filnavne på op til 255 tegn pr. Komponent, hvilken mur løber du ind? Vi kan ikke bebrejde NTFS( filsystemet, som langt de fleste moderne Windows-maskiner bruger) som NTFS, vil understøtte en sammenkædning af mapper og filnavne op til en samlet sti længde på 32.767 tegn. Det langt overstiger den typiske mappestruktur, som de fleste brugere nogensinde ville have brug for.
Hvor det hele falder fra hinanden, er en kunstig begrænsning Windows-stak oven på LFN / NTFS-systemet: MAX_PATH-variablen. MAX_PATH-variablen angiver, at en komplet mappestruktur i Windows ikke kan overstige 260 samlede tegn, inklusive drevbogstav, kolon, backslash og null backlash i slutningen. Således har du kun en potentiel reel MAX_PATH på 256 tegn, f.eks. C: \ din-256-tegn-sti \ .
Så hvad skete der, da du rydde op på din computer, er at du havde en mappe med en allerede lang vej( enten fordi mappenavnene var lange, filnavne var lange eller begge dele), og da du forsøgte at flytte en eller flereaf disse mapper til en anden mappe med en lang sti, oversteg den samlede længde af stinavnen den 260 tegngrense, der blev pålagt af MAX_PATH-variablen.
Nu kan du tænke "Ah-hah! Vi ændrer bare MAX_PATH-variablen og løser problemet! "Desværre er det ikke så nemt. Ikke kun er MAX_PATH-variablen stort set hårdt kodet til Windows, men selvom du gik igennem det enorme besvær med at ændre det, ville du ende med at bryde så meget, det ville ikke være det værd. For mange applikationer forventer, at stien variabel er, hvad Windows har længe angivet det til at være. Vi kan ikke bare gå rundt om at ændre det uden at skabe et enormt rod.
Hvor forlader det dig? Nå, den enkleste løsning er at bare redigere stinavdataene. Hvis du f.eks. Har et ton af gemte artikler, hvor applikationen / udvidelsen du brugte til at gemme dem fra internettet, oprettede en mappe, der var den fulde titel af artiklen + artikellederne, og så er filnavnet selv den fulde titelaf artiklen + artiklen fører, ville det være meget nemt at ramme eller overskride MAX_PATH med en enkelt gem. Redigering af disse enorme mapper og artikeltitler ned til en mere fornuftig størrelse er en nem måde at løse problemet på.
Hvis du har et stort antal filer med en lang sti, og du ikke vil redigere dem alle( eller hvis du vil slet et ton af gamle biblioteker, der er for lange til Windows at håndtere, når de er begrænset afMAX_PATH-variabel), der er en kommandolinjearbejde. Selv om Windows er begrænset af MAX_PATH-variablen, erkendte Windows-ingeniører, at der ville være situationer, hvor brugerne skulle håndtere længere stinavn. Som sådan har Windows API en funktion til at håndtere ekstremt lange stier.
For at kunne udnytte denne API og bruge kommandolinjeværktøjer på dine uhåndterlige mapper / filnavne, skal du blot tilføje bibliotekets navn med et par ekstra tegn. Hvis du f.eks. Havde en stor mappestruktur, som du ønskede at slette( men modtog en fejl på grund af sti længden, da du forsøgte det), kan du ændre kommandoen fra:
rmdir c: \ documents \ some-really-super-long-folder-name-scheme \
til:
rmdir \\? \ c: \ documents \ nogle-virkelig super-lang-mappe-navn-scheme \
Nøglen er tilføjelsen af \\? \ portionfør starten af filstiDette pålægger Windows at se bort fra begrænsningerne i MAX_PATH-variablen og at interagere med den vej, du lige har leveret som leveret / forstået direkte af det underliggende filsystem( som klart kan understøtte en længere sti).Vær altid opmærksom på kommandoprompten for altid at undgå, at du sletter filer eller mapper, du har til hensigt at forlade.
Hvis vores oversigt over dette problem har du nysgerrig, skal du helt sikkert grave dig ind i denne artikel fra Microsoft Developer Network-biblioteket, navngive filer, stier og navnepladser for at få flere oplysninger om, hvad der sker under emhætten.
Har du et presserende teknisk spørgsmål? Skyd os en mail på [email protected], og vi vil gøre vores bedste for at besvare det.