Максимально возможная длина имени файла в ядре Windows

Мне было интересно, какая самая длинная длина имени разрешена ядром Windows?

Например: я знаю, что ядро ​​использует структуры UNICODE_STRING для хранения всех путей к объектам, и поскольку длина байта строки широких символов хранится внутри USHORT, это позволяет использовать максимальную длину пути 2 ^ 15-1 символов. Есть ли подобное жесткое ограничение на имя файла (а не путь)? (Меня не волнует, накладывает ли NTFS или FAT32 конкретное ограничение; я ищу максимально возможное теоретически допустимое имя в ядре, при условии отсутствия дополнительных ограничений файловой системы или оболочки.)

(Изменить: для тех, кто задается вопросом, почему это вообще имеет значение, учтите, что обычно перемещение по каталогу достигается с помощью _3 _ / _ 4_ вызовов, по одному вызову на файл. Учитывая функцию с именем NtQueryDirectoryFile, которая является базовым системным вызовом и которая возвращает несколько имена файлов для каждого вызова, на самом деле можно воспользоваться этим ограничением максимальной длины на пути, чтобы сделать чрезвычайно быстрый обход каталога, который использует только стек в качестве буфера. Теперь я пытаюсь расширить эту концепцию , и мне нужно знать максимальный размер имени файла.)


person user541686    schedule 07.01.2011    source источник
comment
Когда вы говорите USHORT, а затем 2 ^ 31, что вы имеете в виду? Если он беззнаковый, то это будет 2 ^ 32, но ushort хранит только до 2 ^ 16 (это 16 бит). Я где-то неправильно понял ваш смысл?   -  person James    schedule 07.01.2011
comment
Извините, это была опечатка; Я имел ввиду 2 ^ 15 - 1. Поменял, спасибо.   -  person user541686    schedule 07.01.2011
comment
И я забыл принять во внимание, что каждому персонажу требуется 2 байта памяти, что вдвое сокращает объем получаемого пространства ... В любом случае, я предполагаю, что такое ограничение в ядре будет плохо документировано и варьируется от XP до Vista / Win7 . Надеюсь, кто-то может вам помочь, +1   -  person James    schedule 07.01.2011
comment
Достаточно ли быстродействующий ваш метод, чтобы иметь какое-либо существенное значение? Если есть какое-то внутреннее ограничение, что может помешать Microsoft изменить его в будущем? Насколько мне известно, компоненты пути ограничены только базовой файловой системой; Я сомневаюсь, что в обозримом будущем он когда-либо превысит 255 (в основном для целей обратной совместимости).   -  person Luke    schedule 07.01.2011
comment
Да, он проходит через весь мой диск C: (на котором установлена ​​Windows 7, всего около 400 000 файлов) менее чем за четыре секунды, если все данные для чтения кэшированы в системной памяти. Как только я переключаюсь на использование malloc () вместо стековой памяти, затрачиваемое время удваивается, а иногда и больше. И я заметил, что он, вероятно, на один или два порядка быстрее, чем Explorer, когда ищет файлы. Если интересно, могу выложить код где-нибудь, хотя он написан на D.   -  person user541686    schedule 07.01.2011


Ответы (2)


Максимальная длина пути составляет 32 767 символов, при этом каждый компонент пути (каталог или файл) может иметь максимальную длину 255 символов (точнее, значение, возвращаемое в параметре lpMaximumComponentLength функции GetVolumeInformation).

Это задокументировано в MSDN .

person Helge Klein    schedule 07.01.2011
comment
+1, Спасибо за ссылку, пригодится. Но я ищу абсолютный максимум времени компиляции, а на странице указано, что 255 обычно является максимумом. Итак, мой вопрос, есть ли какой-нибудь абсолютный верхний барьер, кроме 32K? - person user541686; 07.01.2011
comment
(К сожалению, забыл поставить +1; исправлено.) :) - person user541686; 07.01.2011
comment
Думаю, я просто приму это, потому что не думаю, что есть лучший ответ. Спасибо. :) - person user541686; 21.01.2011

А, я сам нашел эту страницу, которая гарантирует это имя файла не может быть длиннее 255 символов:

  • Имя пути ДОЛЖНО быть не более 32 760 символов.
    ...
  • Длина каждого компонента имени пути ДОЛЖНА быть не более 255 символов.

Что заставляет задуматься:

Почему Windows использует ULONGs для длины имени файла , когда использует USHORTs для путь длины?!

Если кто знает, почему это так, напишите / прокомментируйте! Мне довольно любопытно. :)

person user541686    schedule 25.08.2011
comment
ULONG, вероятно, используются для поддержания согласованности с другими полями в записях заголовков справочной информации. Предел USHORT для UNICODE_STRING - это реальный предел. Использование USHORT в информационном заголовке потребует либо значения заполнения, либо приведет к нарушению выравнивания остальной структуры. Обратите внимание, что каждая запись заголовка должна быть выровнена по 8 байтов. - person Chris Smith; 18.10.2011