Dacă lucrați cu Windows destul de mult, în special cu dosarele și fișierele cu nume lungi, veți întâlni o eroare bizară: Windows va raporta că calea dosarului sau numele fișierului este prea lungă pentru a vă deplasa la o destinație nouă sau chiar a șterge. Care-i treaba?
Hei How-To Geek!
Deci, a doua zi, reorganisem niște fișiere pe calculatorul meu, creând dosare, chestii de genul ăsta. Apoi, când m-am mutat unele fișiere într-un dosar, am primit un mesaj, declarând că calea de director rezultată ar fi prea lungă. Eram confuz. Știu că fiecare sistem de operare OS de la DOS acceptă numere lungi de fișiere, dar Windows susține că traseul este prea lung? De ce se întâmplă acest lucru?
Cu stimă,
Domnul dezorganizat
Problema cu care vă confruntați este o intersecție nefericită a două sisteme care, în astfel de cazuri, generează o eroare. Pentru a înțelege exact de unde provine eroarea, trebuie să intrăm în istoria numelor lungi de fișiere (LFS) și a modului în care interacționează Windows cu aceștia înainte de a ajunge la soluții.
Numele lungi de fișiere au fost introduse, prin intermediul arhitecturii MS-DOS subiacente, în Windows 95. Noul sistem LFN a permis numere de fișiere și directoare de până la 255 de caractere. Aceasta a fost o extindere binevenită a sistemului anterior de nume de fișiere, numit de obicei 8.3 nume de fișiere deoarece numele a fost limitat la opt caractere și o extensie de trei cifre, dar de asemenea cunoscut sub numele de Short Filename (SFN). După cum vă puteți imagina, în acel moment erau încă multe aplicații bazate pe DOS și au existat mai multe dureri de cap care înceariseră să obțină noile LFN-uri și SFN-urile moștenite pentru a juca frumos unul cu celălalt. Dacă ați întâlnit vreodată o dischetă mai veche sau un CD-ROM cu fișiere trunchiate ciudat pe ea (ca abcdef ~ 1.txt), numele fișierului a fost tăiat de unele aplicații SFN care utilizează o aplicație moștenită de la un LFN mai lung și neacceptat (cum ar fi abcdefghijk. txt).
Suntem departe de la mijlocul anilor '90, însă întregul lung nume de fișier este (în cea mai mare parte) ferm curățat. Dacă executați o versiune de Windows din ultimii 10 ani, probabil că nu ați întâmpinat nici măcar un conflict de lungime a numelui de fișier ca pe care l-am folosit pentru a rula înapoi în DOS / Windows 95 zile. Acestea fiind spuse, încă mai fugim în sughiț, așa cum ați descoperit cu proiectul dvs. de curățare a discurilor. Dar de ce? Dacă sistemul Windows Long Filename suportă foldere și nume de fișiere de până la 255 de caractere pe component, la ce perete intri? Nu putem da vina pe NTFS (sistemul de fișiere pe care o utilizează marea majoritate a mașinilor moderne Windows), deoarece NTFS va suporta o strângere a dosarelor și a numelor de fișiere până la o lungime totală de 32.767 de caractere. Acest lucru depaseste cu mult structura tipica a directorilor pe care majoritatea utilizatorilor ar avea vreodata nevoie.
În cazul în care toate se împart în afară este o restrângere artificială stive Windows pe partea de sus a sistemului LFN / NTFS: variabila MAX_PATH. Variabila MAX_PATH specifică faptul că o structură completă de directoare în Windows nu poate depăși 260 de caractere totale, inclusiv litera unității, colon, backslash și reacție nulă la sfârșit. Astfel, aveți doar un potențial MAX_PATH real de 256 de caractere, de ex. C: \ ta-256-caractere-cale \.
Ceea ce sa întâmplat atunci când ați curățat calculatorul dvs. este că ați avut un director cu o cale deja lungă (fie că numele dosarelor erau lungi, numele fișierelor erau lungi sau ambele) și când ați încercat să mutați una sau mai multe dintre aceste directoare într-un alt director cu o lungă cale, lungimea totală a denumirii căii a depășit limita de 260 de caractere impusă de variabila MAX_PATH.
Acum s-ar putea să te gândești "Ah-hah! Vom schimba variabila MAX_PATH și vom rezolva problema! "Din păcate, nu este așa de simplu. Nu numai că variabila MAX_PATH este codificată în mod substanțial în Windows, dar chiar dacă ați trecut prin enormul hassle al schimbării acesteia, veți sfârși prin rupere atât de mult încât nu merită. Prea multe aplicații se așteaptă ca variabila căii să fie ceea ce Windows a specificat de mult. Nu putem să mergem să-l schimbăm fără a crea o mizerie enormă.
Unde te lasă asta? Ei bine, cea mai simplă soluție este de a edita doar datele căii. De exemplu, dacă aveți o tona de articole salvate în cazul în care aplicația / extensia pe care ați folosit-o pentru a le salva de pe web a creat un director care a fost titlul complet al articolului + articolul de plumb, și apoi numele de fișier în sine este titlul complet din articolul + conduce articolul, ar fi foarte simplu să atingi sau să depășești MAX_PATH cu o singură salvare. Editarea acestor titluri enorme de dosare și articole până la o dimensiune mai rezonabilă este o modalitate ușoară de a rezolva problema.
Dacă aveți un număr mare de fișiere cu o cale lungă și nu doriți să le editați pe toate (sau dacă dorițișterge o tona de directoare vechi care sunt prea lungi pentru ca Windows să se ocupe cu restricția limitată de variabila MAX_PATH), există o linie de comandă în jurul valorii de lucru. Chiar dacă Windows este restricționat de variabila MAX_PATH, inginerii Windows au realizat că vor exista situații în care utilizatorii ar trebui să se ocupe de nume de cale mai lungi. Ca atare, API-ul Windows are o funcție pentru a trata trasee extrem de lungi.
Pentru a profita de acel API și de a folosi instrumentele din linia de comandă pe folderele / numele de fișiere grele, trebuie doar să adăugați numele directorului cu câteva caractere suplimentare. De exemplu, dacă aveați o structură uriașă de directoare pe care doriți să o ștergeți (dar ați primit o eroare din cauza lungimii căii când ați încercat aceasta), ați putea schimba comanda de la:
rmdir c: \ documents \ some-really-super-long-folder-nume-scheme \
la:
rmdir \? \ c: \ documents \ some-really-super-long-folder-nume-schema \
Cheia este adăugarea \\?\ înainte de începerea căii fișierului; acest lucru instruiește Windows să ignore limitările impuse de variabila MAX_PATH și să interacționeze cu calea pe care tocmai ați furnizat-o ca furnizată / înțeleasă direct de sistemul de fișiere care stă la baza (care poate susține clar o cale mai lungă). Ca întotdeauna, aveți grijă la promptul de comandă pentru a evita ștergerea accidentală a fișierelor sau a directoarelor pe care intenționați să le lăsați intacte.
Dacă prezentarea noastră despre această problemă vă interesează, accesați cu siguranță acest articol din biblioteca Microsoft Developer Network, denumirea fișierelor, a căilor și a spațiilor de nume, pentru mai multe informații despre ce se petrece sub capota.
Aveți o întrebare tehnică presantă? Trimiteți-ne un e-mail la [email protected] și vom face tot posibilul pentru a răspunde.
