Calea țintă este prea lungă. Dacă un fișier cu un nume lung nu este șters și apare o eroare că sistemul de fișiere nu acceptă astfel de nume lungi
Pe unul dintre proiecte am avut ocazia să folosesc modulul pentru Drupal - validare client. Și nu este că modulul este rău, dimpotrivă, își îndeplinește pe deplin funcționalitatea, și anume, verifică formularul din partea clientului. Dar fișierele modulului au nume destul de lungi și, din cauza unuia dintre aceste fișiere, git-ul nostru a încetat să funcționeze corespunzător. Pentru că nu am mai putut scrie informații în acest folder din cauza următoarei erori:
Nu se poate copia fișierul/dosarul. Numele fișierului de destinație/calea de destinație prea lung
Sau, de asemenea, dar în engleză:
Numele fișierului ar fi prea lung pentru folderul de destinație. Puteți scurta numele fișierului și puteți încerca din nou sau puteți încerca o locație care are o cale mai scurtă.
După ce am făcut puțină cercetare, s-a dovedit că lungimea maximă a căii acceptată de Windows 7 este de 260 de caractere. Și din moment ce toate proiectele sunt stocate în folderul meu C:\Utilizatori\\Documente\xampp\htdocs\git\- atunci toate proiectele erau potențial în pericol.
Opțiuni de soluție
Am vazut 2 solutii posibile:
1. Mutați xampp în capul discului
2. Creați un alias pentru această cale (de exemplu, o unitate numită H)
A doua varianta mi s-a parut mai simpla, pentru ca pentru xampp caile nu se vor schimba, dar cu git vom intra in foldere prin aliasul creat. Ei bine, pentru ca IDE-ul să funcționeze corect, va trebui să schimbați calea proiectelor.
Și astfel, pentru ca Windows să înlocuiască numele unității cu calea lungă, rulați comanda prin cmd:
Subst H: C:\Utilizatori\\Documente\xampp\htdocs\git\
Mulți utilizatori de PC-uri Windows, ca să nu mai vorbim de dezvoltatori, sunt familiarizați cu problemele atunci când lucrează cu căi lungi (mai mult de 260 de caractere, MAX_PATH) pentru fișiere sau directoare.
Acest articol discută modalități de a scăpa de această relicvă atunci când se dezvoltă aplicații pe diverse platforme (WinApi, .Net Framework, .Net Core) și se activează suportul nativ pentru căi lungi în Windows 10 (Actualizare aniversară).
Win API Applications
În aplicațiile care utilizează API-ul Win pentru a lucra cu fișiere, rețeta pentru a scăpa de limitarea MAX_PATH este cunoscută din timpuri imemoriale - a fost necesar să se folosească versiunea Unicode a funcției cu sfârșitul „W” pentru a lucra cu un director sau fișier și începeți calea cu prefixul \\?\. Acest lucru a făcut posibilă utilizarea căilor de până la 32767 de caractere.În Windows 10 (1607), comportamentul funcțiilor pentru lucrul cu fișierele s-a schimbat: acum este posibil să dezactivați verificarea restricțiilor MAX_PATH la nivel de sistem.
Acest lucru a afectat următoarele funcții:
Pentru a lucra cu directoare: CreateDirectoryW, CreateDirectoryExW, GetCurrentDirectoryW, RemoveDirectoryW, SetCurrentDirectoryW. Și pentru lucrul cu fișiere: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExtW, GetNameW, GetNameW, GetName MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.
Acest lucru elimină necesitatea prefixului \\?\ și poate oferi aplicațiilor care rulează direct sau indirect prin API-ul Win șansa de a obține suport pentru căi lungi fără a fi nevoie să le reconstruiască. Cum să activați această funcție este descris la sfârșitul articolului.
.Cadru net
Deși .Net Framework folosește API-ul Win pentru a lucra cu fișiere, modificarea anterioară nu ar fi adus rezultate, deoarece Codul BCL are încorporate verificări preliminare pentru permisiunea lungimii numelor de director și fișiere și nici măcar nu a ajuns la punctul de a apela funcțiile Win API, aruncând o excepție cunoscută. Datorită numeroaselor solicitări din partea comunității (mai mult de 4500 pe UserVoice), în versiunea 4.6.2, verificările privind restricțiile privind lungimea căii au fost eliminate din codul BCL, lăsând acest lucru în sarcina sistemelor de operare și de fișiere!Iată ce oferă:
- Folosind prefixul „\\?\” putem lucra cu căi lungi ca în API-ul Win, Directory.CreateDirectory("\\\\?\\" + long_dir_name);
- Dacă activați suportul nativ Windows 10 pentru nume lungi de fișiere (1607), nici măcar nu va trebui să utilizați un prefix!
- Utilizați .Net Framework 4.6.2 ca țintă atunci când construiți aplicația.
- Utilizați un fișier de configurare, de exemplu, dacă aplicația a fost deja construită sub .Net 4.0:
.Net Core
Aici, sprijinul pentru căi lungi a fost anunțat încă din noiembrie 2015. Se pare că natura Open Source a proiectului și lipsa unei necesități stricte de a asigura compatibilitatea cu versiunea anterioară au avut un impact.Cum se pornește:
Totul funcționează din cutie. Spre deosebire de implementarea în .Net Framework, nu este nevoie să adăugați prefixul „\\?\” - acesta este adăugat automat dacă este necesar.
Aici puteți vedea un exemplu.
Cum să activați suportul pentru căi lungi în Windows 10 (1607)
Această caracteristică este dezactivată în mod implicit. Acest lucru se datorează faptului că această caracteristică este experimentală și diferite subsisteme și aplicații trebuie dezvoltate pentru suport complet.Puteți activa suportul încorporat pentru căi lungi prin crearea sau modificarea următorului parametru de registry de sistem: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled parametru (Tip: REG_DWORD) 1 – corespunde valorii activate.
Sau prin politicile de grup (Win+R\gpedit.msc) Configurare computer > Șabloane administrative > Sistem > Sistem de fișiere > Activați căi lungi NTFS. Este același lucru într-o versiune localizată: Configurare computer > Șabloane administrative > Sistem > Sistem de fișiere > Activați căi lungi Win32.
Mai departe, sursele nu sunt de acord în privința manifestului (sau am înțeles greșit, dar momentan nu am cum să verific). De exemplu, documentația MSDN afirmă că un manifest poate fi utilizat ca o modalitate alternativă de a activa suportul pentru căi lungi în aplicații individuale, iar blogul MSDN afirmă că acesta este al doilea pas necesar după activarea acestuia în politici.
Dar sunt de acord în formatul pentru specificarea acestei opțiuni:
Din păcate, acest lucru nu va funcționa cu CMD în acest moment, din cauza particularităților de lucru cu căi, dar în PowerShell totul ar trebui să funcționeze.
P.S.
Aceasta se încheie micul meu post de vineri, lăsând deoparte întrebările privind caracterul complet al implementării suportului pentru căi lungi în Windows 10 (1607) sau performanța atunci când se utilizează diferite combinații de ediții Windows, sisteme de fișiere și API-uri. Postarea va fi actualizată pe măsură ce devin disponibile noi fapte și rezultate experimentale.Vă mulțumim pentru atenție!
Titlul s-a dovedit a fi lung, dar indică esența problemei care va fi descrisă aici. Recent am întâlnit o situație nu foarte bună. În timp ce sortam hard disk-ul și îl ștergeam de lucruri inutile, am descoperit că unul dintre fișiere nu a fost șters, dar a apărut următoarea eroare: „Sistemul de fișiere nu acceptă nume de fișiere sursă atât de lungi. Încercați să mutați fișierul într-un folder cu o lungime de cale mai scurtă sau specificați un nume de fișier mai scurt și încercați din nou."
Nu numai că nu am putut șterge fișierul, dar nici nu am putut schimba numele cu un nume mai scurt. Pentru mulți, acest lucru ar părea un punct mort, deoarece se dovedește că fișierul nu este șters.De fapt, problema poate fi rezolvată foarte simplu și rapid, iar acum voi descrie două metode de rezolvare și rămâne la latitudinea dvs. să decideți pe care să o utilizați.
Ce să faci dacă calea către sursă este prea lungă, cum să ștergi un astfel de fișier?
Dacă aveți un fișier care nu este șters din cauza unui nume lung, există mai multe opțiuni pentru a rezolva problema. De exemplu, un fișier este imbricat în mai multe directoare, să spunem cinci sau chiar zece foldere care au nume de 10-20 de caractere, atunci acesta poate fi motivul pentru care nu ștergeți fișierul. Cert este că Windows nu acceptă niciun fișier al căror nume depășește 260 de caractere. Dacă această limită este depășită, va apărea eroarea pe care am arătat-o mai sus. Numărul de foldere cu nume proprii și numele fișierului în sine ar trebui să însumeze mai puțin de 260 de caractere. Sistemul are și o caracteristică - dacă această limită este depășită, putem redenumi în continuare folderele. Aceasta înseamnă că trebuie să redenumiți toate folderele cu un nume scurt, de exemplu, o literă sau un număr.
Această problemă poate apărea nu numai pentru că ați dat un nume atât de lung. Mi s-a întâmplat asta când am decis să descarc fișierele site-ului de pe server și să fac ceva. Deoarece fișierele nu mai erau necesare, am șters întregul director cu fișierele site-ului, dar după cum s-a dovedit, acesta conținea un fișier cu un nume foarte lung, plus nume de foldere, iar acest lucru nu mi-a permis să-l șterg pe tot.
Metoda a doua va ajuta dacă primul a eșuat. Faptul este că nu toate folderele care duc la un fișier cu nume lung pot fi redenumite și va apărea aceeași eroare a sistemului de fișiere. Apoi puteți crea un disc virtual folosind oricare dintre subfolderele care conduc la fișierul care nu poate fi șters. Acum vă voi arăta cum să faceți asta.
Deschideți linia de comandă. Pentru a face acest lucru, apăsați combinația Win+R și introduceți comanda cmd. Puteți face clic dreapta pe meniul Start (sau pe combinația de taste Win+X) și selectați Command Prompt acolo.
Acum scrieți o comandă care va crea un disc virtual pentru noi:
Trebuie să selectați o literă de unitate care nu este ocupată de alții. Partiția de sistem este de obicei indicată ca C, iar a doua partiție ca D sau E, apoi selectați oricare alta.
Calea către folder trebuie specificată de pe disc. Dacă acest lucru este dificil pentru dvs., atunci deschideți folderul care va acționa ca un disc virtual și copiați calea către acesta în Explorer în partea de sus.
Comanda mea arată astfel:
Când mergem la My Computer, ar trebui să vedeți acolo o unitate cu litera pe care i-am atribuit-o din linia de comandă. Astfel, calea către fișier va fi redusă cu aproape jumătate, ceea ce înseamnă că lungimea totală a caracterelor poate fi mai mică de 260 de caractere. Acum poți încerca să scapi de undeletable.
Pentru a șterge un disc virtual trebuie să introduceți comanda:
| substDiskLetter/d |
Folosind Total Commander
Pe Internet, am descoperit o metodă care vă permite să ștergeți fișiere care nu pot fi șterse folosind . Desigur, dezavantajul aici este că va trebui să instalați software suplimentar pe computer și nu toată lumea va dori să facă acest lucru. În orice caz, voi lăsa această metodă aici în cazul în care cineva dorește să o folosească.
Descărcați și instalați programul. Să mergem la filă "Fişier" faceți clic pe secțiune „Schimbați atributele”. Apare o fereastră în care eliminăm bifa din toate atributele. Dacă nu există nicio bifă lângă elementul din partea de sus „Procesează conținutul directorului”- alege. Acum din același program încercăm să ștergem un fișier cu nume lung.
Folosim arhivatorul 7-Zip
Pentru această sarcină vom avea nevoie de un arhivator 7-Zip. Faceți clic dreapta pe directorul de pornire și îndreptați mouse-ul spre partiție „7-Zip”și selectați elementul "Adauga la arhiva".
Apare o fereastră în care trebuie să bifați o singură casetă „Ștergeți fișierele după compresie”. Apoi faceți clic pe OK.
O arhivă cu toate aceste lucruri este creată pe desktop, iar folderele cu fișiere lungi sunt pur și simplu șterse. Puteți șterge arhiva în sine fără probleme.
Acestea sunt modalitățile pe care le-am analizat pentru a remedia eroarea fișierului care nu este șters. Poate ai alte opțiuni despre cum să faci asta?
Nu este un secret pentru nimeni că Windows Explorer, ca majoritatea altor aplicații Windows, inclusiv PowerShell, nu poate funcționa cu obiecte de sistem de fișiere cu imbricare de foldere profunde. a cărei lungime a căii depășește 260 de caractere. Mai mult decât atât, această limitare există doar la nivel de aplicație, iar sistemul de fișiere NTFS însuși acceptă căi de fișiere până la 32767 personaje.
Această limitare este impusă de bibliotecă Win32 API, și a cărui lungime maximă a căii este de 260 de caractere ( MAX_PATH=260). În general, traseul este format din următoarele elemente: +[cale_of_256_characters]+[
Sfat. Puteți ocoli această limitare a API-ului Win32 și puteți lucra cu nume lungi de fișiere folosind formatul de cale UNC, specificând calea absolută către fișier folosind prefixul de cale cu lungime extinsă \\?\ . De exemplu, așa \\?\C:\SomeLongPath\LongNameFile.txt
Această restricție nu se aplică și atunci când utilizatorii au acces la fișiere prin intermediul protocolului SMB (din acest motiv, structurile de directoare cu căi lungi sunt comune pe serverele de fișiere cu date utilizator). Administratorul care întreține acest server nu poate gestiona (șterge/muta) fișiere cu căi lungi prin interfața standard Windows Explorer. Când încercați să creați/copiați un fișier într-un astfel de director, apare o eroare:
Calea spre destinație prea lungă. Numele (numele) fișierului ar fi prea lung pentru folderul de destinație. Puteți scurta numele fișierului și puteți încerca din nou sau puteți încerca o locație care are o cale scurtă
Alte programe/casete de dialog pot raporta prezența restricției în felul lor.
De acord, e amuzant că este 2014 și încă vorbim despre limita de 260 de caractere pentru lungimea maximă a căii în Windows... Dar se pare că nu sunt de așteptat schimbări drastice în viitorul apropiat și chiar și în cel mai recent Previzualizarea tehnică Windows 10, această limitare încă mai există.
În acest articol vom arăta cum în Windows puteți lucra cu fișiere a căror cale depășește 260 de caractere. În acest caz, sarcina noastră este să ștergem un director care conține fișiere cu o lungime mare de cale.
Când încercați să ștergeți un astfel de director din Explorer, apare o eroare:
Numele fișierului ar fi prea lung pentru folderul de destinație. Puteți scurta numele fișierului și puteți încerca din nou sau puteți încerca o locație care are o cale scurtă.
De asemenea, Powershell nu poate gestiona corect directoarele și fișierele cu căi mari care depășesc 260 de caractere. Când încercați să ștergeți un director cu astfel de fișiere (C:\Install\MS SQL 2012 Express Edition pe 64 de biți\verylongpath), apare o eroare:
Remove-Item .\verylongpath -Recurse
Remove-Item: calea specificată, numele fișierului sau ambele sunt prea lungi. Numele de fișier complet calificat trebuie să fie mai mic de 260
caractere, iar numele directorului trebuie să aibă mai puțin de 248 de caractere.
La linia:1 char:1
+ Remove-Item .\verylongpath -Recurse
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo: WriteError: (C:\Install\MS S...it\verylongpath:String) , PathTooLongExcepti
pe
+ FullyQualifiedErrorId: RemoveItemIOError, Microsoft.PowerShell.Commands.RemoveItemCommand 
Cea mai simplă opțiune (este, de fapt, sugerată în fereastra de eroare) este de a scurta numele folderelor părinte, reducând lungimea totală a căii (dar aceasta nu este întotdeauna aplicabilă).
Mklink /d c:\install\link „C:\Install\MS SQL 2012 Express Edition pe 64 de biți\verylongpath”
O altă opțiune, care amintește de lucrul cu o legătură simbolică, este să mapați folderul problematic pe un disc virtual (în exemplul nostru X:), reducând astfel și lungimea căii:
Subst X: „C:\Install\MS SQL 2012 Express Edition pe 64 de biți\verylongpath”
Acum puteți lucra cu date pe unitatea X:, căile către fișiere în care nu vor depăși limita. După terminarea lucrului, puteți șterge discul virtual:
Subst X: /d
Dar personal, ceea ce îmi place cel mai mult pentru sarcina de a șterge date în astfel de situații este capacitatea robocopy.exe, care sprijină lucrul cu căi lungi.
Folosind opțiunea /MIR, utilitarul robocopy poate crea o copie completă (oglindă) a directorului sursă în directorul țintă. Și, dacă folderul sursă este gol, toate datele din folderul țintă sunt, de asemenea, șterse. Să creăm un folder gol C:\Instalare\testși folosind argumentul /MIR, copiați conținutul folderului de testare în folderul țintă (dacă numele folderului conține spații sau caractere chirilice, calea trebuie inclusă între ghilimele).
Robocopy /MIR C:\Install\test "C:\Install\MS SQL 2012 Express Edition pe 64 de biți\verylongpath"
După executarea comenzii, conținutul directorului C:\Install\MS SQL 2012 Express Edition pe 64 de biți\verylongpath este șters (înlocuit cu conținutul directorului gol).
Așadar, astăzi am arătat câteva trucuri simple pe care le puteți folosi atunci când lucrați cu foldere pe servere de fișiere care conțin foldere a căror lungime de cale depășește limita de 260 de caractere.
