Новости
Багатьом користувачам ПК під управлінням ОС Windows, не кажучи про розробників, знайомі проблеми при роботі з довгими (більше 260 символів, MAX_PATH) шляхами файлів або каталогів.
У даній статті розглядаються способи позбавлення від цього пережитку при розробці додатків на різних платформах (WinApi, .Net Framework, .Net Core) і активації нативной підтримки довгих шляхів в Windows 10 (Anniversary Update).
Додатки Win API
У додатках, які використовують Win API для роботи з файлами, рецепт порятунку від обмеження MAX_PATH був відомий з давніх-давен - необхідно було використовувати Unicode версію функції з закінченням «W» для роботи з Директорією або файлом і починати шлях з префікса \\? \. Це давало можливість використовувати шляхи довгою до 32767 символів.
У Windows 10 (1607) поведінку функцій для роботи з файлами змінилося: з'явилася можливість відключити перевірку обмежень MAX_PATH на рівні системи.
Це торкнулося наступних функцій:
Для роботи з каталогами: CreateDirectoryW, CreateDirectoryExW, GetCurrentDirectoryW, RemoveDirectoryW, SetCurrentDirectoryW. І для роботи з файлами: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.
Це позбавляє від необхідності використовувати префікса \\? \ І потенційно дає шанс додатків, які працюють безпосередньо або побічно через Win API, отримати підтримку довгих шляхів без необхідності їх пересборки. Як активувати цю можливість описано в кінці статті.
.Net Framework
Хоча .Net Framework і використовує Win API для роботи з файлами - попереднє зміна не принесло б результату, тому що в код BCL вбудовані попередні перевірки на допустимість довжини імен каталогів і файлів, і до виконання функцій Win API справа навіть не доходило, видаючи відоме виключення. На численні прохання спільноти (більше 4500 на UserVoice) у версії 4.6.2 з коду BCL вирізали перевірки обмеження довжини шляху, віддавши це на відкуп операційній і файлової систем!
Ось що це дає:
Як увімкнути:
- Використовувати .Net Framework 4.6.2 як мета при складанні програми.
- Використовувати конфігураційний файл, наприклад, якщо програма вже було зібрано під .Net 4.0:
<? Xml version = "1.0" encoding = "utf-8"?> <Configuration> <startup> <supportedRuntime version = "v4.0" sku = ". NETFramework, Version = v4.0" /> </ startup> <runtime> <AppContextSwitchOverrides value = "Switch.System.IO.UseLegacyPathHandling = false; Switch.System.IO.BlockLongPaths = false" /> </ runtime> </ configuration>
.Net Core
Тут підтримку довгих шляхів анонсували ще в листопаді 2015 року. Мабуть позначилося Open Source природа проекту і відсутність суворої необхідності забезпечення зворотної сумісності.
Як увімкнути:
Все працює з коробки. На відміну від реалізації в .Net Framework - тут немає необхідності в додаванні префікса "\\? \" - він додається автоматично при необхідності.
ось тут можна подивитися приклад.
Як включити підтримку довгих шляхів в Windows 10 (1607)
Ця можливість за замовчуванням відключена. Це пояснюється тим, що дана функція є експериментальною, і є необхідність допрацьовувати різні підсистеми і додатки для повної підтримки.
Включити вбудовану підтримку довгих шляхів можна створивши або змінивши наступний параметр системного реєстру: HKLM \ SYSTEM \ CurrentControlSet \ Control \ FileSystem Параметр LongPathsEnabled (Тип: REG_DWORD) 1 - відповідає значенню включено.
Або через групові політики (Win + R \ gpedit.msc) Computer Configuration> Administrative Templates> System> Filesystem> Enable NTFS long paths. Воно ж в локалізованому варіанті: Конфігурація комп'ютера> Адміністративні шаблони> Система> Файлова система> Включити довгі шляхи Win32.
Далі джерела розходяться в думці щодо маніфесту (або я неправильно зрозумів, але на даний момент перевірити не маю можливості). Наприклад, в документації MSDN написано, що маніфест можна використовувати в якості альтернативного способу активації підтримки довгих шляхів в окремих додатках, а в блозі MSDN вказано, що це є другим обов'язковим кроком після активації в політиках.
Але вони сходяться в форматі завдання даної опції:
<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>
З CMD, на жаль, це не спрацює, на даний момент, через особливості роботи з шляхами, а в PowerShell має все заробити.
PS
На цьому мій невеличкий п'ятничний піст закінчується, залишивши за рамками питання повноти реалізації підтримки довгих шляхів в Windows 10 (1607), або працездатність при використанні різних комбінацій редакцій Windows, файлових систем і API. У міру надходження нових фактів і результатів експериментів пост буде оновлюватися.
Дякую за увагу!Це позбавляє від необхідності використовувати префікса \\?
Lt;?
Quot; encoding = "utf-8"?
Net Framework - тут немає необхідності в додаванні префікса "\\?