If-Koubou

Защо докладването от Windows на тази папка е твърде дълго за копиране?

Защо докладването от Windows на тази папка е твърде дълго за копиране? (Как да)

Ако работите с Windows достатъчно дълго, особено с папки и файлове, които имат дълги имена, ще се появи странна грешка: Windows ще съобщи, че пътят на папката или името на файла е твърде дълъг, за да се премести в нова дестинация или дори да изтрие. Каква е сделката?

Хей как да се Гейк!

И така, онзи ден реорганизирах някои файлове на моя компютър, създавайки папки, такива неща. След това, когато прехвърлях някои файлове в папка, получавам съобщение, в което се посочва, че полученият път на папките ще бъде твърде дълъг. Бях объркан. Знам, че всяка OS, тъй като DOS поддържа Long Filenames, но Windows твърди, че пътят е твърде дълъг? Защо се случва това?

Sincerly,

Г- н Дезорганизирано

Проблемът, с който се сблъсквате, е жалко кръстовище на две системи, което в такива случаи води до грешка. За да разберем точно откъде идва грешката, трябва да се впишем в историята на Long Filenames (LFN) и как Windows взаимодейства с тях, преди да се впуснем в решения.

Дълги имена на файлове бяха въведени чрез основната архитектура на MS-DOS в Windows 95. Новата система LFN позволяваше имена на файлове и директории до 255 знака. Това беше добре дошло разширение на предишната система за имена на файлове, обикновено наречено 8.3 имена на файлове, тъй като името е ограничено до осем символа и трицифрено разширение, но също така е известно като Short Filename (SFN). Както можете да си представите, тогава все още имаше много DOS-базирани приложения наоколо и имаше повече от няколко главоболия, опитващи се да получат по-новите LFNs и наследниците SFNs да играят хубаво един с друг. Ако някога сте се натъкнали на по-стара дискета или CD-ROM със странно съкратени файлове (например abcdef ~ 1.txt), името на файла е било отрязано от някое SFN-използвано наследствено приложение от по-дълъг и неподдържан LFN (като abcdefghijk. текст).

Дълги сме, обаче, от средата на 90-те години на миналия век и цялото дълго име на файла (в по-голямата си част) е твърдо изгладено. Ако работите с версия на Windows от последните 10 години, вероятно никога няма да срещнете дори конфликт с дължина на файла, какъвто използвахме, за да се върнете обратно в DOS / Windows 95 дни. Това каза, че все още сме в хълцане, както открихте с проекта за почистване на диска. Но защо? Ако системата Windows Long Filename поддържа папки и имена на файлове с до 255 символа на компонент, в коя стена се намирате? Не можем да обвиняваме NTFS (файловата система, която използва по-голямата част от съвременните машини с Windows), тъй като NTFS ще поддържа обединяване на папки и имена на файлове до обща дължина от 32 767 знака. Това далеч надхвърля типичната структура на директорията, която повечето потребители биха имали нужда.

Където всичко се разпада, това е изкуствено ограничение на Windows стека над системата LFN / NTFS: променливата MAX_PATH. Променливата MAX_PATH указва, че цялата структура на директорията в Windows не може да надвишава 260 общи знака, включително буквата на устройството, двоеточие, обратна наклонена черта и невъзможност за връщане в края. По този начин имате само потенциална MAX_PATH от 256 знака, напр. C: \ си-256-знаков-път \.

Така че какво се случи, когато почиствате компютъра си, е, че сте имали директория с вече дълъг път (било защото имената на папките са били дълги, имената на файловете са били дълги или и двете) и когато се опитахте да преместите един или повече от тези директории в друга директория с дълъг път, общата дължина на името на пътя е надхвърлила ограничението от 260 знака, наложено от променливата MAX_PATH.

Сега можете да мислите "Ах-ха! Просто сменим променливата MAX_PATH и решим проблема! "Уви, това не е толкова просто. Не само променливата MAX_PATH е по същество твърдо кодирана в Windows, но дори и да сте претърсили огромната караница да я промените, щяхте да се скъсате толкова много, че няма да й струва. Твърде много приложения заявяват, че променливата на пътя е това, което Windows определи отдавна. Не можем просто да го променим, без да създаваме огромна бъркотия.

Къде ви оставя това? Е, най-простото решение е просто да редактирате данните за пътя. Ако например имате тон от запазени статии, в които приложението / разширението, което сте използвали, за да ги запазите от мрежата, е създадена директория, която е пълното заглавие на статията + заглавието на статията, а самата име на файла е пълното заглавие от статия + водещата статия, би било много лесно да се удари или надвиши MAX_PATH с едно спасяване. Редактирането на тези огромни заглавия на папки и статии до по-разумен размер е лесен начин за решаване на проблема.

Ако имате огромен брой файлове с дълъг път и не искате да ги редактирате всички (или, ако искате)Изтрий тон от стари директории, които са твърде дълги, за да се справят с Windows, когато са ограничени от променливата MAX_PATH), има работа около командния ред. Въпреки че Windows е ограничен от променливата MAX_PATH, инженерите на Windows осъзнават, че има ситуации, при които потребителите ще трябва да се справят с по-дълги имена на маршрути. По този начин API на Windows има функция за справяне с изключително дълги пътища.

За да се възползвате от този приложния програмен интерфейс (API) и да използвате инструменти на командния ред на ненужните си папки / имена на файлове, просто трябва да добавите името на директорията с няколко допълнителни знака. Например, ако имате огромна структура на директории, която искате да изтриете (но сте получили грешка поради дължината на пътя, когато сте я направили), можете да промените командата от:

rmdir c: \ documents \ some-really-super-long-папка-име-схема \

да се:

rmdir \? \ c: \ documents \ some-really-super-long-папка-име-схема \

Ключът е добавянето на \\?\ част преди началото на пътя на файла; това инструктира Windows да пренебрегва ограниченията, наложени от променливата MAX_PATH, и да взаимодейства с пътя, който току-що сте предоставили като предоставен / разбран директно от системата на файловете, която може да поддържа по-дълъг път. Както винаги, внимавайте в командния ред, за да избегнете случайно изтриването на файлове или директории, които възнамерявате да оставите непокътнати.

Ако нашият преглед на този проблем ви е любопитен, определено се впуснете в тази статия от библиотеката на Microsoft Developer Network, наименувате файлове, пътища и имена, за повече информация за това, което се случва под качулката.

Имате належащ технически въпрос? Изпратете ни имейл на [email protected] и ще направим всичко възможно, за да му отговорим.