Resumo

  • A RFC 959 definiu SMNT como comando opcional para montar outra estrutura de arquivos sem alterar login, contabilização nem parâmetros de transferência.
  • Depois da troca, o mesmo caminho textual poderia resolver outro objeto; a prova de uma operação precisava incluir o namespace ativo, não apenas usuário e path.
  • A extensão HOST adotou outra ordem: a escolha do host virtual deve vir antes da autenticação quando pode mudar os métodos e o conjunto de usuários autorizados.

Uma sessão contínua, dois mapas de recursos

O cliente já se autenticou. O servidor conhece o usuário e a conta, e as partes ajustaram tipo, modo e estrutura de transferência. O cliente então envia SMNT apontando para um diretório ou grupo de arquivos dependente do sistema.

Segundo a RFC 959, uma resposta bem-sucedida monta outra estrutura de sistema de arquivos sem mudar as informações de login e contabilização nem os parâmetros de transferência. A conexão de controle não recomeça. O principal permanece. O mapa que dá sentido aos nomes muda.

Essa lista de preservação é a parte mais interessante da ordem. Ela impede que se confunda identidade autenticada com contexto de resolução. O protocolo permitia que os dois avançassem em ritmos diferentes.

Três transições que parecem navegação

CWD oferece o contraste mais próximo. Ele muda o diretório ou conjunto de dados de trabalho, preservando usuário e conta. É deslocamento dentro da estrutura atual. REIN faz algo muito mais profundo: descarta usuário, conta e parâmetros de transferência para devolver a conexão a um estado comparável ao recém-aberto.

SMNT fica entre ambos. Ele troca a estrutura, mas não reinicia toda a sessão. Portanto, cada ordem cria uma obrigação de invalidação distinta. Com CWD, muda a base relativa. Com SMNT, muda o universo de nomes e pode mudar a política. Com REIN, identidade e ajustes anteriores deixam de ser pressupostos válidos.

Agrupar tudo sob “mudar de diretório” seria um erro operacional. A interface pode mostrar movimento, enquanto a segurança precisa saber se posição, namespace ou principal foi alterado.

O path exato ainda é evidência incompleta

FTP não estabeleceu uma convenção universal para paths. A RFC 959 os deixou sujeitos aos sistemas de arquivos envolvidos. A RFC 3659 manteve a cautela: fora de TVFS, a sintaxe é definida pelo servidor; clientes devem guardar e retransmitir exatamente o nome recebido.

Preservar os caracteres evita uma corrupção introduzida pelo cliente. Não preserva o objeto através de um SMNT. /financeiro/fechamento pode ser idêntico antes e depois e alcançar raízes, mídias ou políticas diferentes.

Uma trilha capaz de identificar o recurso precisa unir endpoint, principal, host virtual se houver, estrutura montada, diretório corrente, representação do path e momento. Registros que guardam apenas usuário e path omitem justamente o estado capaz de transformar um nome familiar em outro objeto.

Também não se deve atribuir uniformidade ao passado. O grupo de arquivos de SMNT era dependente do sistema, e a ordem era opcional. As fontes documentam a separação de estados, não um único modelo de implementação disseminado por todos os servidores.

Montar era uma decisão de acesso

A RFC 5797 classificou SMNT na classe de controle de acesso, como ordem opcional do conjunto base. Essa classificação continua na tabela de IANA.

Faz sentido. Outra estrutura pode expor outro conjunto de objetos e mudar o resultado da autorização. O fato de o usuário ter passado pelo login não lhe concede automaticamente o direito de selecionar qualquer estrutura. O servidor precisa autorizar a transição e avaliar as ações posteriores no novo contexto.

A RFC 1123 mostra a fronteira do requisito: CWD é obrigatório, SMNT continua opcional. Navegar pelo espaço oferecido fazia parte do denominador comum; substituir esse espaço, não.

O registro FTP de IANA prova que o nome está coordenado e vinculado a uma semântica. Não prova suporte em um servidor, permissão para um usuário nem execução numa sessão. Até uma resposta positiva comprova somente a transição aceita, não a continuidade do objeto indicado por paths iguais.

Quando o contexto define quem pode entrar

A RFC 7151 introduziu HOST para selecionar um host virtual num servidor FTP compartilhado. A ordem deve aparecer antes da autenticação; depois dela, recebe 503.

O host escolhido pode definir os métodos de autenticação e o conjunto de usuários autorizados. Nesse caso, o contexto participa da própria validade da identidade. Não seria seguro carregar um principal já autenticado para outro domínio sem reexaminar suas credenciais.

HOST não substituiu SMNT, nem trata da mesma função. Mas o contraste cria um critério. Se a mudança apenas troca recursos sob uma identidade independente, talvez seja possível preservar o login e refazer a autorização. Se a mudança determina quais identidades são reconhecidas, ela precisa ocorrer antes do login.

Uma peça antiga para sistemas que trocam de tenant

Poucos operadores dependem hoje de SMNT. Ainda assim, painéis empresariais preservam a sessão enquanto mudam de organização; consoles de nuvem mantêm credenciais enquanto mudam de projeto ou região; processos mantêm identidade enquanto recebem outro namespace de montagem.

Essas tecnologias não são FTP com nova aparência. A continuidade está na pergunta de projeto: qual estado sobrevive e qual autoridade continua válida depois da troca?

Um principal não é um namespace. Um path não é um objeto fora do contexto que o resolveu. Uma sessão contínua não comprova um plano de armazenamento contínuo. O login sobreviveu ao SMNT; por isso, o evento de montagem precisava fazer parte da evidência.

Fontes