Hvorfor er Windows Reporting denne mappe for lang tid til at kopiere?

Hvis du arbejder langsomt 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 problemet?

Hey, hvordan-til-geek!

Så i 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?

sincerly,

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, som 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 arvige SFN'er til at lege godt sammen. Hvis du nogensinde har stødt på en ældre diskette eller cd-rom med underlige trunkerede 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 dog langt fra midten af ​​1990'erne, og hele filen Long Fileename er (for det meste) stramt fast. 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 katalogstruktur, 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, herunder drevbogstav, kolon, backslash og null backlash i slutningen. Således har du kun en potentiel reel MAX_PATH på 256 tegn, f.eks. C: \ dit-256-tegn-sti \.

Så hvad skete der, da du rydde op på din computer, er at du havde en mappe med en allerede lang sti (enten fordi mappenavne var lange, filnavne var lange eller begge dele), og da du forsøgte at flytte en eller flere af disse mapper til en anden mappe med en lang sti overskred den samlede længde af stinavnen den 260 tegnbegrænsning, der er 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 stien variabel at være, 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? Den enkleste løsning er bare at redigere stien data. Hvis du f.eks. Har masser 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 titel af 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 slette et ton gamle mapper, der er for lange til, at Windows skal håndtere, når det er begrænset af MAX_PATH-variablen), er der en kommandolinjearbejde. Selvom Windows er begrænset af MAX_PATH-variablen, erkendte Windows-ingeniører, at der ville være situationer, hvor brugere ville 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 enorm 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 \ nogle-virkelig-super-long-folder-name-scheme \

til:

rmdir \\? \ c: \ documents \ nogle-virkelig-super-long-folder-name-scheme \

Nøglen er tilføjelsen af \\? \ del før starten af ​​filstien Dette pålægger Windows at se bort fra begrænsningerne i MAX_PATH-variablen og at interagere med den sti, 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, som 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.