Hvis du arbejder langsomt med Windows, især med mapper og filer, der har lange navne, løber du i en underlig fejl : Windows vil rapportere, at mappestien eller filnavnet er for lang til at flytte til en ny destination eller endda slette. Hvad er handlen?

Hej, hvordan-til-geek!

Så om dagen reorganiserede jeg nogle filer på min computer, skabte 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

Hr. Uorganiseret

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 dvæler 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 dog langt fra midten af ​​1990'erne, og hele filen Long Fileename er (for det meste) stærkt stryket 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 vil have brug for.

Hvor det hele falder fra hinanden, er en kunstig begrænsning Windows stacks 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, fx 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 sti (enten fordi mappenavnene var lange, var filnavne 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, var den samlede længde af stien Navnet overskred den 260 tegngrænse, der blev pålagt af MAX_PATH-variablen.

Nu tænker du måske "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 titel af artiklen + artiklen fører, ville det være meget nemt at ramme eller overskride MAX_PATH med en enkelt gem. At redigere 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. 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 udnytte API'en og bruge kommandolinjeværktøjer på dine uhåndterlige mapper / filnavne, skal du blot tilføje mappenavnet med en få 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-long-folder-name-scheme

Nøglen er tilføjelse af\? delen før starten af ​​filsti Dette 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). Som altid skal du være forsigtig med kommandoprompten for at undgå at slette filer eller mapper, som du har til hensigt at forlade intakt.

Hvis vores oversigt over dette problem har været nysgerrig, skal du helt sikkert grave dig ind i denne artikel fra Microsoft Developer Network-biblioteket, navngiv filer, Stier og Navnepladser for mere information om, hvad der sker under emhætten.

Har du et presserende teknisk spørgsmål? Skyd os en mail på , og vi gør vores bedste for at svare på det.

Fungerer Firefox-hukommelsesrensere?

Det er ingen hemmelighed, at Firefox kan forbruge en hel del systemhukommelse under normal brug. Mens antallet af faner du har åbent, og de installerede add-ons sikkert bidrager, kan selv en konservativt brugt ud af boksinstallationen rapportere en hel del hukommelsesforbrug. Dette har forårsaget et par Firefox-tilføjelser til at overflade som påstand om at frigøre hukommelse, som browseren ikke længere har brug for, men fungerer de faktisk?

(how-to)

Sådan stopper du et afsnit fra spaltning mellem sider i Microsoft Word

Når du skriver i Word, flyder afsnit glat fra en side til den næste, og sideskift indsættes automatisk, når det er nødvendigt. Men hvad hvis du vil holde et bestemt afsnit sammen og ikke opdele afsnitene mellem to sider? Der er en simpel løsning til dette. Hvorfor ikke blot indsætte en manuel sideskift før stykket?

(how-to)