Hvorfor rapporterer Windows denne mappen er for lang til å kopiere?

Hvis du jobber med Windows lenge nok, spesielt med mapper og filer med lange navn, kommer du til en bizar feil: Windows vil rapportere at mappebanen eller filnavnet er for lang til å flytte til et nytt mål eller til og med slette. Hva er greia?

Hei, hvordan-til-geek!

Så i dag reorganiserte jeg noen filer på datamaskinen min, lagde mapper, den slags ting. Da, da jeg flyttet noen filer til en mappe, mottok jeg en melding som sier at den resulterende mappebanen vil være for lang. Jeg var forvirret. Jeg vet at hvert eneste operativsystem siden DOS støtter lange filnavn, men Windows hevder at banen er for lang? Hvorfor skjer dette?

sincerly,

Mr. Disorganized

Problemet du løper inn er et uheldig skjæringspunkt mellom to systemer som i slike tilfeller gir en feil. For å forstå nøyaktig hvor feilen kommer fra, må vi grave inn i historien om lange filnavn (LFN) og hvordan Windows samhandler med dem før vi dykker inn i løsninger.

Lange filnavn ble introdusert gjennom den underliggende MS-DOS-arkitekturen i Windows 95. Det nye LFN-systemet tillot fil- og katalognavn på opptil 255 tegn. Dette var en velkommen utvidelse av det forrige filnavnet, vanligvis kalt 8.3 filnavn fordi navnet var begrenset til åtte tegn og en tresifret forlengelse, men også kjent som Short Filename (SFN). Som du kan forestille deg, da var det fortsatt mange DOS-baserte programmer rundt, og det var mer enn noen få hodepine som forsøkte å få de nyere LFN-ene og arven SFNs til å leke fint med hverandre. Hvis du noen gang har kommet over en eldre diskett eller CD-ROM med merkelig avkortede filer på den (som abcdef ~ 1.txt), ble filnavnet kuttet ned av noen SFN-brukende eldre applikasjoner fra noen lengre og ikke-støttet LFN (som abcdefghijk. tekst).

Vi er langt fra midten av 1990-tallet, og hele filen for lange filnavn er (for det meste) godt stryket ut. Hvis du kjører en versjon av Windows fra de siste 10 årene, har du sannsynligvis aldri kommet over en filnavnlengdekonflikt som vi pleide å løpe inn i DOS / Windows 95-dagene. Når det er sagt, løper vi fortsatt inn i hikke, som du oppdaget med diskoppryddingsprosjektet. Men hvorfor? Hvis Windows 'Long Filename-systemet støtter mapper og filnavn på opptil 255 tegn per komponent, hvilken vegg kjører du inn? Vi kan ikke klandre NTFS (filsystemet som det store flertallet av moderne Windows-maskiner bruker) som NTFS, vil støtte en kjetting av mapper og filnavn opp til en total sti-lengde på 32.767 tegn. Det som langt overstiger den typiske katalogstrukturen de fleste brukere noensinne vil trenge.

Hvor alt faller fra hverandre, er en kunstig begrensning av Windows-stabler på toppen av LFN / NTFS-systemet: MAX_PATH-variabelen. MAX_PATH-variabelen angir at en komplett katalogstruktur i Windows ikke kan overstige 260 totale tegn, inkludert stasjonsbokstaven, kolon, tilbakestrek og null tilbakeslag på slutten. Dermed har du bare en potensiell reell MAX_PATH på 256 tegn, f.eks. C: \ ditt-256-tegns-bane \.

Så det som skjedde da du rydde opp datamaskinen var at du hadde en katalog med en allerede lang bane (enten fordi mappenavnene var lange, filnavnene var lange eller begge deler), og da du forsøkte å flytte en eller flere av disse katalogene i en annen katalog med en lang bane, overskred den totale lengden på banenavnet 260 tegngrensen pålagt av MAX_PATH-variabelen.

Nå kan du tenke "Ah-hah! Vi endrer bare MAX_PATH-variabelen og løser problemet! "Å, det er ikke så enkelt. Ikke bare er MAX_PATH-variabelen i hovedsak hardkodet til Windows, men selv om du gikk gjennom det enorme problemet med å endre det, ville du ende opp med å bryte så mye det ikke ville være verdt det. For mange applikasjoner forventer at stivariabelen skal være hva Windows har angitt lenge for å være. Vi kan ikke bare gå rundt og endre det uten å skape et enormt rot.

Hvor forlater det deg? Vel, den enkleste løsningen er å bare redigere sti dataene. Hvis du for eksempel har massevis av lagrede artikler der programmet / utvidelsen du pleide å lagre dem fra nettet, opprettet en katalog som var den fulde tittelen på artikkelen + artikkelen, og så er filnavnet selv den fulle tittelen av artikkelen + artikkelen fører, ville det være veldig enkelt å treffe eller overstige MAX_PATH med en enkelt lagring. Å redigere de enorme mappene og artikkeltitlene ned til en mer fornuftig størrelse er en enkel måte å løse problemet på.

Hvis du har et stort antall filer med en lang bane, og du ikke vil redigere dem alle (eller hvis du vil slette massevis av gamle kataloger som er for lange for Windows å håndtere når det er begrenset av MAX_PATH-variabelen), er det en kommandolinje rundt. Selv om Windows er begrenset av MAX_PATH-variabelen, oppdaget Windows ingeniører at det ville være situasjoner der brukerne måtte håndtere lengre stinavn. Som sådan har Windows API en funksjon for å håndtere ekstremt lange stier.

For å kunne dra nytte av den API-en og bruke kommandolinjeverktøy på de uhåndterlige mappene / filnavnene, må du bare legge til katalognavnet med noen ekstra tegn. Hvis du for eksempel hadde en stor katalogstruktur som du ønsket å slette (men mottok en feil på grunn av banelengden når du prøvde det), kan du endre kommandoen fra:

rmdir c: \ documents \ noen-virkelig-super-lang-mappe-navn-ordningen \

til:

rmdir \\? \ c: \ documents \ noen-virkelig-super-lang-mappe-navn-ordningen \

Nøkkelen er tillegg av \\? \ del før starten av filbanen; Dette instruerer Windows om å se bort fra begrensningene som er pålagt MAX_PATH-variabelen, og å samhandle med banen du nettopp har levert som forstått direkte av det underliggende filsystemet (som tydeligvis kan støtte en lengre bane). Som alltid, vær forsiktig på kommandoprompten for å unngå ved et uhell å slette filer eller kataloger du har tenkt å forlate intakt.

Hvis vår oversikt over dette problemet har vært nysgjerrig, må du definitivt grave deg inn i denne artikkelen fra biblioteket Microsoft Developer Network, navngi filer, baner og navneområder for mer informasjon om hva som skjer under hetten.

Har du et presset teknisk spørsmål? Skyt oss en e-post på [email protected], og vi vil gjøre vårt beste for å svare på det.