Максимальная длина имени файла в NTFS (Windows XP и Windows Vista)?
Я разрабатываю таблицу базы данных, в которой будут храниться имена загруженных файлов. Какова максимальная длина имени файла в NTFS в Windows XP или Vista?
его 255, я знаю это, поскольку мне пришлось создать приложение, чтобы корпоративные пользователи не могли этого достичь, поскольку это вызывает проблемы на наших серверах хранения.
@ Роберт Питт. Вам что-то там не хватает. Цитата из MSDN: «максимальная длина пути составляет MAX_PATH, что составляет 260 символов».
@ Michael9000. Я считаю, что Роберт Питт цитировал ограничение имени файла (об этом вопрос), а не ограничение пути.
подождите, это вопрос: «максимальное имя файла» или «максимальный полный путь» (состоящий из нескольких имен файлов / имен каталогов)?
NTFS вообще НЕ ограничена MAX_PATH, оболочка Windows ограничена MAX_PATH, максимальная длина пути NTFS составляет 32 КБ
К вашему сведению: MAX_PATH определен в minwindef.h для тех, кто его ищет. Кроме того, здесь есть другие полезные макросы.
@paulm: на самом деле я был бы удивлен, если бы это было ограничение NTFS. Однако некоторые ограничения в режиме ядра требуют ограничения примерно до 32 КБ элементов WCHAR. А именно UNICODE_STRING является проблемой.
@rogerdpack похоже, что многие из ответивших попали именно в эту ловушку.
Ответы 14
255 символов.
Отдельные компоненты имени файла (т.е. каждый подкаталог по пути и окончательное имя файла) ограничены 255 символами, а общая длина пути ограничена приблизительно 32 000 символов.
However, on Windows, you can't exceed MAX_PATH value (259 characters for files, 248 for folders). See http://msdn.microsoft.com/en-us/library/aa365247.aspx для получения полной информации.
Вот еще несколько фактов, подтверждающих этот ответ (Windows обычно ограничивается 260 символами): msdn.microsoft.com/en-us/library/… и blogs.msdn.com/b/bclteam/archive/2007/02/13/…
Правильно для NTFS, а не для Windows, согласно предоставленной вами ссылке: «В Windows API (с некоторыми исключениями, обсуждаемыми в следующих параграфах) максимальная длина пути составляет MAX_PATH, что определяется как 260 символов». Путь общее для всех практических целей ограничен 259 символами (с учетом нулевого символа конца).
По-видимому, если вы используете "юникодную версию" файловых методов Windows API, вы можете получить до 32767, если вы префикс пути с помощью "\\? \", Верно?
@rogerdpack: для полного пути - да, но каждый отдельный компонент (подпапка / конечный файл) имеет ограничение в 255 кодовых точек utf-16. Плюс нормальный софт ожидает MAX_PATH, так что ... бум :)
"приблизительно 32 000 символов", вероятно, составляет 32768 символов, потому что на компьютерах числа обычно являются степенью 2 и 2 ^ 15 = 32768.
В Windows 10 (версия 1607 - юбилейное обновление) и Windows Server 2016 у вас есть возможность игнорировать проблему MAX_PATH, переопределив запись групповой политики, включив длинные пути NTFS в разделе Конфигурация компьютера -> Шаблоны администратора -> Система -> Файловая система:
С 260 все должно быть в порядке: msdn.microsoft.com/en-us/library/windows/desktop/…
Проголосовали против абсолютно сомнительной рекомендации оставаться ниже MAX_PATH ... Мы уже не в 1980-х!
@DonaldDuck: и ты ошибаешься насчет этого. Теоретический максимум составляет 65535 Байты, потому что именно так UNICODE_STRING считает размер буфера. Но поскольку мы должны разделить это на sizeof(WCHAR), мы получаем 32767 (Length всегда четный в UNICODE_STRING). И даже это приблизительное значение по-прежнему *, потому что внутреннее имя подсистемы Win32, также известное как имя DOS, расширяется. Так что вместо C: у вас может быть \Device\HarddiskVolume11. Так что это расширение буквально уменьшает размер, вы можете использовать из подсистему Win32.
К сожалению, люди до сих пор используют старые серверы, потому что ИТ не должны ничего стоить. @ 0xC0000022L. Фактически корпорации относятся к 80-м годам.
@ Драгас, я знаю это чувство. В любом случае, первая выпущенная NT уже имела ограничение около 65 Кбайт. Чего не хватало, так это значимой поддержки в подсистеме Win32. Потребовались дополнительные усилия, чтобы заставить вашу программу использовать полную длину пути, тогда как MAX_PATH был простым способом ...
Согласно MSDN, это 260 символов. Он включает в себя "<NUL>" - невидимый завершающий нулевой символ, поэтому фактическая длина составляет 259.
Но прочтите статью, все немного сложнее.
Фактически, в упомянутой статье MSDN говорится, что путь ограничен 260 символами, но длина имя файла зависит от файловой системы (но обычно 255 байтов). Однако можно использовать «версии Unicode [функций Windows API]» для увеличения ограничения пути до 32767 байт, но этот предел уменьшается из-за того, что окна внутренне расширяют требуемый префикс \\?\ во время выполнения до некоторой неопределенной длины. После этого расширения путь не должен превышать 32767 байт.
255 символов, хотя полный путь тоже не должен быть длиннее. В Википедии есть хорошая таблица об этом: http://en.wikipedia.org/wiki/Filename.
Это 257 символов. Точнее: Сама NTFS требует максимальной длины файла в несколько тысяч символов (около 30 000 с чем-то). Однако Windows устанавливает максимальную длину в 260 для пути + имя файла. Папка диск + занимает не менее 3 символов, поэтому в итоге получается 257.
Неправильно - терминатор NUL является частью MAX_PATH, что оставляет вам максимальный путь в 256 символов (который вы не сможете создать из-за ограничения отдельных компонентов в 255).
"который вы не сможете создать из-за ограничения отдельных компонентов 255" Неправильно. Мы говорим здесь о максимальной длине пути, а не о максимальной длине отдельных компонентов пути. Более того, «При использовании API для создания каталога указанный путь не может быть настолько длинным, чтобы нельзя было добавить имя файла 8.3 (то есть имя каталога не может превышать MAX_PATH минус 12)».
Эта дискуссия возникает только потому, что низкоуровневый api позволяет создавать имена файлов с 256 символами, исходя из предположения, что 256 символов являются пустыми, но файл становится недоступным (скрытым) для собственных приложений, поэтому обычно бесполезен.
@LudovicKuty: на самом деле OP говорил об ограничении длина имени файла, а не длина пути (да, даже в исходной версии, я проверил). И он / она очень конкретно имел в виду ограничения NTFS, а не ограничения ОС, конкретной подсистемы, API или фреймворка.
@ 0xC0000022L Да, действительно. Я неправильно прочитал его в вопросе OP и сосредоточился на комментариях, в которых говорится о длине имени файла и длине пути.
199 на Windows XP NTFS, я только что проверил.
Это не теория, а просто примерка на моем ноутбуке. Могут быть смягчающие эффекты, но физически это не позволит мне увеличить их.
Интересно, есть ли какие-то другие ограничения, ограничивающие это? Попробуйте сами.
Подтвердил это на моей версии XP, какая боль
Я сделал то же самое на Windows XP, просто для смеха. Я достиг предела в 200 символов. Затем я просто создал файл с 255-кратным w, удалил его и создал папку с тем же именем в Windows 7 x64. Теперь вопрос в том, что здесь является ограничивающим фактором: версия NTFS, ОС или подсистема или Win32 API в XP?
Ограничение в 200 символов похоже в проводнике. Другие программы могут создавать более длинные имена файлов. Вероятно, это намеренное ограничение, чтобы спасти пользователя от самого себя. :-)
Фактически это 256, см. Сравнение функциональности файловой системы, ограничения.
Повторить пост на http://fixunix.com/microsoft-windows/30758-windows-xp-file-name-length-limit.html
"Assuming we're talking about NTFS and not FAT32, the "255 characters for path+file" is a limitation of Explorer, not the filesystem itself. NTFS supports paths up to 32,000 Unicode characters long, with each component up to 255 characters.
Explorer -and the Windows API- limits you to 260 characters for the path, which include drive letter, colon, separating slashes and a terminating null character. It's possible to read a longer path in Windows if you start it with a
\\"
Если вы прочтете вышеперечисленные сообщения, то увидите, что есть пятая вещь, в которой вы можете быть уверены: Найти хоть одного упрямого пользователя компьютера!
Нет - 255. Поле NameLength в атрибуте NTFS $ Filename представляет собой байт без смещения; это дает диапазон 0-255
Длина в NTFS составляет 255. Поле NameLength в атрибуте NTFS $Filename - это байт без смещения; это дает диапазон 0-255.
Имя файла iself может находиться в разных «пространствах имен». Пока есть: POSIX, WIN32, DOS и (WIN32DOS - когда имя файла может быть изначально именем DOS). (Поскольку строка имеет длину, она мог содержит \ 0, но это может привести к проблемам и не находится в пространствах имен выше.)
Таким образом, имя файла или каталога может содержать до 255 символов. При указании полного пути под Windows вам нужно префикс пути с помощью \\? \ (или используйте \\? \ UNC \ server \ share для путей UNC), чтобы пометить этот путь как расширенный (~ 32k символов). Если ваш путь длиннее, вам придется по ходу установить рабочий каталог (тьфу - побочные эффекты из-за настройки всего процесса).
Я добавляю это к утвержденному выше ответу.
Чтобы быть ясным, люди считают, что это 255–260 символов, потому что это все, что поддерживает проводник Windows. Это приведет к ошибке, если вы сделаете что-то вроде копирования файла с более длинными именами файлов. Однако программа может читать и записывать гораздо более длинные имена файлов (именно так вы добираетесь до длины, на которую в первую очередь жалуется Explorer). В подобных ситуациях Microsoft рекомендует открыть файл в исходной программе, которая его написала, и переименовать.
Я попытался сохранить файл в глубине иерархии папок, определенно превышающей 260+ символов из командной строки с помощью vim, но безуспешно.
@panny: поэтому авторы Vim не позаботились о реализации длинных имен путей. Виноваты не Windows и не подсистема Win32, и это не имеет ничего общего с ограничением длина имени файла для NTFS, о котором спрашивал OP.
Вот что говорит «Необработанное исключение» в framework 4.5 при попытке сохранить файл с длинным именем:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Согласно новой документации Windows SDK (8.0) кажется, что предоставляется новое ограничение пути. Есть новый набор функции обработки пути и определение PATHCCH_MAX_CCH, как показано ниже:
// max # of characters we support using the "\\?\" syntax
// (0x7FFF + 1 for NULL terminator)
#define PATHCCH_MAX_CCH 0x8000
Однако проводник Windows 8 (в моем случае Win8.1 Preview) не работает с этим ограничением и не принимает пути длиной более 259 символов.
238! Я проверил его под Win7 32 бит с помощью следующего сценария bat:
set "fname = "
for /l %%i in (1, 1, 27) do @call :setname
@echo %fname%
for /l %%i in (1, 1, 100) do @call :check
goto :EOF
:setname
set "fname=%fname%_123456789"
goto :EOF
:check
set "fname=%fname:~0,-1%"
@echo xx>%fname%
if not exist %fname% goto :eof
dir /b
pause
goto :EOF
Я проверил это под Windows 7 с помощью программы, которая правильно обрабатывает длинные пути. Каждый отдельный сегмент пути мог занимать 255 символов (я использовал w). И что теперь?
Я не могу создать файл с именем + точка + расширение в WS 2012 Explorer длиннее 224 символов. Не стреляйте в посыльного!
В CMD того же сервера я не могу создать имя символа длиннее 235:
The system cannot find the path specified.
Файл с именем из 224 символов, созданный в проводнике, не может быть открыт в Notepad ++ - вместо этого создается новый файл.
The system cannot find the path specified. - это не то же самое, что The specified path, file name, or both are too long.. Думаю, у тебя была опечатка или что-то в этом роде. Вы получите это сообщение, если попытаетесь создать файл по несуществующему пути или если хотите перейти в несуществующем направлении.
Эта часть официальной документации ясно говорит, что это 255 символов Unicode для NTFS, exFAT и FAT32 и 127 символов Unicode или 254 ASCII символа для UDF.
Кроме того, максимальная длина имени пути всегда составляет 32 760 символов Unicode, причем длина каждого компонента пути не превышает 255 символов.
Достаточно близко. Как я указываю в комментарии к принятому ответу, это 32767 элементов WCHAR. Нет, это нет «символы Unicode» (проверьте терминологию Unicode: кодовые точки, символы и т. д.!).
Я никогда не видел так много разных ответов на простой вопрос. 199, 255, 256, 257, 260, «около 30 000», «примерно 32 000» и «в зависимости от обстоятельств». Конечно, есть квалификаторы, но не все ли они могут быть правильными, не так ли?