Кратко

  • В draft-ietf-nfsv4-internationalization-17 описаны разные допустимые модели NFSv4: имена как непрозрачные последовательности октетов либо Unicode-осведомлённое сравнение с нормализацией и правилами регистра. По положительному ответу клиент обычно не может восстановить полное отношение эквивалентности.
  • До резервного копирования, репликации, аварийного переключения или миграции следует оформить квитанцию эквивалентности пространства имён: точные байты запросов, возвращённые формы, среду, проверки коллизий, сведения о возможностях и пределы наблюдения.

Успех, который не объясняет себя

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

Если оба варианта приводят к одному файлу, известно лишь, что эквивалентность возникла на каком-то уровне. NFS-сервер мог нормализовать вход. Он мог сохранить исходную форму, но признавать канонически эквивалентную при LOOKUP. Решение могло принять нижележащее файловое хранилище. Настройка могла добавить сравнение без учёта регистра. Одинаковый удачный ответ совместим со всеми этими объяснениями.

Редакция 17 проекта об интернационализации NFSv4 опубликована 11 сентября 2026 года после замечаний IETF Last Call. Это активный Internet-Draft на Standards Track, переданный в IESG. Он ещё не стал RFC и сам по себе не доказывает реализацию описанного поведения каким-либо продуктом.

История документа особенно показательна. В отчёте ответственного редактора сказано, что положения об интернационализации NFSv4.1 не были реализованы так, как задумывались. Перечисленные крупные реализации широко следовали подходу NFSv4.0, не интерпретирующему UTF-8, а осведомлённые функции оставались ограниченными или экспериментальными. Поэтому нынешний текст в значительной степени исходит из фактической практики. Координировать приходится реальные сравнения, а не предполагаемое влияние прежней нормы.

Пространство имён из непрозрачных байтов

Для файловой системы, не осведомлённой об UTF-8, компонент имени — непрозрачная строка октетов. Сравнение выполняется побайтно. Такой режим сохраняет имена из старых кодировок и последовательности, не являющиеся допустимым UTF-8. Разные байты остаются разными именами, даже если Unicode считает их символьные формы канонически эквивалентными.

У этого решения есть последовательная логика: идентичность задают исходные байты, а обновление Unicode-библиотеки не должно незаметно сливать старые записи. Цена проявляется у пользователя. Клавиатура или приложение могут воспроизвести тот же видимый текст в другой нормальной форме, и файл окажется «не найден».

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

Фраза «без учёта регистра» тоже не полна в международном контексте. Преобразование может зависеть от языка и предпочтений пользователя. Проект считает, что общий механизм передачи всех таких решений клиенту пока не готов для стандартизации. Заявление «поддерживает Unicode» не говорит, идёт ли речь о допустимости ввода, форме хранения или равенстве.

Возможность не равна политике

Атрибут fs_charset_cap даёт узкий сигнал. В текущем проекте он указывает на сервер, принимающий только имена UTF-8. Историческое значение FSCHARSET_CAP4_CONTAINS_NON_UTF8 осталось неясным; серверам рекомендуется предоставлять его дополнение, а клиентам — игнорировать сам флаг. Если атрибут не поддерживается, управляемая проба с не-UTF-8 именем позволяет кое-что узнать о приёме.

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

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

READDIR не показывает все допустимые обращения

Полный список каталога кажется исчерпывающим, однако READDIR возвращает сохранённую или выбранную сервером форму. Он не перечисляет все варианты, которые LOOKUP признал бы путём к тому же filehandle. Сервер может показать одно написание, а принять канонически эквивалентное другое.

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

Политика меняется и со временем. К классу канонической эквивалентности могут добавиться члены при включении новых символов в Unicode. Проект предпочитает сравнение, нечувствительное к форме, обязательной форме хранения, в том числе из-за долгой жизни имён. Сохранность байтов необходима, но новая платформа всё равно может вынести по ним другое решение.

Миграция меняет судью

Планы переноса проверяют объём, число объектов, права, метки времени и контрольные суммы. Все эти меры нужны, но они не измеряют равенство имён. При создании записи на целевой стороне новый сервер, файловая система, Unicode-библиотека и набор параметров заново решают, какие байты допустимы и что следует слить.

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

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

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

Квитанция эквивалентности пространства имён

Для осмысленного одобрения нужен компактный артефакт, который сможет проверить следующий оператор. Назовём его квитанцией эквивалентности пространства имён. Это редакционное предложение по управлению, а не требование Internet-Draft.

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

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

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

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

Границы квитанции намеренно узки. Содержимое символической ссылки непрозрачно по другим правилам; не-ASCII доменные имена используют U-label; разные строковые типы NFS обрабатываются не одинаково. Квитанция не сертифицирует Unicode вообще, а подтверждает конкретные наблюдавшиеся отношения в названной среде.

Граница доказательства

RFC 6943 показывает, что несогласованное сравнение идентификаторов способно вызвать ложные совпадения, пропуски, отказ в обслуживании, а в отдельных системах — повышение привилегий. Это не сообщение об инциденте NFS, и проект его не заявляет. Но этого достаточно, чтобы включать равенство имён в проверку безопасности, если пути участвуют в авторизации, запуске или хранении доказательств.

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

Источники