максимальный путь к файлу windows

Ограничение максимальной длины пути

в Windows API (с некоторыми исключениями, обсуждаемыми в следующих параграфах) максимальная длина пути — это максимальный _ путь, который определен как 260 символов. Локальный путь структурирован в следующем порядке: буква диска, двоеточие, обратная косая черта, имена компонентов, разделенные обратной косой чертой, и завершающий нуль-символ. Например, максимальный путь на диске D — это «D: \ часть 256-символьного пути «, где » » представляет невидимый завершающий нуль-символ для текущей системной кодовой страницы. (Символы используются для наглядности и не могут быть частью допустимой строки пути.)

Например, это ограничение может быть достигнуто при клонировании репозитория Git с длинными именами файлов в папку с длинным именем.

функции файлового ввода-вывода в Windows API преобразуют «/» в » \ » в процессе преобразования имени в имя в формате NT, за исключением случаев использования \ \ префикса «? \ «, как описано в следующих разделах.

нет необходимости выполнять нормализацию юникода в строках пути и имени файла для использования в Windows функциях API-интерфейса файлового ввода/вывода, так как файловая система обрабатывает путь и имена файлов как непрозрачную последовательность WCHAR. любые нормализации, необходимые приложению, должны выполняться с учетом того, что внешние вызовы связанных функций API-интерфейса Windows файлового ввода/вывода.

При использовании API для создания каталога указанный путь не может быть настолько длинным, что нельзя добавить имя файла 8,3 (т. е. имя каталога не может превышать максимальный _ путь минус 12).

Оболочка и файловая система имеют разные требования. можно создать путь с Windows API, который пользовательский интерфейс оболочки не может интерпретировать правильно.

включение длинных путей в Windows 10, версии 1607 и более поздних

Windows 10 начиная с версии 1607, ограничения по максимальному _ пути были удалены из общих функций файлов и каталогов Win32. Однако необходимо явно принять участие в новом поведении.

Чтобы обеспечить новое поведение при полном пути, должны выполняться оба следующих условия.

Манифест приложения также должен содержать longPathAware элемент.

Источник

Выбираем длинный путь (или прощай MAX_PATH)

Многим пользователям ПК под управлением ОС Windows, не говоря о разработчиках, знакомы проблемы при работе с длинными (более 260 символов, MAX_PATH) путями файлов или каталогов.

Приложения Win API

В приложениях, которые используют Win API для работы с файлами, рецепт избавления от ограничения MAX_PATH был известен с незапамятных времён – необходимо было использовать Unicode версию функции с окончанием «W» для работы с директорией или файлом и начинать путь с префикса \\?\. Это давало возможность использовать пути длинной до 32767 символов.

В Windows 10 (1607) поведение функций для работы с файлами изменилось: появилась возможность отключить проверку ограничений MAX_PATH на уровне системы.

Это избавляет от необходимости использовать префикса \\?\ и потенциально даёт шанс приложениям, работающим напрямую или косвенно через Win API, получить поддержку длинных путей без необходимости их пересборки. Как активировать эту возможность описано в конце статьи.

.Net Framework

.Net Core

Тут поддержку длинных путей анонсировали ещё в ноябре 2015 года. Видимо сказалось Open Source природа проекта и отсутствие строгой необходимости обеспечения обратной совместимости.

Вот тут можно посмотреть пример.

Как включить поддержку длинных путей в 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 указано, что это является вторым обязательным шагом после активации в политиках.
Но они сходятся в формате задания данной опции:

С CMD, к сожалению, это не сработает, на данный момент, из-за особенностей работы с путями, а в PowerShell должно всё заработать.

На этом мой небольшой пятничный пост заканчивается, оставив за рамками вопросы полноты реализации поддержки длинных путей в Windows 10 (1607), или работоспособность при использовании различных комбинаций редакций Windows, файловых систем и API. По мере поступления новых фактов и результатов экспериментов пост будет обновляться.

Источник

Максимальный путь к файлу windows

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Pyatilistnik.org. В прошлый раз мы с вами разобрали возможности утилиты PING, рассмотрели как ее применять на практике. В сегодняшней публикации я вам покажу, как устраняется боль и печаль в операционных системах Windows, я говорю про длинные пути, в своей практике я очень часто встречал жалобы «Слишком длинный целевой путь» или «Слишком длинный конечный путь«, то же самое вы можете встретить и при удалении. Ниже я покажу, как выкручиваться из данной ситуации.

Описание проблемы длинных путей

Тем не менее, файловая система Windows по-прежнему накладывает некоторые ограничения, например, какие символы могут использоваться в именах файлов и общую длину путей. Некоторое время максимальная длина пути составляла 260 символов, но с появлением Windows 10, часть ограничений начала потихоньку уходить, например для приложений и появилась возможность отключить проверку MAX_PATH и использовать длинные пути без префикса \\?\.

Что интересно, значение в 260 символов обусловлено значением MAX_PATH Win32 API. У файловой системы NTFS максимальная длина пути ″немного″ больше и составляет 32767 символа. Для обхода ограничений Win32 API некоторые приложения используют формат UNC, указывая абсолютный путь с префиксом \\?\, например так:

Большинство людей может и не столкнуться с ней, а вот почти каждый системный администратор обязательно это увидит. Тут все дело в том, что в большинстве организаций есть свои сетевые файловые ресурсы, через которые пользователи производят обмен и работу с документами. В какой-то момент люди могут создать такой путь, который будет 258 или 260 символов, попытаются туда скопировать файл, а им выдастся ошибка:

Тоже самое при копировании в папку, так же выскакивает «Слишком длинный целевой путь».

Вот ошибка при извлечении архива в сетевую папку:

Методы снимающие ограничения на длину пути в Windows

Нюансы длинных путей в приложениях

Есть один нюанс. Этот новый параметр (имеется ввиду та политика и ключ реестра) не обязательно будет работать со всеми существующими приложениями, но он будет работать с большинством. В частности, любые современные приложения должны работать нормально, как и все 64-битные приложения. Старые 32-разрядные приложения должны быть применимы для работы, что на самом деле просто означает, что разработчик указал в файле манифеста приложения, что приложение поддерживает более длинные пути. Большинство популярных 32-битных приложений не должно вызывать проблем. Тем не менее, вы ничем не рискуете, пробуя настройку. Если приложение не работает, единственное, что произойдет, это то, что оно не сможет открывать или сохранять файлы, сохраненные в местах, где полный путь превышает 260 символов.

Если вы разработчик, то чтобы ваше приложение имело возможность работать с длинными путями Windows, в манифесте обязательно указывайте следующие настройки:

Как в Windows 10 отключить ограничение на длину пути в 260 символов через политику

Чем примечателен данный метод, так это тем, что неподготовленных пользователей он не вынуждает выполнять команды или производить правку реестра, тут все в графическом виде. Так же если у вас есть домен Active Directory и вы хотите массово убрать ошибки «Слишком длинный целевой путь» или «Слишком длинный конечный путь» в приложениях и запретить им проверять MAX_PATH и использовать длинные пути без префикса \\?\, то групповые политики вам это помогут.

Покажу для начала, как делать через локальную политику, открываете окно «Выполнить» в котором пишите gpedit.msc.

Далее идем по пути:

Найдите тут параметр «Включить длинные пути Win32 (Enable Win32 long paths)«, по умолчанию он отключен, и я честно не понимаю почему. Активируйте его.

Как я писал выше, в проводнике это не даст ни каких эффектов, поэтому вы все так же будите получать ошибку при копировании, создании, удалении «Слишком длинный целевой путь» или «Слишком длинный конечный путь«. Ниже я покажу, что делать если нужно что-то там удалить или изменить. Данное ограничение в длине пути теперь не подхватиться на лету всеми приложениями, потребуется перезагрузка.

Включение поддержки длинных путей через реестр

Данный метод ни чуть не сложнее предыдущего и делает все то же самое, включает поддержку длинных путей свыше 256 символов для приложений Windows. Когда вы что-то меняете через редактор политик, по сути меняются настройки в реестре, это нужно помнить и знать. Сейчас я вам покажу какой ключ меняется. Откройте редактор реестра Windows. Перейдите в раздел:

тут вам необходимо найти параметр LongPathEnabled, которому для активации поддержки длинных путей и изменения ограничений в MAX_PATH, нужно задать значение «1». Тут потребуется перезагрузка.

Все что вам нужно, это распаковать zip-архив и запустить нужный файл активации, потом так же перезагрузиться, так как у вас будет создан нужный ключ реестра, без необходимости лезть в реестр самостоятельно.

Еще вы можете сделать такую поддержку и для конкретного пользователя по пути:

Если там нет ключа LongPathsEnabled, то создайте его, тип DWORD (32 бита) и значение 1.

Как в Windows 10 отключить ограничение на длину пути в 260 символов через PowerShell

Не все люди готовы копаться в редакторах и реестрах, им нужно быстрое решение, одним из таких является PowerShell. В оболочке выполните команду для активации параметра «Включить длинные пути Win32 (LongPathEnabled)». Не забываем перезагрузить систему.

Как удалять, копировать, переносить файлы и папки при ошибке с длинными путями

Разобравшись с тем, как отключить проверку MAX_PATH в приложениях, давайте теперь поймем и научимся решать проблему длинных путей на файловых шарах и просто в проводнике. Классическая ситуация, когда пользователь попытался перенести свой файл или удалить его, создать папку и так далее, и он получает ошибку с пресловутыми длинными путями. Он просит разобраться вас и тут начинаются танцы с бубнами, вы просите его либо переименовать часть пути, или попросить его произвести действия в другом расположении, или просто забить, сказав, что виновата Windows со своими ограничениями, но мы же с вами профессионалы и инженеры, поэтому должны уметь выходить из таких ситуаций.

Как в Windows 10 отключить ограничение на длину пути в 260 символов через командную строку

Запустите командную строку в режиме администратора и введите:

Обход ограничений длинных путей через 7zFM

Наверняка многие знают архиватор 7Zip, но мало кто пользуется его файловым менеджером 7zFM.exe, а зря именно он может вам помочь в ситуации с сообщением «Слишком длинный целевой путь» или «Слишком длинный конечный путь». Вот у меня есть тестовая директория, у которой уже есть 260 символов в пути, и я не могу там создавать новую папку.

Откройте 7zFM.exe и перейдите в нем в конечную папку вашего пути.

Для создания новой папки нажмите клавишу F7.

Задайте необходимое вам имя, в моем примере это будет «БОльше 260 Microsot«.

В результате у нас создалась новая папка и заметьте 7zFM не ругнулся на наличие длинных путей, он их игнорирует просто и все.

Проверяем, что директория доступна через проводник Windows.

Все прекрасно отображается. Теперь я думаю вы легко сможете переносить, копировать, удалять файлы через 7zFM, когда вам проводник Windows ругается на наличие длинных путей.

Как обойти ограничение длинных путей через символьную ссылку

Такой трюк мы с вами уже проделывали, когда нужно было переносить IMAP профиль у Outlook. Смысл в том, что создается файл в нужном вам месте, и этот файл это просто ярлык ссылающийся на нужный вам файл или папку, после этого путь сокращается и вы можете удалять или создавать все что вам нужно. Откройте командную строку, далее вам нужно иметь два составляющих:

Нам поможет команда mklink, где ключ /D создает ссылку на каталог

Источник

Именование файлов, путей и пространств имен

все файловые системы, поддерживаемые Windows, используют концепцию файлов и каталогов для доступа к данным, хранящимся на диске или устройстве. Windows разработчики, работающие с Windowsными api-интерфейсами для файлов и устройств, должны понимать различные правила, соглашения и ограничения имен файлов и каталогов.

Доступ к данным можно получить с дисков, устройств и сетевых ресурсов с помощью API файлового ввода-вывода. Файлы и каталоги вместе с пространствами имен являются частью концепции пути, которая представляет собой строковое представление места получения данных независимо от диска, устройства или сетевого подключения для конкретной операции.

Некоторые файловые системы, такие как NTFS, поддерживают связанные файлы и каталоги, которые также следуют соглашениям об именовании файлов и правилам, как обычный файл или каталог. Дополнительные сведения см. в разделах жесткие связи, соединения и точки повторного анализа и операции с файлами.

Дополнительные сведения см. в следующих подразделах:

дополнительные сведения о настройке Windows 10 для поддержки длинных путей к файлам см. в разделе ограничение максимальной длины пути.

Имена файлов и каталогов

Ограничения количества символов также могут быть разными и могут различаться в зависимости от используемого формата префикса файловой системы и имени пути. Это усложняется за счет поддержки механизмов обратной совместимости. Например, более старая файловая система MS-DOS FAT поддерживает не более 8 символов для базового имени файла и 3 символа для расширения, а всего 12 символов, включая разделитель точек. Обычно это называется именем файла 8,3. Windows файловые системы FAT и NTFS не ограничиваются 8,3 именами файлов, так как они имеют длинную поддержку имен файлов, но по-прежнему поддерживают версию 8,3 длинных имен файлов.

Соглашения об именах

Следующие фундаментальные правила позволяют приложениям создавать и обрабатывать допустимые имена файлов и каталогов независимо от файловой системы.

Используйте точку, чтобы отделить базовое имя файла от расширения в имени каталога или файла.

Используйте обратную косую черту ( \ ) для разделения компонентов пути. Обратная косая черта разделяет имя файла от пути к нему и одно имя каталога из другого имени каталога в пути. Нельзя использовать обратную косую черту в имени для фактического файла или каталога, так как это зарезервированный символ, разделяющий имена в компоненты.

Не думайте о чувствительности к регистру. Например, имена OSCAR, OSCAR и OSCAR должны быть одинаковыми, даже если некоторые файловые системы (такие как POSIX-совместимая файловая система) могут считать их разными. Обратите внимание, что NTFS поддерживает семантику POSIX для чувствительности к регистру, но это не поведение по умолчанию. Дополнительные сведения см. в разделе CreateFile.

Обозначения томов (буквы диска) не учитывают регистр. Например, «D: \ » и «d: \ » ссылаются на один и тот же том.

Используйте любой символ в текущей кодовой странице для имени, включая символы Юникода и символы в расширенном наборе символов (128 – 255), за исключением следующих:

Следующие зарезервированные символы:

Символы, целочисленное представление которых находится в диапазоне от 1 до 31, за исключением альтернативных потоков данных, в которых разрешены эти символы. дополнительные сведения о файловых потоках см. в разделе file Потоки.

Любой другой символ, который не разрешен целевой файловой системой.

Используйте точку в качестве компонента каталога в пути для представления текущего каталога, например. \temp.txt «. Дополнительные сведения см. в разделе paths.

Используйте две последовательные точки (..) как компонент каталога в пути, чтобы представить родителя текущего каталога, например. \temp.txt «. Дополнительные сведения см. в разделе paths.

Не используйте следующие зарезервированные имена для имени файла:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 и LPT9. Также Избегайте этих имен сразу после расширения; Например, не рекомендуется использовать NUL.txt. Дополнительные сведения см. в разделе Пространства имен.

Не завершайте имя файла или каталога с пробелом или точкой. хотя базовая файловая система может поддерживать такие имена, оболочка Windows и пользовательский интерфейс не поддерживаются. Однако можно указать точку в качестве первого символа имени. Например, «. temp».

Короткие и длинные имена

Длинное имя файла считается любым именем файла, которое превышает короткое соглашение об именовании в стиле MS-DOS (также называемое 8,3). при создании длинного имени файла Windows также может создать короткую форму 8,3 имени, именуемую псевдонимом 8,3 или коротким именем, а также сохранить ее на диске. Это 8,3 может быть отключено для повышения производительности в зависимости от конкретной файловой системы.

Windows server 2008, Windows Vista, Windows Server 2003 и Windows XP: 8,3 псевдонимы не могут быть отключены для указанных томов до Windows 7 и Windows Server 2008 R2.

Во многих файловых системах имя файла будет содержать символ тильды (

) в каждом компоненте имени, которое слишком длинное для соответствия правилам именования 8,3.

Не все файловые системы следуют соглашению о подстановке тильды, и системы могут быть настроены на отключение создания псевдонима 8,3, даже если они обычно поддерживаются. Поэтому не следует предполагать, что псевдоним 8,3 уже существует на диске.

Чтобы запросить 8,3 имен файлов, длинных имен файлов или полного пути к файлу из системы, рассмотрите следующие варианты.

в новых файловых системах, таких как NTFS, exFAT, udf и FAT32, Windows сохраняет длинные имена файлов на диске в юникоде, что означает, что исходное имя длинного файла всегда сохраняется. Это справедливо даже в том случае, если длинное имя файла содержит символы национальных алфавитов, независимо от того, какая кодовая страница активна во время операции чтения или записи с диска.

файлы, использующие длинные имена файлов, можно скопировать между разделами файловой системы NTFS и Windows разделами файловой системы FAT без потери сведений об имени файла. Это может быть неверно для старых файлов MS-DOS FAT и некоторых типов файловых систем CDFS (CD-ROM) в зависимости от фактического имени файла. В этом случае короткое имя файла подставляется по возможности.

Если компонент пути является именем файла, то он должен быть последним компонентом.

Каждый компонент пути также будет ограничен максимальной длиной, указанной для конкретной файловой системы. Как правило, эти правила делятся на две категории: Short и Long. Обратите внимание, что имена каталогов хранятся в файловой системе как файлы особого типа, но правила именования для файлов также применяются к именам каталогов. Для суммирования путь — это просто строковое представление иерархии между всеми каталогами, которые существуют для определенного имени файла или каталога.

Полные и относительные пути

для функций API Windows, которые управляют файлами, имена файлов часто могут относиться к текущему каталогу, в то время как некоторым api требуется полный путь. Имя файла задается относительно текущего каталога, если он не начинается с одного из следующих:

Если имя файла начинается только с обозначения диска, но не с обратной косой черты после двоеточия, то оно интерпретируется как относительный путь к текущему каталогу на диске с указанной буквой. Обратите внимание, что текущий каталог может быть или не являться корневым каталогом, в зависимости от того, на что он был установлен во время последней операции «изменение каталога» на этом диске. Ниже приведены примеры этого формата.

Путь также считается относительным, если он содержит «двойные точки»; то есть две точки вместе находятся в одном компоненте пути. Этот Специальный описатель используется для обозначения каталога над текущим каталогом, в противном случае известный как «родительский каталог». Ниже приведены примеры этого формата.

Относительные пути могут сочетать оба типа примеров, например «К. \tmp.txt «. Это полезно, поскольку, несмотря на то, что система отслеживает текущий диск вместе с текущим каталогом этого диска, она также следит за текущими каталогами на разных буквах диска (если в системе несколько), независимо от того, какой из обозначений установлен в качестве текущего диска.

Ограничение максимальной длины пути

Пространства имен

существует две основные категории соглашений о пространствах имен, используемых в Windows api, которые обычно называются пространствами имен NT и пространствами имен Win32. Пространство имен NT было разработано как пространство имен самого низкого уровня, в котором могут существовать другие подсистемы и пространства имен, включая подсистему Win32 и, по расширениям, пространства имен Win32. POSIX — это еще один пример подсистемы в Windows, построенной на основе пространства имен NT. ранние версии Windows также определили несколько предопределенных или зарезервированных имен для определенных специальных устройств, таких как порты связи (последовательные и параллельные) и консоль экрана по умолчанию, как часть того, что теперь называется пространством имен устройств NT, и все еще поддерживаются в текущих версиях Windows для обеспечения обратной совместимости.

Пространства имен файлов Win32

Префиксы и соглашения пространств имен Win32 приведены в этом разделе и в следующем разделе с описанием того, как они используются. обратите внимание, что эти примеры предназначены для использования с функциями API Windows и не всегда работают с приложениями оболочки Windows, такими как Windows Explorer. по этой причине существует более широкий диапазон возможных путей, чем обычно доступно в Windows приложениях оболочки, а Windows приложения, использующие его, можно разрабатывать с помощью этих соглашений по пространству имен.

Так как он отключает автоматическое расширение строки пути, \ \ префикс «? \ » также позволяет использовать «..» и «.» в именах путей, которые могут быть полезны при попытке выполнить операции с файлом, в противном случае зарезервированные описатели относительных путей в составе полного пути.

Обратите внимание, что для префикса «?» можно использовать только API-интерфейсы Юникод, что \ \ \ позволяет превысить максимальный _ путь

Пространства имен устройств Win32

при работе с функциями API Windows следует использовать \ \ префикс «. \ » для доступа только к устройствам, а не файлам.

Пространства имен NT

чтобы сделать эти объекты устройств доступными для приложений Windows, драйверы устройств создают символьную ссылку (символьную ссылку) в пространстве имен Win32 «Global??» для соответствующих объектов устройств. Например, COM0 и COM1 в разделе «Global??» подкаталог — это просто символических ссылок Serial0 и Serial1, «C:» — это символьную ссылку до HarddiskVolume1, «отображается physicaldrive0» — символьную ссылку до DR0 и т. д. без символьную ссылку указанное устройство «Xxx» будет недоступно для любого Windows приложения, использующего соглашения о пространстве имен Win32, как описано выше. Однако для этого устройства можно открыть маркер, используя любые интерфейсы API, поддерживающие абсолютный путь к пространству имен NT формата » \ устройство \ xxx».

Источник