Kodėl „Windows Reporting This Folder“ yra per ilgas kopijuoti?
Jei dirbate su „Windows“ pakankamai ilgai, ypač su aplankais ir failais, turinčiais ilgus vardus, susidursite su keista klaida: „Windows“ praneš, kad aplanko kelias arba failo pavadinimas yra per ilgas, kad galėtumėte pereiti prie naujos paskirties vietos arba netgi ištrinti. Koks susitarimas?
Hey How-To Geek!
Taigi kitą dieną aš reorganizavau kai kuriuos failus kompiuteryje, kuriu aplankus, tokius dalykus. Tada, kai perkėliau kai kuriuos failus į aplanką, gaunu pranešimą, kuriame nurodoma, kad gautas aplanko kelias būtų per ilgas. Aš buvau sutrikęs. Žinau, kad kiekviena OS, nes DOS palaiko ilgus failų vardus, tačiau „Windows“ teigia, kad kelias yra per ilgas? Kodėl taip atsitinka?
Nuoširdžiai,
Ponas Neorganizuotas
Problema, su kuria susidūrėte, yra gaila dviejų sistemų sankirtos, kurios tokiais atvejais sukelia klaidą. Norint tiksliai suprasti, iš kur atsiranda klaida, turime įterpti į ilgų failų vardų (LFN) istoriją ir kaip „Windows“ su jais bendrauja, kol mes įsijungsime į sprendimus.
Ilgas failų vardai buvo įvesti per pagrindinę MS-DOS architektūrą „Windows 95“. Nauja LFN sistema leidžiama failų ir katalogų pavadinimams iki 255 simbolių. Tai buvo sveikintinas ankstesnės failų vardų sistemos išplėtimas, paprastai vadinamas 8.3 failų rinkmena, nes pavadinimas buvo apribotas iki aštuonių ženklų ir trijų skaitmenų plėtinys, bet taip pat žinomas kaip trumpas failo vardas (SFN). Kaip galite įsivaizduoti, ten dar buvo daug „DOS“ programų ir buvo daugiau nei keletas galvos skausmų, kurie bandė gauti naujesnius LFN ir senus SFN, kad jie būtų gražūs vienas su kitu. Jei kada nors susidūrėte su senesniu diskeliu ar CD-ROM su keistai sutrumpintais failais (pvz., Abcdef ~ 1.txt), kai kurie ilgesni ir nepalaikomi LFN (pvz., Abcdefghijk. txt).
Tačiau nuo 1990-ųjų vidurio mes ilgai nuvažiavome, o visas „Long Fileename“ dalykas yra (iš esmės) tvirtai išlygintas. Jei naudojate „Windows“ versiją nuo pastarųjų 10 metų, jūs tikriausiai niekada net nesutiksite su failo pavadinimo ilgio konfliktu, panašiu į tai, kaip mes naudojome 95 dienų „DOS“ / „Windows“ sistemoje. Be to, mes vis dar susidūrėme su žagsėjimais, kaip aptikote su disko valymo projektu. Bet kodėl? Jei „Windows“ ilgo failo pavadinimo sistema palaiko iki 255 simbolių aplankus ir failų pavadinimus kiekvienam komponentui, kokios sienos esate? Negalime kaltinti NTFS (failų sistemos, kurią naudoja dauguma šiuolaikinių „Windows“ mašinų), nes NTFS palaikys aplankų ir failų pavadinimų grandinę iki viso 32,767 simbolių kelio ilgio. Tai gerokai viršija tipišką katalogo struktūrą, kurią dauguma vartotojų turėtų.
Jei viskas suskaidoma, tai dirbtinis apribojimas, kurį „Windows“ sukrauna į „LFN / NTFS“ sistemą: MAX_PATH kintamasis. „MAX_PATH“ kintamasis nurodo, kad visa „Windows“ katalogų struktūra negali viršyti 260 visų simbolių, įskaitant disko raidę, dvitaškį, nugaros brūkšnį ir nulinį slinkimą pabaigoje. Taigi tik potencialus realus MAX_PATH yra 256 simboliai, pvz. C: jūsų 256 simbolių kelias.
Taigi, kas atsitiko, kai išvalėte kompiuterį, kad jūs turėjote katalogą, turintį ilgą kelią (dėl to, kad aplanko pavadinimai buvo ilgi, failų pavadinimai buvo ilgi arba abu), ir kai bandėte perkelti vieną ar daugiau šiuos katalogus į kitą katalogą, turintį ilgą kelią, bendras maršruto pavadinimo ilgis viršijo 260 simbolių apribojimą, kurį nustatė MAX_PATH kintamasis.
Dabar galite galvoti „Ah-hah! Mes tiesiog pakeisime MAX_PATH kintamąjį ir išspręsime problemą! “Deja, tai nėra taip paprasta. „MAX_PATH“ kintamasis yra ne tik sunkiai koduotas į „Windows“, bet net jei jūs peržengėte milžinišką problemą keisti jį, jūs galų gale nulaužėte tiek daug, kad nebūtų verta. Pernelyg daug programų tikisi, kad kelio kintamasis yra tai, ką „Windows“ jau seniai nurodė. Mes negalime tiesiog pereiti prie jo keisti, nesukuriant milžiniško netvarumo.
Kur tai palieka jus? Na, paprasčiausias sprendimas - tiesiog redaguoti kelio duomenis. Pvz., Jei turite tonų išsaugotų straipsnių, kai programa / plėtinys, kurį naudojote išsaugoję iš žiniatinklio, sukūrė katalogą, kuris buvo visas straipsnio pavadinimas + straipsnis, ir tada failo pavadinimas yra visas pavadinimas iš straipsnio + straipsnio, tai būtų tikrai paprasta pasiekti arba viršyti MAX_PATH su vienu įrašymu. Šių milžiniškų aplankų ir straipsnių pavadinimų redagavimas iki tinkamesnio dydžio yra paprastas būdas išspręsti problemą.
Jei turite daug failų, turinčių ilgą kelią ir nenorite jų redaguoti (arba jei norite Ištrinti tonų senų katalogų, kurie yra per ilgai, kad „Windows“ galėtų susidoroti su „MAX_PATH“ kintamuoju), yra komandų eilutės darbas. Nors „Windows“ riboja MAX_PATH kintamasis, „Windows“ inžinieriai suprato, kad yra situacijų, kai naudotojams reikės elgtis su ilgesniais kelio pavadinimais. Todėl „Windows API“ turi funkciją, skirtą spręsti labai ilgus kelius.
Kad galėtumėte pasinaudoti šia API ir naudokite komandų eilutės įrankius savo sudėtinguose aplankuose / failų pavadinimuose, tiesiog reikia pridėti katalogo pavadinimą keliais papildomais simboliais. Pavyzdžiui, jei turėjote didžiulę katalogo struktūrą, kurią norėjote ištrinti (bet gavote klaidą dėl kelio ilgio, kai bandėte jį), galite pakeisti komandą iš:
rmdir c: dokumentai - tikrai-super-long-folder-name schema.
į:
rmdir c: dokumentai-tikrai-super-long-map-name-schema.
Svarbiausias yra papildymas ? \ T
dalis prieš failo kelio pradžią; tai nurodo „Windows“ ignoruoti MAX_PATH kintamojo nustatytus apribojimus ir sąveikauti su keliu, kurį ką tik pateikėte, kaip tiesiogiai / tiesiogiai supranta pagrindinė failų sistema (kuri gali aiškiai palaikyti ilgesnį kelią). Kaip visada, būkite atsargūs komandų eilutėje, kad netyčia neištrintumėte failų ar katalogų, kuriuos ketinate palikti nepažeistus.
Jei mūsų apžvalgoje apie šią problemą smalsu, neabejotinai įsitraukite į šį straipsnį iš „Microsoft“ kūrėjų tinklo bibliotekos, failų, kelių ir pavadinimų vietų pavadinimo, jei norite gauti daugiau informacijos apie tai, kas vyksta po gaubtu.
Ar turite spaudos technologijų klausimą? Atsiųskite mums el. Laišką adresu [email protected] ir mes padarysime viską, kad atsakytume į jį.