Hey How-To Geek!
So the other day, I was reorganizing some files on my computer, creating folders, that kind of stuff. Then, when I was moving some files into a folder, I get a message, stating that the resulting folder path would be too long. I was confused. I know that every single OS since DOS supports Long Filenames, yet Windows claims that the path is too long? Why does this happen?
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 apper rundt, og det var mer enn noen få hodepine som prøvde å 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 imidlertid langt fra midten av 1990-tallet, og hele filen for lange filnavn er (for det meste) stramt 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 dager. 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 bane 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, backslash og null backlash 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 mappene 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 som er pålagt av MAX_PATH-variabelen.
Nå kan du tenke "Ah-hah! Vi endrer bare MAX_PATH-variabelen og løser problemet! "Alas, det er ikke så enkelt. Ikke bare er MAX_PATH-variabelen i hovedsak hardkodd til Windows, men selv om du gikk gjennom det enorme besværet 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 fulle tittelen til 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 disse 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 vilslette 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 utnytte denne API-en og bruke kommandolinjeverktøy på de ubøyelige 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:documentssome-really-super-long-folder-name-scheme
til:
rmdir \?c:documentssome-really-super-long-folder-name-scheme
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 du nysgjerrig, må du definitivt grave inn i denne artikkelen fra Microsoft Developer Network-biblioteket, 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.
