MAX_PATH и подводные камни путей/имён файлов в Windows — лимит 260 символов, зарезервированные имена, конечная точка, регистр

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

Сложность этой области в том, что ограничения разбиты на несколько слоёв — «ограничение Win32 API», «ограничение файловой системы», «ограничение оболочки (Проводника)», «ограничение runtime .NET» — и не всегда понятно, что удастся обойти, а что останется проблемой. В этой статье разбираем, что на самом деле представляет собой MAX_PATH=260, при каких условиях можно легально работать с длинными путями, ловушки имён файлов вроде зарезервированных имён CON и конечных точек, а также обработку регистра — вместе с практическими решениями на C# для каждого случая.

1. Сначала вывод

• MAX_PATH=260 — это ограничение Win32 API, включающее букву диска, двоеточие, обратную косую черту, до 256 символов текста пути и завершающий NUL. Файловая система (например, NTFS) способна работать с гораздо более длинными путями: с префиксом \\?\ в Unicode-версии API можно указать в сумме около 32 767 символов.¹²
• Для снятия лимита в 260 символов на Windows 10 версии 1607 и новее нужны одновременно «LongPathsEnabled=1 в реестре» и «longPathAware в манифесте приложения». Только одного из них недостаточно.³
• Runtime .NET (Core) / .NET 5 и новее не выполняет проверку MAX_PATH и неявно обрабатывает длинные пути. При таргетировании .NET Framework на 4.6.2 и новее снимается собственная проверка runtime на 260 символов.⁴⁵
• При этом приложения без поддержки длинных путей реально остаются в ходу. Сама официальная документация прямо указывает, что оболочка (Проводник) может неверно интерпретировать путь, который удалось создать через Win32 API.¹
• В именах файлов нельзя использовать < > : " / \ | ? * и управляющие символы (0-31), а CON, PRN, AUX, NUL, COM1-9 и LPT1-9 трактуются как зарезервированные даже с расширением (например, CON.txt).⁶
• Пробелы и точки в конце имени молча удаляются при нормализации пути. Это источник ошибок вида: ввели «отчёт_v2.», а получили «отчёт_v2», или невозможности получить доступ из Windows к файлу с конечным пробелом, созданному другой ОС.⁶⁷
• Регистр имён файлов в Windows по умолчанию «сохраняется, но не различается». NTFS также поддерживает различение регистра на уровне каталога (fsutil.exe file setCaseSensitiveInfo), но включение этого режима имеет побочный эффект — приложения Windows не всегда способны это учесть.⁸⁹
• На стороне реализации нужно учитывать особенность Path.Combine: если один из последующих аргументов является корневым путём, все предыдущие аргументы отбрасываются (на .NET Core можно рассмотреть Path.Join), и санитизировать имена файлов, введённые пользователем, через Path.GetInvalidFileNameChars плюс собственную проверку зарезервированных имён и конечных символов.¹⁰¹¹

2. Что на самом деле представляет собой MAX_PATH=260

Максимальная длина пути в Win32 API, за некоторыми исключениями, определена как MAX_PATH=260 символов. У этого числа есть точный состав. Локальный путь складывается из «буквы диска, двоеточия, обратной косой черты, разделённых обратными косыми чертами компонентов имени и завершающего NUL» — например, для диска D максимум составляет «D:\ + 256 символов текста пути + завершающий NUL».¹

Иными словами, если считать 260 «длиной, доступной для имени файла», на самом деле её на 4 символа меньше — за счёт обозначения диска и завершающего NUL. Есть и более узкое ограничение: поскольку API создания каталогов требуют оставить место для последующего добавления имени в формате 8.3, путь к каталогу не может превышать MAX_PATH минус 12 символов.¹

Важно понимать, что это ограничение уровня Win32 API, а не предел файловой системы. NTFS поддерживает длинные имена файлов и пути расширенной длины, а Unicode-версии многих Win32-функций принимают пути расширенной длины общим объёмом около 32 767 символов. Верхняя граница отдельного компонента пути (одного имени папки или файла) — это значение, возвращаемое GetVolumeInformation, и обычно оно составляет 255 символов.¹²

Именно этот разрыв — «API говорит 260, файловая система говорит около 32 767» — и есть источник реальных сбоев на практике. Совершенно законно возникает ситуация, когда путь, созданный одним инструментом, невозможно открыть в другом (или в собственном приложении). Распаковка глубокого репозитория через git clone в папку с длинным именем, после чего сборка перестаёт проходить, — хрестоматийный пример, упомянутый даже в официальной документации.¹

Отметим также, что в старых версиях .NET Framework при полном пути от 260 символов и более выбрасывалось исключение System.IO.PathTooLongException. Увидев это исключение, в первую очередь подозревайте длину пути.¹²

3. Как преодолеть барьер в 260 символов и при каких условиях

Есть в целом два способа работы с длинными путями: «префикс \\?\» и «включение длинных путей на уровне ОС».

3.1. Префикс \\?\

Если добавить \\?\ в начало строки пути, Win32 API прекращает разбор строки и передаёт её как есть напрямую файловой системе. Это позволяет обойти ограничение MAX_PATH (UNC-путь имеет вид \\?\UNC\server\share). Однако есть условия и побочные эффекты.¹⁶

• Должна использоваться Unicode-версия API (функции с суффиксом «W» или вызовы через UTF-16, как в .NET).
• Поскольку нормализация пропускается, нельзя использовать разделитель / или относительную запись через ./... Префикс \\?\ нельзя добавить к относительному пути, поэтому относительные пути всегда ограничены значением MAX_PATH.¹
• Поддерживают это не все API — совместимость нужно проверять по документации конкретной функции.⁶

3.2. Включение длинных путей на Windows 10 1607 и новее — условие «оба параметра сразу»

На Windows 10 версии 1607 и новее можно снять ограничение MAX_PATH со многих распространённых Win32-функций работы с файлами и каталогами (CreateFileW, FindFirstFileW, GetFileAttributesW и т. п.). Однако это требует явного включения со стороны приложения — нужно выполнить оба следующих условия.³

1. Значение реестра LongPathsEnabled (REG_DWORD) в разделе HKLM\SYSTEM\CurrentControlSet\Control\FileSystem должно быть равно 1. То же самое можно настроить через групповую политику «Конфигурация компьютера > Административные шаблоны > Система > Файловая система > Включить длинные пути Win32».
2. В манифесте приложения должен присутствовать элемент longPathAware.

<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>

# Со стороны реестра (нужны права администратора)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

Жалоба «настроил реестр, а не работает» почти всегда объясняется отсутствием записи в манифесте. Официальная документация тоже подчёркивает: «этот параметр реестра влияет только на приложения, доработанные для использования новой функциональности». Кроме того, значение реестра кэшируется в рамках процесса при первом вызове файловой функции и не перечитывается на протяжении жизни процесса, поэтому для гарантированного применения изменения ко всем приложениям может потребоваться перезагрузка.³

3.3. Как обстоят дела в .NET

• .NET (Core) / .NET 5 и новее: runtime не выполняет проверку MAX_PATH и неявно обрабатывает длинные пути. Особый код на стороне приложения не требуется.⁴
• .NET Framework: при таргетировании на 4.6.2 и новее снимается проверка runtime на 260 символов, и PathTooLongException теперь выбрасывается только при превышении 32 767 символов или когда ошибку возвращает сама ОС. Даже существующее приложение с более старым таргетом может подключить это через AppContext-переключатели Switch.System.IO.BlockLongPaths=false (а также Switch.System.IO.UseLegacyPathHandling=false, отключающий устаревшую обработку путей).⁵¹²
• Чтобы приложение на .NET Framework реально пропускало длинные пути на практике, помимо настроек runtime выше требуется совместное использование включения длинных путей на стороне ОС и манифеста. Документация по поддержке длинных путей в NuGet.exe явно приводит эту конфигурацию (Windows 10 1607+ + манифест longPathAware + отключение UseLegacyPathHandling) как рабочий пример.¹³

3.4. Реальность: «неподдерживающие приложения» остаются даже после всего этого

Даже проделав всё это, вы не заставите все приложения в мире работать с длинными путями. Официальная документация прямо указывает: «у оболочки и файловой системы разные требования, интерфейс оболочки может неверно интерпретировать путь, который удалось создать через Win32 API»,¹ и на практике инструменты, не заявляющие о поддержке длинных путей, действительно встречаются (например, документация NuGet отмечает, что восстановление пакетов (restore) через Visual Studio или msbuild -t:restore не поддерживает длинные пути¹³). Даже если ваше собственное приложение способно создать файл по длинному пути, сможет ли пользователь открыть его в Проводнике или другом инструменте — уже отдельный вопрос. Проектные решения с учётом этой асимметрии сведены в таблицу решений в разделе 6.

4. Недопустимые символы, зарезервированные имена устройств, конечные точки и пробелы

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

4.1. Зарезервированные имена устройств — даже CON.txt не годится

CON и NUL — это имена устройств из эпохи MS-DOS, и они по сей день остаются зарезервированными в пространстве имён NT. Поэтому файл с именем «CON» обычным способом создать нельзя, и даже с добавлением расширения, как в CON.txt, оно всё равно интерпретируется как зарезервированное имя.⁶ На практике это проявляется, например, как сбой при попытке сохранить лог взаимодействия с последовательным портом под именем вроде «COM1.log», или как невозможность распаковать в Windows папку «aux», созданную на стороне Linux.

Заметим также, что по правилам нормализации пути раньше путь, начинающийся с зарезервированного имени — например, «CON» или «COM1.TXT», — преобразовывался и интерпретировался как путь устройства (\\.\CON). В Windows 11 эта интерпретация изменилась, и теперь для обращения к легаси-устройству требуется полная форма записи вроде \\.\CON.⁷ Тем не менее, поскольку и старые версии ОС, и существующие приложения по-прежнему используют прежнюю интерпретацию, вывод о том, что зарезервированных имён стоит избегать для бизнес-данных, не меняется.

4.2. Пробелы и точки в конце имени исчезают «молча»

Официальные правила именования гласят: «не завершайте имя файла или каталога пробелом или точкой».⁶ Если копнуть глубже, в нормализации путей Windows есть чёткое правило: «если путь не заканчивается символом-разделителем, все конечные точки и пробелы (U+0020) удаляются».⁷

На практике это неприятно тем, что без всякой ошибки имя молча превращается в другое. Если пользователь вводит имя «отчёт_v2.», в действительности создаётся файл «отчёт_v2» — конечная точка исчезает. И наоборот, файл вроде «report » (с конечным пробелом), созданный со стороны Linux через SMB, недостижим через обычную запись пути в Windows, поскольку нормализация меняет имя по пути. Способ получить доступ к такому «легальному, но недостижимому через нормализацию» имени — префикс \\?\, который пропускает нормализацию. Официальная документация прямо называет это назначение, отмечая, что файл вроде hidden. недоступен никаким другим способом.⁷

Отметим, что начальная точка допустима — имя вроде .gitignore создаётся без проблем.⁶

5. Регистр «сохраняется, но не различается»

Поведение файловой системы Windows по умолчанию — case-preserving, case-insensitive. Создав файл с именем Readme.txt, вы увидите его именно с таким регистром при отображении, но при поиске и сравнении регистр игнорируется, и README.TXT приводит к тому же самому файлу. Буквы дисков тоже не различают регистр.⁸⁶

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

На практике это проявляется при взаимодействии с Linux. Начиная со сборки Windows 10 17107, можно включить различение регистра для отдельного каталога.⁹

# В PowerShell с правами администратора
fsutil.exe file setCaseSensitiveInfo C:\work\linux-src enable
fsutil.exe file queryCaseSensitiveInfo C:\work\linux-src

Это действенный приём при работе с деревом исходников, происходящим из Linux (где, например, сосуществуют Makefile и makefile), но сама официальная документация предупреждает о побочном эффекте: приложение Windows, которое предполагает нечувствительность файловой системы к регистру, может потерять доступ к файлам в каталоге с включённым различением регистра. Кроме того, изменить флаг можно только тогда, когда целевой каталог пуст, а новые подкаталоги наследуют настройку родителя.⁹ Исторически также официально зафиксирован случай, когда при наличии двух файлов, отличающихся только регистром имени, Проводник показывал оба, но при выборе любого из них открывался всегда один и тот же файл.⁹

Для проектирования бизнес-приложений практический ориентир такой: по умолчанию считать в Windows имена, отличающиеся только регистром, одинаковыми, но при передаче имени файла в Linux проверять коллизии по регистру. При взаимодействии с Linux ловушки встречаются ещё до вопроса имён файлов — на уровне кодировки символов, поэтому стоит также заглянуть в статью «Введение в кодировки символов Windows — мойибакэ при взаимодействии с Linux».

6. Практика для бизнес-приложений — объединение путей, санитизация, таблица решений

6.1. Используйте Path.Combine, зная его особенности

Склеивание путей через + не рассматриваем в принципе, но и у Path.Combine есть особенность, которую нужно знать. Если во втором или последующем аргументе передан путь с корнем, все аргументы до него полностью отбрасываются.¹⁰

var baseDir = @"C:\App\Data";

// Если пользовательский ввод оказался путём с корнем, baseDir молча отбрасывается
Path.Combine(baseDir, @"C:\Windows\secret.txt"); // → "C:\Windows\secret.txt"
Path.Combine(baseDir, @"\evil.txt");             // → "\evil.txt" (корень текущего диска)

Передайте строку, полученную из пользовательского ввода или конфигурационного файла, напрямую вторым аргументом — и получите уязвимость, позволяющую записать файл за пределами предполагаемой папки сохранения. Официальная документация тоже предупреждает, что такое поведение может привести к непреднамеренному доступу к чувствительным файлам, и в качестве альтернативы предлагает Path.Join / Path.TryJoin (недоступны в .NET Framework).¹⁰¹⁴ Что бы вы ни использовали, в конечном счёте стандартная практика — проверять, что результат после нормализации через Path.GetFullPath действительно находится внутри базового каталога.

// Нормализуем и базовый путь тоже, затем преобразуем в относительный путь и проверяем.
// Такой подход надёжнее сравнения строковых префиксов при вариациях вроде
// наличия/отсутствия конечного разделителя или базового пути, являющегося корнем диска
var baseFull = Path.GetFullPath(baseDir);
var fullPath = Path.GetFullPath(Path.Combine(baseFull, userInput));
var relative = Path.GetRelativePath(baseFull, fullPath);
if (relative == ".." ||
    relative.StartsWith(".." + Path.DirectorySeparatorChar) ||
    Path.IsPathRooted(relative)) // при выходе на другой диск или UNC-путь возвращается абсолютный путь
{
    throw new InvalidOperationException("Путь сохранения указывает за пределы ожидаемой папки.");
}

Path.GetRelativePath сравнивает пути по соглашению, принятому по умолчанию в ОС — то есть в Windows это сравнение без учёта регистра, что согласуется с описанным ниже поведением «Windows по умолчанию не различает регистр». Обратная сторона этого: в местах, где для отдельного каталога включено различение регистра (см. предыдущий раздел), Data и data могут оказаться разными каталогами, и проверка без учёта регистра оставляет возможность ошибочно счесть «другую папку, отличающуюся только регистром» находящейся внутри базового каталога. Если есть вероятность работы с такой конфигурацией, безопаснее не принимать в качестве базового каталога расположение с включённым различением регистра.

Ещё один момент, о котором стоит помнить: эта проверка — это лишь проверка строки, нормализованной как путь. Если внутри базового каталога существует junction или символическая ссылка, строка может формально указывать внутрь базового каталога, а реальный объект — находиться за его пределами. Причём ссылка может встретиться не только в конечном файле, но и в промежуточной папке (в виде база\ссылка\файл.txt), поэтому проверка одной лишь конечной точки через File.ResolveLinkTarget не поможет её обнаружить. В первую очередь стоит вообще избегать конфигураций, где недоверенный пользователь способен создавать ссылки или junction внутри базового каталога. Если же строгое соблюдение действительно необходимо, либо получайте окончательный путь из дескриптора реально открытого файла (Win32 GetFinalPathNameByHandle) и проверяйте, что он находится внутри базового каталога, либо последовательно проверяйте каждый компонент-папку пути на предмет того, не является ли он ссылкой.

6.2. Санитизация имён файлов, введённых пользователем

Для функциональности, которая собирает имя файла из пользовательского ввода — например, «название контрагента + дата.csv», — сосредоточьте санитизацию в одном месте. Отправная точка — Path.GetInvalidFileNameChars, но официально указано, что этот массив не гарантирует полного набора недопустимых символов.¹¹ Зарезервированные имена устройств и конечные точки/пробелы этот API не обнаруживает, поэтому добавьте собственную проверку.

private static readonly HashSet<string> ReservedNames =
    new(StringComparer.OrdinalIgnoreCase)
    {
        "CON", "PRN", "AUX", "NUL",
        "COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9",
        "LPT1","LPT2","LPT3","LPT4","LPT5","LPT6","LPT7","LPT8","LPT9",
        "COM¹","COM²","COM³",  // COM¹-COM³ с надстрочными цифрами тоже зарезервированы
        "LPT¹","LPT²","LPT³",  // так же LPT¹-LPT³
    };

public static string SanitizeFileName(string input)
{
    var invalid = Path.GetInvalidFileNameChars();
    var name = new string(input.Select(c => invalid.Contains(c) ? '_' : c).ToArray());

    name = name.TrimEnd(' ', '.');            // Конечные пробелы и точки всё равно будут молча отброшены, поэтому убираем их сами

    // Укладываемся в лимит длины одного компонента имени файла (обычно 255 символов).
    // Обрезаем с запасом, оставляя место для иерархии папок и суффиксов, добавляемых приложением позже
    const int MaxNameLength = 120;
    if (name.Length > MaxNameLength)
    {
        var ext = Path.GetExtension(name);
        if (ext.Length > 20)
        {
            ext = ""; // Аномально длинное «расширение» не сохраняем как расширение (иначе можно получить исключение из-за отрицательного диапазона)
        }
        name = name[..(MaxNameLength - ext.Length)].TrimEnd(' ', '.') + ext;
    }

    // Проверку на пустоту/зарезервированное имя всегда выполняем над «итоговым» результатом,
    // чтобы поймать случаи, когда обрезка или TrimEnd превращают имя в пустую строку или зарезервированное имя (например, NUL)
    var stem = name.Split('.')[0];            // Защита от NUL.txt: проверяем зарезервированные имена по части до расширения
    if (name.Length == 0 || ReservedNames.Contains(stem))
    {
        name = "_" + name;                    // Добавление одного символа всё равно спокойно укладывается в лимит 255
    }
    return name;
}

Эта проблема часто встречается в именах файлов CSV-выгрузок, поэтому по практике работы с самим CSV стоит также заглянуть в статью «CSV — это не «просто текст» — практика работы с CSV в бизнес-приложениях на C#».

6.3. Ловушки относительных путей и текущего каталога

У относительных путей есть две ловушки. Во-первых, текущий каталог — это настройка на уровне процесса, поэтому его может в любой момент изменить любой поток. Официальная документация прямо пишет: «относительные пути опасны в многопоточных приложениях», и начиная с .NET Core 2.1 можно использовать Path.GetFullPath(string, string), который позволяет явно указать базовый путь.⁷ Во-вторых, форма вроде C:tmp.txt — без обратной косой черты сразу после буквы диска — означает «путь относительно текущего каталога на диске C», а вовсе не абсолютный путь. Такой «путь, относительный к диску», официально называется классическим источником ошибок в программах и скриптах.⁷

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

6.4. Таблица решений — поддерживать длинные пути или отклонять их на входе

7. Диагностика — «в Проводнике видно, но открыть не получается»

Порядок разбора для классической жалобы: «файл виден в Проводнике, а при открытии в приложении выдаётся ‘файл не найден’».

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

Отметим также, что неудачная загрузка DLL — тоже частый представитель ошибок вида «файл не найден», но здесь чаще дело в порядке поиска, а не в длине пути; это разобрано в статье «Как работает разрешение имён DLL в Windows — порядок поиска и SxS».

8. Итог

• MAX_PATH=260 — это ограничение Win32 API, включающее «D:\ + до 256 символов + завершающий NUL», а сама NTFS способна работать с путями расширенной длины около 32 767 символов. Для каталогов действует дополнительное ограничение — не более MAX_PATH минус 12.
• Чтобы превысить 260 символов, нужен либо префикс \\?\ (только Unicode-версии API, относительные пути недопустимы), либо включение длинных путей на Windows 10 1607 и новее (одновременно реестровое LongPathsEnabled и манифестное longPathAware).
• .NET (Core)/5+ обрабатывает длинные пути неявно, а .NET Framework при таргетировании на 4.6.2 и новее снимает проверку runtime. Однако приложения без поддержки, включая Проводник, по-прежнему встречаются, поэтому вопросы «можно ли создать» и «сможет ли пользователь этим воспользоваться» нужно рассматривать раздельно.
• В именах файлов недопустимы зарезервированные символы (< > : " / \ | ? *) и управляющие символы, зарезервированные имена устройств вроде CON, NUL, COM1 недопустимы даже с расширением, а конечные пробелы и точки молча удаляются при нормализации.
• Регистр по умолчанию «сохраняется, но не различается». Различение регистра на уровне каталога через fsutil file setCaseSensitiveInfo полезно при взаимодействии с WSL, но достаётся ценой риска некорректной работы приложений Windows.
• На стороне реализации стандартная практика — проверка базового каталога с учётом особенности Path.Combine в отношении корневых аргументов, объединение санитизации вокруг GetInvalidFileNameChars плюс проверка зарезервированных имён и конечных символов, а также исключение относительных путей через приведение к абсолютным с помощью Path.GetFullPath.

Похожие статьи

• CSV — это не «просто текст» — практика работы с CSV в бизнес-приложениях на C# (кодировка символов, совместимость с Excel, защита от инъекций)
• Введение в кодировки символов Windows — мойибакэ при взаимодействии с Linux
• Кодировки символов и символы перевода строки в Windows — основы мойибакэ и CRLF/LF
• Как работает разрешение имён DLL в Windows — порядок поиска и SxS

Смежные области консультаций

В Komura Software LLC мы занимаемся расследованием ошибок, связанных с файловым вводом-выводом, вроде «не открывается только в определённом окружении или только определённый файл», пересмотром поддержки длинных путей и валидации имён файлов в существующих бизнес-приложениях, а также консультациями по проектированию файлового взаимодействия в смешанных окружениях Windows и Linux.

• Разработка приложений для Windows
• Расследование сбоев и анализ первопричин
• Техническая консультация и ревью архитектуры
• Контакты

Справочные материалы

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Сколько символов может содержать путь в Windows?

По умолчанию лимит Win32 API составляет MAX_PATH=260 символов, и в эту длину входят буква диска, двоеточие, обратная косая черта, до 256 символов текста пути и завершающий NUL. Сама файловая система (NTFS и другие) способна работать с гораздо более длинными путями — передав в Unicode-версию API путь с префиксом \\?\, можно указать в сумме около 32 767 символов. При этом отдельный компонент пути (одно имя папки или файла) обычно ограничен 255 символами, а относительные пути всегда ограничены значением MAX_PATH.

Как снять ограничение MAX_PATH в 260 символов?

Начиная с Windows 10 версии 1607, если задать одновременно значение реестра LongPathsEnabled=1 (или групповую политику «Включить длинные пути Win32») и элемент longPathAware в манифесте приложения, лимит в 260 символов снимается для многих Win32-функций работы с файлами. Задание только одного из двух параметров не даёт эффекта. Runtime .NET (Core) / .NET 5 и новее не выполняет проверку MAX_PATH и обрабатывает длинные пути неявно, а при таргетировании .NET Framework на версию 4.6.2 и новее снимается проверка на 260 символов на стороне runtime. Однако приложения без поддержки длинных путей — включая сам Проводник — по-прежнему встречаются, поэтому нужно учитывать, кто в итоге будет работать с созданным вами длинным путём.

Почему нельзя создать файл с именем CON или NUL?

CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9 и другие — это зарезервированные имена устройств, доставшиеся ещё от эпохи MS-DOS, и Windows интерпретирует эти имена не как файлы, а как устройства. Добавление расширения, как в NUL.txt, не помогает — оно всё равно трактуется как NUL. В Windows 11 часть логики интерпретации таких путей изменилась, но поскольку старые версии ОС и множество существующих приложений по-прежнему следуют прежней интерпретации, для имён файлов с бизнес-данными такие имена по-прежнему безопаснее избегать.

Различает ли Windows регистр букв в именах файлов?

По умолчанию — «сохраняет регистр, но не различает его» (case-preserving, case-insensitive). Создав файл с именем Readme.txt, вы увидите его именно с таким регистром при отображении, но попытка открыть README.TXT приведёт к тому же самому файлу. NTFS также поддерживает POSIX-подобное различение регистра, и начиная со сборки Windows 10 17107 можно включить различение регистра для отдельной папки через fsutil.exe file setCaseSensitiveInfo — но у этого есть побочный эффект: приложения Windows, рассчитанные на нечувствительность к регистру, могут начать работать некорректно, поэтому применять это стоит только там, где это действительно нужно, например при взаимодействии с WSL.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.