Чому Windows Reporting цієї папки занадто довго копіювати?

Якщо ви працюєте з Windows досить довго, особливо з папками та файлами з довгими іменами, ви зіштовхнетеся з химерною помилкою: Windows повідомить, що шлях до папки або ім'я файлу занадто довгий, щоб перейти до нового призначення або навіть видалити. У чому справа?

Гей How-To Geek!

Тому днями я реорганізував деякі файли на моєму комп'ютері, створюючи папки, такі речі. Потім, коли я переносив деякі файли в папку, я отримую повідомлення, яке повідомляє, що отриманий шлях до папки буде занадто довгим. Я був збентежений. Я знаю, що кожна ОС, оскільки DOS підтримує довгі імена файлів, але Windows стверджує, що шлях занадто довгий? Чому це відбувається?

Щиро,

Г-н Дезорганізований

Проблема, з якою ви стикаєтеся, є невдале перетинання двох систем, які в таких випадках дають помилку. Щоб точно зрозуміти, звідки виникає помилка, нам потрібно заглибитися в історію довгих імен файлів (LFN) і про те, як Windows взаємодіє з ними, перш ніж ми заглибимося в рішення..

Довгі імена файлів були введені через базову архітектуру MS-DOS у Windows 95. Нова система LFN дозволяла використовувати назви файлів і каталогів довжиною до 255 символів. Це було приємним розширенням попередньої системи назв файлів, зазвичай називається 8.3 filenaming, оскільки назва обмежувалася до восьми символів і тризначним розширенням, але також відома як коротке ім'я файлу (SFN). Як ви можете собі уявити, тоді ще було багато додатків на базі DOS, і було більше, ніж кілька головних болів, які намагалися отримати нові LFN і застарілі SFN, щоб грати добре один з одним. Якщо ви коли-небудь стикалися зі старою дискетою або компакт-диском з незвично урізаними файлами (наприклад, abcdef ~ 1.txt), це ім'я файлу було скорочено деякою версією SFN-успадкованої програми з деякої довшої та непідтримуваної LFN (як abcdefghijk. txt).

Ми довгий шлях з середини 1990s, але, та вся річ Long Filename є (для найбільшої частини) твердо вигладжена. Якщо ви використовуєте версію Windows за останні 10 років, ви, напевно, ніколи не зіткнулися з конфліктом довжини файлів, як ми звикли працювати в DOS / Windows 95 днів. Тим не менш, ми все одно стикаємося з гикавками, як ви виявили з проектом очищення диска. Але чому? Якщо система довгого файлу Windows підтримує папки та імена файлів довжиною до 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 зрозуміли, що існуватимуть ситуації, коли користувачам доведеться мати справу з довшими іменами шляхів. Таким чином, Windows API має функцію для вирішення надзвичайно довгих шляхів.

Для того, щоб скористатися перевагами цього API і використовувати інструменти командного рядка на ваших непотрібних папках / іменах файлів, вам просто потрібно додати ім'я каталогу з кількома додатковими символами. Наприклад, якщо у вас була велика структура каталогів, яку ви хотіли видалити (але отримали помилку через довжину шляху, коли ви спробували її виконати), ви можете змінити команду з:

rmdir c: документи, які є дійсно супер-довгими-назвами-папками \ t

до:

c-документів-дійсно-супер-довго-папку-ім'я-схема \ t

Ключем є додавання \ T частина перед початком шляху до файлу; це інструктує Windows, щоб нехтувати обмеженнями, що накладаються змінною MAX_PATH, і взаємодіяти з шляху, який ви щойно надійшли як надані / зрозумілі безпосередньо базовою системою файлів (які можуть чітко підтримувати довший шлях). Як завжди, будьте обережні в командному рядку, щоб уникнути випадкового видалення файлів або каталогів, які ви хотіли залишити недоторканими.

Якщо наш огляд цієї проблеми вас цікавить, обов'язково зануртесь у цю статтю з бібліотеки мереж розробників Microsoft, іменуючи файли, шляхи та простору імен, щоб отримати додаткову інформацію про те, що відбувається під капотом.

Чи маєте актуальне технічне питання? Стріляйте нам електронною поштою на [email protected], і ми зробимо все можливе, щоб відповісти на нього.