Кратко

  • STOU обещал не занятый pathname только в текущем каталоге. Он ничего не говорил о глобальной, вечной связи имени с созданным файлом или о равенстве содержимого.
  • Факт Unique= показывал, ведут ли разные pathnames к одному сохранённому файлу: одинаковый непрозрачный токен означал одну и ту же файловую запись, но согласованность требовалась лишь как минимум на время управляющего соединения.
  • Ни pathname, ни токен не давали права доступа, не доказывали сохранность и не должны были превращаться в скрытое средство доступа. Переименование, ссылки, удаление и миграция оставались отдельными решениями.

Один файл за двумя pathname

В машинном списке FTP стоят два разных pathname. Рядом с каждым указан одинаковый Unique=. Для клиента это ограниченное свидетельство: оба имени ведут к одному и тому же сохранённому файлу. Если удалить или переместить “вторую копию”, исход может затронуть не копию, а ещё один путь к тем же данным.

Теперь рассмотрим другую строку истории. Клиент отправляет STOU без pathname, и сервер создаёт имя, не занятое в текущем каталоге. Здесь отличие имени — цель операции. Новый pathname должен не столкнуться с существующим. Но из этого не следует, что записанный под ним файл отличается по содержанию от другого, будет существовать вечно или получил универсальный идентификатор.

Две уникальности направлены в разные стороны. STOU отвечает: “какое свободное имя выделено для этой записи?” Unique= отвечает: “ведут ли эти имена к одному сохранённому файлу?” Первая операция управляет местом в пространстве имён. Второй факт сообщает ограниченное соответствие между pathname и файловой записью. Прилагательное одно, предметы разные.

Токен сопоставлял pathnames, но не становился вечным паспортом файла

RFC 3659, опубликованный в марте 2007 года, определил Unique= как факт машинной выдачи. Токен непрозрачен и чувствителен к регистру. Равные значения у двух pathnames указывают, что оба ведут к одной и той же сохранённой файловой записи.

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

Факт также не является хешем содержимого. Разные сохранённые файлы с одинаковыми байтами не обязаны иметь один токен; несколько имён одной файловой записи, напротив, должны сравниваться как один файл в пределах обещанной согласованности. Подмена “тех же сохранённых данных” понятием “того же файла по содержанию” меняет предмет утверждения.

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

STOU создавал локально свободный адрес, а не первичный ключ

Команда STOU была стандартизована в RFC 959 в октябре 1985 года. Её синтаксис — STOU <CRLF> — не содержал pathname. Сервер создавал файл в текущем каталоге под именем, уникальным относительно этого каталога.

“Относительно текущего каталога” — весь масштаб обещания. Один и тот же текст имени мог существовать в другом каталоге. Позднее имя могло быть освобождено и использовано снова по правилам конкретной системы. Путь мог измениться после переименования. Ничто в команде не превращало его в постоянный ключ записи для внешней базы.

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

У RFC 959 оставалась ошибка в том, как вернуть имя. Документ говорил о “250 Transfer Started”, хотя 125 и 150 были предварительными ответами, а 250 обозначал завершённое действие. Его таблица для STOU также отделяла начальные 125/150 от последующих 226/250. Неопределённость смешивала адрес, выделенный для будущей записи, и результат самой записи.

RFC 1123 исправил это в 1989 году. Фактический pathname должен был появиться до передачи в точной форме 125 FILE: pppp или 150 FILE: pppp. Маркер FILE: делал строку доступной машинному разбору, а предварительный код сохранял правильный предел: файл будет записываться под этим именем, но успешное завершение передачи ещё не доказано.

Переименование меняло путь, но не обязательно сохранённый файл

Если pathname используется как постоянный внешний ключ, простое переименование выглядит как исчезновение старого файла и появление нового. Unique= показывает, почему такая модель хрупка: разные имена могут вести к одной сохранённой файловой записи. Ссылка или дополнительное имя способны умножить pathnames без создания дополнительных копий данных.

Обратная ошибка тоже возможна. Два независимо выделенных STOU имени не следует автоматически сливать, даже если клиент считает запросы повтором. Команда удостоверяет только отсутствие коллизии в момент локального выделения. Она не сообщает, что два pathname ведут к одному сохранённому файлу, и потому не оправдывает объединение истории, прав или сроков хранения.

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

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

Новое имя конфликтовало с идеей продолжить прежний частичный файл

Различие pathname и сохранённого файла объясняет ещё одну оговорку RFC 3659. Документ расширил REST для возобновления передачи в потоковом режиме и рекомендовал обычно продолжать RETR или STOR. Сервер мог разрешить APPE или STOU, так что речь не об абсолютном запрете.

Однако REST перед STOU был не рекомендован, а семантика сочетания названа неопределённой. Маркер возобновления предполагает позицию внутри уже распознанного назначения. STOU выделяет новый pathname. Новый адрес не доказывает, что под ним находится продолжение прежнего частичного файла.

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

Эта неопределённость — практический пример того, почему pathname не следует принимать за постоянный файловый ключ. Возобновление требует доказать, что запись продолжится в тот же частичный файл; выделение свободного имени решает только конфликт пространства имён.

Выбор сервера появился до обеих форм unique

Истоки STOU объясняют, почему серверу вообще передали право назвать файл. RFC 172, опубликованный в июне 1971 года, определял файл через pathname внутри системы, но не стандартизировал соглашения о pathname. Пользователь должен был понимать правила удалённой файловой системы. Обычное сохранение по существующему имени могло заменить содержимое, а по новому — создать файл.

Управление доступом при этом оставалось у резидентной системы. FTP переносил операции и учётные данные, но не отменял защиту хоста. Уже здесь путь был адресом в чужой административной области, а не свободно переносимым идентификатором пользователя.

RFC 505 в 1973 году предложил каталог-пул для передачи файла пользователю без знания его пароля. Получатель мог быть уведомлён и позже скопировать файл в собственное пространство. Предложение POOL id name принимало желаемое имя, а сервер добавлял префикс или суффикс ради уникальности в пуле.

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

RFC 949 в июле 1985 года оформил отдельный STOU, приводя примеры очередей принтера, факса и перфоратора. Авторы не захотели менять устоявшуюся обработку STOR; новый глагол было проще добавить в диспетчер команд. Сервер выбирал имя в текущем каталоге и обязан был сообщить его отправителю.

Документ отдельно сохранил контроль доступа, аутентификацию и учёт. Право сервера назвать свободное место не означало право клиента писать без разрешения. Эта граница остаётся полезной и для Unique=: возможность узнать, ведут ли два pathname к одной файловой записи, не предоставляет полномочий менять её.

Реестр фиксировал слово, а не состояние конкретного сервера

RFC 5797 создал реестр FTP-команд и расширений прежде всего для предотвращения конфликтов названий. В действующем реестре IANA STOU остаётся необязательной базовой командой со ссылками на RFC 959 и RFC 1123.

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

Тем более реестр не исправлял безопасность FTP. RFC 2577 документировал передачу паролей, управления и данных без шифрования, а также риски кражи и подмены соединения данных. Ни локально уникальный pathname, ни совпавший Unique= не аутентифицировали содержимое и не подтверждали сторону соединения.

Обе формы unique оставляли за собой узкий след. Одна давала серверу возможность избежать коллизии при создании имени. Другая позволяла в ограниченный период определить, ведут ли несколько имён к одной сохранённой файловой записи. Их точность исчезает, если объявить любую из них вечным, глобальным и властным идентификатором.