De ce este raportat Windows acest folder este prea lung pentru a copia?

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 sau numele fișierului folderului este prea lungă pentru a vă deplasa la o destinație nouă sau chiar a șterge. Care-i treaba?

Hei How-To Geek!

A doua zi, reorganisem niște fișiere pe calculatorul meu, creând foldere, chestii de genul ăsta. Apoi, când mișc unele fișiere într-un dosar, primesc un mesaj, afirmând că calea dosarului rezultată ar fi prea lungă. Eram confuz. Știu că fiecare sistem de operare OS de la DOS acceptă numerele lungi de fișiere, dar Windows susține că calea 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ă explorăm istoricul numelor lungi de fișiere (LFS) și modul în care interacționează Windows cu aceștia înainte de a ne îndrepta spre 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 directori de până la 255 de caractere. Aceasta a fost o extindere binevenită a sistemului de nume de fișiere anterior, 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 mult de câteva dureri de cap care încercau să obțină LFN-urile mai noi ș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), acest nume de fișier a fost tăiat de către unele SFN folosind aplicația moștenită de la un LFN mai lung și neacceptat (cum ar fi abcdefghijk. txt).

Suntem departe de la mijlocul anilor '90, totuși, și întregul lung nume de fișier este (în cea mai mare parte) ferm finisat. 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ă ne confruntăm cu sughiț, așa cum ați descoperit cu proiectul dvs. de curățare a discurilor. Dar de ce? Dacă sistemul Windows Long Filename suportă dosare ș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 depășește cu mult structura tipică a directorilor pe care majoritatea utilizatorilor o va avea vreodată 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ă de directoare completă î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 pentru că numele dosarelor erau lungi, numele fișierelor erau lungi sau ambele) și atunci când ați încercat să mutați una sau mai multe dintre acele 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ă 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 doar să-l schimbăm fără a crea o mizerie enormă.

Unde te lasă asta? Ei bine, cea mai simplă soluție este să editați doar datele despre traseu. De exemplu, dacă aveți o tona de articole salvate î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, iar 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 către 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 API-ul respectiv și de a folosi instrumentele din linia de comandă pe folderele / numele fișierelor dificile, 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 ați dorit să o ștergeți (dar ați primit o eroare datorită 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-schema \

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 limitele 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 subiacente (care poate susține în mod 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-a făcut curioasă, 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 hota.

Aveți o întrebare tehnică presantă? Trimiteți-ne un e-mail la adresa [email protected] și vom face tot ce putem pentru a răspunde.