Кратко

  • Команда ALLO позволяла до STOR или APPE объявить объём в логических байтах, а для записей и страниц — также максимальный размер единицы.
  • Сервер без необходимости предварительного выделения должен был считать команду пустой операцией; положительный 202 говорил, что она излишня и клиент может идти дальше.
  • Такой ответ подтверждал совместимость процедуры, а не наличие места. Для вывода о сохранении требовались канал данных, финальный ответ, состояние квоты и проверяемый файл.

Заявка на место в мире разных файловых систем

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

RFC 354 1972 года закрепил оба варианта в описании ALLOCATE (ALLO). Некоторым серверам команда могла требоваться, чтобы оставить достаточно пространства для нового файла. Десятичный аргумент задавал число байтов в выбранном размере байта; затем должны были следовать STORE или APPEND.

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

RFC 765 1980 года уточнил, что первая величина измеряется в логических байтах. Для файлов со структурой записей или страниц можно было добавить максимальный размер записи или страницы после пробела, R и ещё одного пробела. Сервер, которому важна только вторая величина, должен был принять фиктивную первую и игнорировать её.

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

Положительный код для действия, которое не требовалось

RFC 959 в 1985 году сохранил обязательное число и необязательную форму R со вторым числом. После ALLO должен идти STOR или APPE; если предварительное объявление максимума не нужно, серверу следует считать команду NOOP.

Правила ответов раскрывают замысел. Успешная команда вроде TYPE или ALLO, не дающая пользовательскому процессу новой информации, может получить 200. Если конкретный Server-FTP не реализует ALLO, потому что она не имеет отношения к данной вычислительной системе, всё равно желателен положительный финальный ответ. Простой клиент понимает, что может продолжить. Для этого предназначен 202, а пример текста сообщает, что выделение места не требуется.

Общее значение 202: команда не реализована, потому что на этом узле она избыточна. Это не скрытая ошибка. Сервер честно говорит, что запрошенного действия не было, и одновременно сообщает, что его отсутствие не мешает следующему шагу. Успех относится к продолжению сеанса, не к физическому резерву.

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

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

STOR проверял то, чего не мог доказать ALLO

ALLO не передаёт содержимое. Команда STOR требует принять данные через отдельное соединение и сохранить их под заданным именем. Существующий файл заменяется переданными данными, отсутствующий создаётся. Только здесь план встречается с разрешениями, путём, соединением и реальным хранилищем.

Ответы показывают стадии. 125 говорит, что соединение данных уже открыто и передача начинается. 150 сообщает, что состояние файла допускает операцию и соединение будет открыто. Это предварительные ответы, не завершение. Положительный финал может прийти как 226 или 250; для проблем соединения, локальной обработки, пути и хранения существуют другие исходы.

452 означает, что действие не выполнено из-за недостатка места в системе. 552 означает прекращение файлового действия после превышения выделения для текущего каталога или набора данных. Предшествующий 202 не противоречит этим ошибкам: отсутствие необходимости в предварительном резерве не гарантирует, что место не закончится во время записи.

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

RFC 3659 проводит сходную границу для прав в машиночитаемых списках. Индикатор записи никогда не гарантирует, что соответствующая команда сработает; системные ограничения, в том числе доступное место, могут привести к отказу. Право — только ориентир. Этот текст не меняет ALLO, но подтверждает различие между допустимостью и результатом.

Необязательная команда оставалась достижимой

RFC 1123 1989 года отнёс поддержку ALLO сервером к необязательной категории. Одновременно пользовательская программа FTP обязана была предоставлять QUOTE, который передаёт серверу произвольную строку и показывает все ответы.

В пояснении названы SITE и ALLO: пользователь мог обратиться к системной или необязательной функции, даже если клиент не понимал её как встроенную возможность. Общий клиент не разрастался до каталога всех локальных традиций, а специальные функции сервера оставались наблюдаемыми.

Реестр команд и расширений FTP IANA по-прежнему содержит ALLO как базовую команду “Allocate” со ссылкой на RFC 959. Реестр устанавливает имя и нормативную ссылку. Он не доказывает реализацию на конкретном сервере, наличие резерва, свободную ёмкость или завершение отдельной передачи.

Аудит должен дойти до результата записи

Запись «ALLO успешно» уничтожает нужное различие. Следует сохранять точную строку команды, обе величины, активные TYPE и STRU, числовой код и полный текст ответа. 200 и 202 входят в положительный класс, но описывают разные решения.

Затем подготовку нужно связать со следующим STOR или APPE: открылось ли соединение данных, сколько байтов отправлено и принято, был ли обрыв, какой пришёл финальный ответ, существует ли объект с ожидаемым размером и хешем. Для вывода о ёмкости нужны свободное место, квота аккаунта и каталога, а также параллельная нагрузка в нужный момент.

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

Даже положительный финальный ответ FTP сам по себе не обещает бессрочное хранение, репликацию или восстановление. Если эти свойства важны, объект перечитывают, сверяют и проверяют копии. Урок ALLO — не сомневаться во всех ответах, а не расширять их значение за пределы выполненной стадии.

Источники