Кратко

  • FTP разделил переименование на RNFR и RNTO: ответ 350 на первую команду был положительным промежуточным состоянием, а не подтверждением нового имени.
  • RFC 3659 позднее раздельно описала возможность выбрать исходный объект, создать имя в целевом каталоге и необязательный факт Unique для сопоставления объекта под разными именами.
  • Стандарты определяют порядок команд и смысл ответов, но не обещают атомарность, долговечность, правила замещения, безопасность при сбое или наличие функции на современном сервере.

Успех, после которого ничего не изменилось

Клиент отправляет RNFR old-name. Сервер отвечает 350 Requested file action pending further information. Код положительный, и примитивная панель может тут же отметить операцию зелёным.

Но старое имя всё ещё может находиться на месте. RFC 959 определяет 3xx как положительный промежуточный ответ: команда принята, однако запрошенное действие удерживается в ожидании дополнительных сведений. Для переименования недостающими сведениями служит новый путь в RNTO.

Та же конструкция уже была в RFC 765. RNFR указывает переименовываемый файл и должна быть немедленно продолжена RNTO; вторая команда задаёт новый путь для файла из непосредственно предшествующей команды. Переименование вызывает пара, а не одна RNFR.

Протокол сделал паузу видимой. Сервер мог положительно разрешить продолжение и одновременно не выдавать ожидание за завершение.

Короткая память управляющего соединения

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

Это не доказывает блокировку исходного файла, резервирование целевого имени или выдачу долговечного идентификатора транзакции. Требование «немедленно» связывает RNTO с прямо предшествующей RNFR. Без нужной предыстории возможен ответ 503 Bad sequence of commands.

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

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

Чем 250 отличается от другого положительного кода

В RFC 959 класс 2xx означает положительное завершение: запрошенное действие успешно закончено, можно начинать новый запрос. 250 конкретно сообщает, что требуемое действие над файлом выполнено. 350, напротив, прямо сохраняет зависимость от дополнительной информации.

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

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

Право на источник не равно праву на назначение

RFC 3659 сделала две поверхности полномочий явными с помощью факта perm. Индикатор f у объекта говорит, что текущий пользователь FTP может сделать его предметом RNFR. Индикатор c у каталога говорит, что в нём можно создавать файлы и что RNTO для имён внутри, вероятно, будет успешной.

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

Слово «вероятно» тоже ограничивает вывод. Факт листинга описывает ожидаемую возможность в момент наблюдения, но не резервирует назначение, не замораживает политику и не устраняет конкуренцию. Фактический запрос всё равно нуждается в окончательном ответе.

Объектное свидетельство под новым именем

Та же RFC определила необязательный факт Unique. Если сервер его предоставляет, пути к одному базовому файлу должны иметь одинаковое непрозрачное значение, а разные файлы — разные. Соответствие должно оставаться стабильным как минимум в течение управляющего соединения.

В примере спецификации mlst.c сначала имеет одно значение Unique. Клиент получает 350 на RNFR mlst.c, затем 250 на RNTO list.c. После этого list.c показывается с тем же значением. Путь изменился, а ограниченное объектное свидетельство сервера сохранилось.

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

Обязательная команда не обещает свойства файловой системы

RFC 1123 сохранила RNFR и RNTO в требованиях к FTP-командам хоста. RFC 5797 отнесла обе к обязательным базовым командам, а реестр команд и расширений FTP IANA поддерживает эти записи.

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

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

Файл между двумя именами

Современные управляющие API тоже могут принять предложение раньше, чем применить изменение. Хорошая система называет промежуточное состояние, привязывает его к сеансу или транзакции, описывает срок и причины аннулирования, а слово «завершено» оставляет для явного подтверждения.

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

350 не был слабым успехом. Это был точно сформулированный неокончательный успех. Файл вошёл в последовательность команд, но ещё не вошёл в новый путь. Переименование не произошло — и ответ именно это сообщал.

Источники