Чому обмеження довжини шляху 260 символів існує в Windows?

Я кілька разів зіткнувся з цією проблемою у невідповідні моменти:

• Спроба працювати над проектами Java з відкритим кодом з глибокими шляхами
• Зберігання глибоких дерев вікі Fitnesse у контролі джерел
• Помилка спроби використовувати Bazaar для імпорту мого дерева керування джерелами

Чому існує така межа?

Чому її ще не видалено?

Як ви справляєтесь з межею шляху? І ні, перехід на Linux або Mac OS X не є коректною відповіддю на це питання;)

Цитуючи цю статтю https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Максимальне обмеження довжини шляху

В API Windows (за деякими винятками, що обговорюються в наступних параграфах), максимальна довжина шляху - MAX_PATH , яка визначається як 260 символів. Локальний шлях структурований у такому порядку: літера диска, двокрапка, зворотна косої частини, назви компонентів, розділені косою рисою, та завершальний нульовий символ. Наприклад, максимальний шлях на диску D - "D: \ деякий рядок шляху 256 символів <NUL>", де "<NUL>" являє собою невидимий завершальний нульовий символ для поточної системної кодової сторінки. (Символи <> використовуються тут для наочності чіткості і не можуть бути частиною дійсної рядки шляху.)

Тепер ми бачимо, що це 1 + 2 + 256 + 1 або [drive] [: \] [path] [null] = 260. Можна припустити, що 256 є розумною фіксованою довжиною рядка від DOS днів. Повертаючись до API DOS, ми розуміємо, що система відстежувала поточний шлях на диск, і ми маємо 26 (32 із символами) максимальних накопичувачів (та поточних каталогів).

INT 0x21 AH = 0x47 говорить: "Ця функція повертає опис шляху без літери диска та початкової косої риски". Отже, ми бачимо, що система зберігає CWD як пару (диск, шлях), і ви запитуєте шлях, вказавши привід (1 = A, 2 = B, ...), якщо ви вказали 0, то він передбачає шлях для привід повернувся INT 0x21 AH = 0x15 AL = 0x19. Отже, тепер ми знаємо, чому це 260, а не 256, оскільки ці 4 байти не зберігаються в рядку шляху.

Чому 256-байтний рядок шляху, тому що 640K достатньо оперативної пам'яті.

Це не зовсім вірно, оскільки файлова система NTFS підтримує шляхи до 32 к символів. Ви можете використовувати ap32 win32 та \\?\префікс шляху, щоб використовувати більше 260 символів.

Детальне пояснення довгого шляху з блогу команди .Net BCL .
Невеликий уривок висвітлює проблему довгими шляхами

Інше занепокоєння викликає непослідовність поведінки, яка виникла б під впливом довгої підтримки. Довгі шляхи з \\?\префіксом можна використовувати в більшості файлів, пов'язаних з файлами API, але не у всіх API API. Наприклад, LoadLibrary, який відображає модуль на адресу процесу виклику, виходить з ладу, якщо ім'я файлу довше MAX_PATH. Таким чином, це означає, що MoveFile дозволить вам перемістити DLL в таке місце, щоб шлях не перевищував 260 символів, але якщо ви спробуєте завантажити DLL, це не вдасться. Подібні приклади є у всіх API API; деякі обхідні шляхи існують, але вони є для кожного конкретного випадку.

Питання в тому, чому обмеження все ще існує. Безумовно, сучасні Windows можуть збільшити сторону, MAX_PATHщоб дозволити довші шляхи. Чому обмеження не знято?

• Причина її неможливо усунути - це те, що Windows пообіцяла, що ніколи не зміниться.

За допомогою контракту API Windows гарантувала всім програмам, що стандартні API файли ніколи не повернуть шлях, довший за 260символи.

Розглянемо наступний правильний код:

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

Windows гарантувала моїй програмі, що вона заповнить мою WIN32_FIND_DATAструктуру:

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

У моїй програмі не було оголошено значення константи MAX_PATH, це зробив API Windows. Моя програма використовувала це визначене значення.

Моя структура правильно визначена і виділяє лише 592байти. Це означає, що я можу отримувати лише ім’я файлу, менший за кількість 260символів. Windows пообіцяла мені, що якщо я правильно напишу заявку, моя програма продовжуватиме працювати в майбутньому.

Якби Windows мала дозволити назви файлів довше, ніж 260символи, тоді мій існуючий додаток (який правильно використовував правильний API) не зможе.

Для всіх, хто закликає Microsoft змінити MAX_PATHконстанту, вони спочатку повинні переконатися, що жодна існуюча програма не працює. Наприклад, я все ще є власником і використовую додаток Windows, яке було написано для роботи в Windows 3.11. Він все ще працює у 64-розрядної Windows 10. Саме тому ви отримуєте зворотну сумісність.

Microsoft зробив створити спосіб використовувати повні імена шляхів 32768; але їм довелося створити новий контракт API, щоб це зробити. Для одного, ви повинні використовувати API Shell для перерахування файлів (оскільки не всі файли існують на жорсткому диску або спільній мережі).

Але вони також повинні не порушувати існуючі користувацькі програми. Переважна більшість додатків не використовують оболонки api для роботи з файлами. Усі просто дзвонять FindFirstFile/ FindNextFileі називають це щодня.

З Windows 10. ви можете зняти обмеження , змінивши ключ реєстру.

Порада Починаючи з Windows 10, версія 1607, обмеження MAX_PATH були вилучені із загальних функцій файлів та каталогів Win32. Однак ви повинні відмовитися від нової поведінки.

Ключ реєстру дозволяє ввімкнути або вимкнути нову поведінку довгого шляху. Щоб увімкнути поведінку довгого шляху, встановіть ключ реєстру на HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(Тип REG_DWORD:). Значення ключа буде кешовано системою (за кожний процес) після першого виклику постраждалого файлу або функції каталогу Win32 (список наведено нижче). Ключ реєстру не буде перезавантажений протягом життя процесу. Для того, щоб усі додатки в системі визнали значення ключа, може знадобитися перезавантаження, оскільки деякі процеси, можливо, почалися ще до встановлення ключа. Ключ реєстру можна також контролювати за допомогою групової політики за адресою Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Ви також можете ввімкнути нову поведінку довгого шляху в додатку за допомогою маніфесту:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

Ви можете змонтувати папку як диск. У командному рядку, якщо у вас є шлях, C:\path\to\long\folderви можете зіставити його для перенесення букви X:за допомогою:

subst x: \path\to\long\folder

Один із способів впоратися з межею шляху - скоротити записи шляху символічними посиланнями.

Наприклад:

1. створити C:\pкаталог для збереження коротких посилань на довгі шляхи
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. додайте C:\p\fooдо свого шляху замість довгого шляху

Можна ввімкнути довгі імена шляху за допомогою PowerShell:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 

Інша версія полягає в використанні групової політики Computer Configuration/ Administrative Templates/ System/ Filesystem:

Щодо того, чому це все ще існує - MS не вважає це пріоритетом, а цінує зворотну сумісність над просуненням своєї ОС (принаймні в цьому випадку).

Обхід, який я використовую, полягає у використанні "коротких імен" для каталогів на шляху замість їх стандартних, читаних для людини версій. Так , наприклад , для C:\Program Files\Я хотів би використовувати C:\PROGRA~1\ Ви можете знайти еквіваленти коротку назву , використовуючи dir /x.

Щодо того, як впоратися з обмеженням розміру шляху в Windows - використання 7zip для упаковки (і розпакування) файлів, чутливих до довжини шляху, виглядає як життєздатне рішення. Я використовував його для транспортування декількох установок IDE (ті шляхи плагінів Eclipse, витівки!) Та купи автогенерованої документації, і до цього часу не було жодної проблеми.

Не дуже впевнений, як це ухиляється від ліміту 260 знаків, встановленого Windows (від технічного PoV), але так, це працює!

Детальніше на їхній сторінці SourceForge тут :

"NTFS насправді може підтримувати імена шляхів довжиною до 32 000 символів."

7-zip також підтримує такі довгі імена.

Але він відключений у коді SFX. Деякі користувачі не люблять довгі шляхи, оскільки не розуміють, як з ними працювати. Ось чому я відключив його в коді SFX.

і випустити нотатки :

9.32 альфа 2013-12-01

• Покращена підтримка імен файлів довше 260 символів.

4,44 бета-версія 2007-01-20

• 7-Zip тепер підтримує назви файлів, довжина яких перевищує 260 символів.

ВАЖЛИВА ПРИМІТКА. Щоб правильно функціонувати, вам потрібно буде вказати шлях призначення у діалоговому вікні "Витяг" 7zip безпосередньо, а не перетягувати файли в потрібну папку. В іншому випадку папка "Темп" буде використовуватися як проміжний кеш, і ви підскочите до того ж обмеження на 260 знаків, як тільки Провідник Windows почне переміщати файли в "остаточне місце спокою". Дивіться відповіді на це запитання для отримання додаткової інформації.

Це так, і це за замовчуванням з певних причин, але ви можете легко замінити його за допомогою цього ключа реєстру:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

Дивіться: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Ще один спосіб впоратися з цим - використовувати Cygwin, залежно від того, що ви хочете робити з файлами (тобто, якщо команди Cygwin відповідають вашим потребам)

Наприклад, він дозволяє копіювати, переміщувати чи перейменувати файли, які навіть Windows Explorer не може. Або, звичайно, розібратися зі вмістом у них, наприклад, md5sum, grep, gzip тощо.

Також для програм, які ви кодуєте, ви можете зв’язати їх із DLL Cygwin, і це дозволить їм використовувати довгі шляхи (я цього не перевіряв)