количество символов в пути к файлу windows
Мир цифровой информации
Если вам кажется, что нет ничего проще, чем придумать имя для файла или папки, то скорее всего вы ошибаетесь. Существуют правила из-за которых нельзя назвать файл любым именем как обычный физический предмет. Для начала проясним, что такое имя файла, и как оно используется.
Понятия «путь» и «имя файла»
Очень часто в компьютерной литературе используются термины «путь» и «имя файла» под разными значениями. Обычно под словом «путь» понимают адрес или расположение файла, т. е. диск, папка и подпапки в которых расположен файл. Однако Microsoft и другие считают, что в путь к файлу входит не только его расположение но и само имя файла. А некоторые подразумевают под словом «путь» только имена файла и папок, в которых он расположен, без указания диска. Некоторые пользователи полагают, что «имя файла» не включает расширение. В данной статье расширение всегда является частью имени файла. На примере ниже синим цветом выделен путь к файлу, а красным имя файла.
X:\папка\подпапка\ файл.расширение
Зарезервированные символы и имена
Ограничения на длины имен файлов и путей
Существуют ограничения на длину имени файла и на длину пути. Абсолютное ограничение длины имени файла вместе включая путь к нему равно 260 символам. Этот предел называют термином MAX_PATH. На самом же деле на практике пределы для имен еще меньше из-за ряда других ограничений. Например, каждая строка на конце должна содержать так называемый нулевой символ, который обозначает конец строки. Несмотря на то, что маркер конца строки не отображается, он учитывается как отдельный символ при подсчете длины, а значит остается 259 символов доступных для имени файла и пути к нему. Первые три символа в пути используются для обозначения диска (например, C:\). Это уменьшает предел для имен папок, подпапок и файла до 256 символов.
На имя объекта (папки или файла) наложено ограничение длины 255 символов. Этот предел действителен только, если объект не расположен внутри папки. Так как при расположении объекта внутри папки, сумма длин всех папок в которых он расположен, разделителей и имени объекта ограничена 256 символами, то предел длины самого имени объекта меньше 255 символов.
Microsoft убрала лимит на 260 символов в пути к файлам NTFS-систем
Максимальная длина пути к файлу или папке в NTFS-системе ограничен 260 символами, но с недавним обновлением Windows 10 Insider Preivew, Microsoft дает пользователям возможность увеличить данное ограничение. Для применения данных изменений пользователь должен проделать некоторые исправления в групповой политике Windows. Для этого надо нажать Win + R, ввести gpedit.msc, а затем перейти по пути «Конфигурация компьютера – Административные шаблоны – Система – Файловая система– NTFS». После этого нажмите “Включение длинных путей NTFS”. После этого вы сможете использовать в пути к файлу больше 260 символов.
Автор поста
Рекомендуем посмотреть
Комментарии (38)
я вот, например, не знал
Это баг на двухсимочных девайсах.Жди новую сборку 
Почему у меня работает, после последней сборки только раз не срабатывало переключения передача данных-wifi и обратно. Вынул симку воткнул и опять пашет.
У всех по разному ведёт себя сборка.
Та вот повезло что-ли. Сижу щёлкаю туда-сюда, чтоб не быть голословным. Нормалёк, не сглазить.
Так у тебя одна сим карта установленна?
Подтверждаю. Есть такой баг, и исправить никакими способами нельзя.
Во вторник должна новая сборка выйти на редстоун чего там будет нового?
Что все спите что-ли.
Не спим мы, просто умираем.
Норм. Удобно, может быть.
Круто. У то нас на работе один чувак любит создавать тысячу папок в папках с именами поэмы и сохранить на рабочем столе
хах, бывают же такие люди))
Ага? Он один раз звонит, говорит что сохранил папку на рабочем столе, а ее нет. Прихожу. действительно нет, потому что координаты рабочего стола уже не вмещают больше ничего)))))
Опять же, кто этими прогами гонять будет? Она? Тогда читайте мой соседний коммент, который адресован товарищу ilyadiv)
Можно расположение рабочего стола на диске д сделать
Можно и ярлык на папку создать на рабочем столе, чтоб сама папка располагалась на диске отличном от С, можно вообще все перелопатить до неузнаваемости, вот только кто это будет делать? Сестра, у которой в глазах отчетливо видно заднюю стенку черепа? Не осилит. Я? Да нафиг оно мне уперлось, задолбал уже этот неблагодарный труд)
Она НЕ О СИ ЛИТ) Понимаешь?) Я просто забил на это болт)
Это точно труд более чем неблагодарный! Идешь в компанию побухать и тут обязательно кто нибудь вспомнит про свой тормозящий ноут или смарт на ведре
Про крузока на лысой резине это в точку. Да и в принципе все в точку. Плюсую?
Я таких чудиков полно лицезрею) я вот не вы*бываясь купил себе хюндай скромный, и на бензин хватает и на прочее, и не перед кем не понтуюсь, нафиг оно нужно)
ReFS проект закрыли?
Теперь можно назвать файл +100500 символов
Точно, любители папок обрадуются?
На работе до внедрения эдо такая проблема была
Это из-за этой фигни я не могу удалить 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 элемент.
Именование файлов, путей и пространств имен
все файловые системы, поддерживаемые 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».
Выбираем длинный путь (или прощай 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. По мере поступления новых фактов и результатов экспериментов пост будет обновляться.