Кратко

  • RFC 959 определила необязательную команду SMNT, которая подключала другую файловую структуру, сохраняя вход, учётные данные и параметры передачи.
  • Одинаковая строка пути до и после успешного переключения могла обозначать разные объекты; пространство имён является частью доказательства о ресурсе.
  • Поздняя команда HOST разрешалась только до аутентификации, поскольку виртуальный хост мог определять способы входа и допустимых пользователей.

Неизменный пользователь над сменившейся структурой

Управляющее соединение уже установлено. Сервер принял пользователя и при необходимости аккаунт; стороны выбрали тип представления и режим передачи. Клиент отправляет SMNT с путём к каталогу или иной системно-зависимой группе файлов.

RFC 959 подчёркивает, что новая структура монтируется без изменения регистрационных и учётных сведений пользователя и параметров передачи. Это не повторный вход и не возврат соединения к начальному состоянию. Меняется основа, на которой разрешаются имена.

Именно перечень сохранённых состояний делает команду важной. Протокол допускал непрерывность принципала при разрыве непрерывности пространства ресурсов. Эти две непрерывности нельзя доказывать друг через друга.

Положение, структура, весь сеанс

CWD меняет рабочий каталог или набор данных, сохраняя пользователя и аккаунт. Это перемещение внутри текущей структуры. REIN, напротив, очищает пользователя, аккаунт и параметры передачи, возвращая управляющее соединение в состояние, похожее на только что открытое.

SMNT занимает промежуточный уровень. Оно меняет не просто текущую позицию, но ещё не уничтожает контекст сеанса целиком. После CWD иной становится относительная база; после SMNT — система разрешения; после REIN нельзя полагаться ни на прежнюю идентичность, ни на настройки.

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

Точное воспроизведение пути не сохраняет объект

RFC 959 не навязывала универсального синтаксиса путей: он зависел от файловых систем участников. RFC 3659 позднее всё ещё предупреждала, что за пределами TVFS синтаксис задаёт сервер, а клиенту следует хранить и возвращать путь в точности как получен.

Такой подход защищает строку от самовольной нормализации. Но он не закрепляет смысл строки после SMNT. /data/current может совпасть побайтно и разрешиться через другой корень, носитель или набор правил.

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

Из документов нельзя выводить единый способ реализации SMNT. Группа файлов была системно-зависимой, а команда — необязательной. Надёжный вывод уже: FTP стандартизировал изменение контекста имён при сохранении других частей сеанса.

Почему это управление доступом

RFC 5797 отнесла SMNT к классу команд управления доступом, пометила необязательной и включила в базовый набор. Нынешний реестр IANA сохраняет эту классификацию.

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

RFC 1123 показывает границу обязательности: CWD требуется, SMNT остаётся необязательной. Перемещение по предложенному пространству входило в общий минимум FTP, его замена — нет.

Реестр команд и расширений FTP IANA подтверждает координацию имени и его документированный смысл. Он не подтверждает поддержку конкретным сервером, права пользователя или выполненный переход. Даже положительный ответ в трассе доказывает принятие перехода, но не тождество одинаково записанных путей по обе стороны.

Когда контекст должен предшествовать входу

RFC 7151 определила HOST для выбора виртуального хоста на общем FTP-сервере. Команду требуется передать до аутентификации; после неё сервер отвечает 503.

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

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

Современность протокольного остатка

Сегодня SMNT встречается редко. Но его задача возникает при смене организации в административной панели, проекта или региона в облаке, пространства монтирования контейнера. Человек или процесс остаётся, видимый набор ресурсов меняется.

Это не те же системы и не прямые продолжения FTP. Общим остаётся требование явно моделировать зависимости: что сохраняется, какая власть подтверждает сохранённое состояние и какой контекст разрешил имя.

Принципал не равен пространству имён. Путь без контекста не равен объекту. Непрерывность соединения не доказывает непрерывность ресурсного слоя. Вход пережил переключение — поэтому само переключение должно было стать отдельным фактом аудита.

Источники