22Aug
Dacă lucrați cu Windows destul de mult, mai ales cu foldere și fișiere care au nume lungi, veți întâlni o eroare bizară: Windows va raporta că calea 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 foldere, 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, însă Windows susține că traseul este prea lung? De ce se întâmplă acest lucru?
Sincer,
Dl Disorganized
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 de fișiere lungi au fost introduse, prin intermediul arhitecturii MS-DOS subiacente, în Windows 95. Noul sistem LFN a permis numere de fișiere și directori 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 lucru pe care Long Filename este( în cea mai mare parte) este ferm ironizat. Dacă rulaț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 de curățare a discului. 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 totul se destramă este o restrângere artificială Windows stive în 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: \ calea dvs. de 256 de caractere \ .
Deci, ce sa întâmplat atunci când ați curățat calculatorul este că aveați 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 multedin acele directoare într-un alt director cu o cale lungă, lungimea totală a denumirii căii a depășit limita de 260 de caractere impusă de variabila MAX_PATH.
Acum, poate vă gândiți "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 vă 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 completdin 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 să ștergeți o tona de directoare vechi prea lungi pentru Windows, atunci când acestea sunt restricționate de cătreMAX_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ă ați avut o structură uriașă de directoare pe care ați dorit să o ștergeți( dar ați primit o eroare datorită lungimii căii când ați încercat), ați putea schimba comanda din:
rmdir c: \ documents \ some-really-super-sub-nume-schemă de nume \
la:
rmdir \\? \ c: \ documents \ some-really-super-long-folder-name-scheme \
Cheia este adăugarea porțiunii \\?î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 se află subiacent( 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ă cu exactitate, accesați cu siguranță acest articol din biblioteca Microsoft Developer Network, denumirea fișierelor, căi și spații 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.