요약

  • FTP는 이름 바꾸기를RNFR과RNTO로 나누었습니다.350응답은 원본 경로를 대기 중인 시퀀스로 받아들였지만 어떤 이름도 바뀌었다고 말하지 않았습니다.
  • 바로 이어지는 목적지 명령과 그 최종 응답이 변경 결과를 실었으며, 이후 MLSx 사실들은 원본 측 권한, 목적지 생성 권한, 선택적 객체 연속성 근거를 분리했습니다.
  • 표준은 원자성, 내구성, 덮어쓰기 정책, 장애 이후 안전성 또는 현재의 배포 상황이 아니라 명령 상태와 근거 경계를 정의합니다.

끝나지 않은 동작에 대한 긍정적 응답

클라이언트가RNFR old-name을 보냅니다. 서버는350 Requested file action pending further information으로 응답합니다. 첫 자리 숫자는 긍정적입니다. 성공 여부를 훑어보는 운영자는 이름 바꾸기가 끝난 것으로 표시할 수 있습니다.

그러나 아무것도 이름이 바뀌지 않았습니다.

RFC 959는 3xx 응답을 긍정적 중간 응답으로 정의합니다. 명령은 수락되었지만, 클라이언트가 더 많은 정보를 제공하기 전까지는 요청된 동작이 보류된다는 뜻입니다. 이 경우 그 정보는RNTO에 담기는 새 경로명입니다. 이 프로토콜은 의도와 변경을 하나의 환한 결과로 압축하는 대신 대기 상태를 드러냅니다.

앞선RFC 765도 이미 같은 구조를 담고 있었습니다.RNFR은 이름을 바꿀 파일을 지정하며 반드시 바로 이어서RNTO가 와야 하고,RNTO는 바로 앞 명령의 파일에 대한 목적지를 지정합니다. 두 명령이 함께해야, 각각이 아니라, 이름 바꾸기가 일어납니다.

서버가 쥐고 있던 것은 완결된 이름 바꾸기가 아니라 문맥이었다

FTP는RNFR과RNTO를 순차 명령 그룹으로 기술합니다. 응답은 앞선 단계가 유효한 중간 상태에 도달했는지를 보여줍니다. 어느 지점에서든 실패하면, 명세는 전체 시퀀스를 처음부터 다시 반복해야 한다고 말합니다.

이 복구 규칙이 서버가 무엇을 쥐고 있는지 알려줍니다. 서버는 같은 제어 세션 안에서 다음 목적지 명령을 해석할 만큼의 원본 문맥을 받아들였습니다. 그러나 이식 가능한 트랜잭션 핸들을 발급하거나, 잠금을 약속하거나, 대상 이름을 예약하거나, 원본이 그대로 유지될 것을 보증하지는 않았습니다.

"바로 이어서(immediately)"라는 말이 중요합니다.RNTO는 바로 앞의RNFR이 지정한 파일을 가리킵니다. 필수 선행 명령 없이 온RNTO는503 Bad sequence of commands를 받을 수 있습니다. 두 명령을 연결 기준으로 분리하거나, 순서를 남기지 않거나, 명령 본문만 기록한 로그는 표준의 상태 기계를 재구성할 수 없습니다.

따라서 최소 세 가지 구별되는 사실이 있습니다. 클라이언트가 원본의 이름을 바꾸려 했다는 사실, 서버가 대기 중인 원본 단계를 수락했다는 사실, 그리고 서버가 나중에 목적지 단계를 완결했거나 거부했다는 사실입니다. 이름 바꾸기가 성공했다는 프로토콜 수준 주장은 마지막 사실만이 뒷받침할 수 있습니다.

350과 250이 하나의 성공 버킷에 담길 수 없는 이유

RFC 959에 따르면 2xx 응답은 긍정적 완결입니다. 요청된 동작이 성공적으로 끝났으며 새 요청을 시작할 수 있다는 뜻입니다.250은 요청된 파일 동작이 무사히 완료되었음을 뜻하도록 정의되어 있습니다. 반면350은 동작이 추가 정보를 기다리는 중이라고 명시합니다.

많은 운영 시스템은 두 응답 모두 4나 5로 시작하지 않는다는 이유로 둘을 "성공"으로 뭉뚱그립니다. 그러면 응답 문법이 담은 가장 강한 정보가 사라집니다. 첫 자리 숫자는 단순히 만족도를 매기는 것이 아니라 상태 전이를 기술합니다.

RNFR에 대한350은 시퀀스를 계속할 수 있는 허가입니다.RNTO에 대한250은 완결의 근거입니다. 최종 응답을 잃어버렸다면 클라이언트는 불분명한 결과를 안고 있으므로, 무엇을 반복할지 정하기 전에 네임스페이스를 먼저 확인해야 합니다. 기억해 둔350에서 다시 실행하는 것은 내구적인 트랜잭션 토큰을 이어받는 것이 아닙니다. 프로토콜 자체의 실패 규칙은 시작점으로 되돌아가라고 가리킵니다.

원본 권한과 목적지 권한은 서로 달랐다

원래 명령 쌍은 두 개의 경로 결정을 내포하지만,RFC 3659는 이후perm사실을 통해 이 구분을 더 명확하게 만들었습니다.

객체에 붙은 권한 표시자f는 그 객체가RNFR의 대상이 될 수 있음을 말합니다. 디렉터리에 붙은 권한c는 그곳에 파일을 생성할 수 있으며, 그 디렉터리 안의 이름에 대해RNTO가 성공할 가능성이 높음을 말합니다. 원본 객체와 목적지 컨테이너는 서로 다른 예측된 능력을 노출하는 것입니다.

"성공할 가능성이 높다"는 표현은 의도적으로 약속보다 약합니다. 목록은 관찰 시점에 현재 FTP 사용자가 무엇을 할 수 있어 보이는지를 기술할 뿐입니다. 목적지를 예약하거나, 정책을 고정하거나, 경합을 제거하거나, 최종 명령 응답을 대체하지는 않습니다.

이 점은 FTP를 넘어 의미가 있습니다. 한 주체는 어떤 객체를 해제하거나 이름을 바꿀 수 있으면서도 모든 목적지에 이름을 만들 수는 없을 수 있습니다. 이 검사들을 포괄적인 "편집 가능" 플래그로 묶는 시스템은 위임을 기저 동작보다 넓게 만들어버립니다.

경계가 있는 객체 근거가 남아 있는 가운데 이름은 바뀔 수 있었다

RFC 3659는 선택적인Unique사실도 정의했습니다. 서버가 이를 제공할 때, 같은 기저 파일을 가리키는 경로명은 같은 불투명 토큰을 담아야 하고, 서로 다른 파일은 서로 다른 토큰을 담아야 합니다. 이 대응은 적어도 제어 연결의 수명 동안 일관되어야 합니다.

그 실습 예제는 특히 유용합니다. 목록은 하나의 Unique 값과 함께mlst.c를 보여줍니다. 클라이언트는RNFR mlst.c에 대해350을 받고,RNTO list.c를 보내며250을 받습니다. 이후 목록은 같은 Unique 값과 함께list.c를 보여줍니다. 경로명은 바뀌었지만 서버의 경계가 있는 객체 토큰은 그대로였습니다.

근거 경계는 엄격합니다. 서버는 어떤 MLSx 사실이라도 지원할 의무가 없습니다. Unique 토큰은 전역 식별자도, 내용 해시도, 영구 이름도 아닙니다. 이 예제는 모든 구현이 모든 이름 바꾸기 이후 그런 토큰을 보존한다는 것을 증명하지 않습니다. 이름 전이와 기저 객체 비교를 분리할 수 있는 어휘가 존재함을 보여줄 뿐입니다.

그것은 경로를 비교하는 것보다 강한 감사 모델입니다. 동작 전에 근거는 원본 경로를 객체 토큰에 묶을 수 있고, 완결이 확인된 뒤에는 목적지 경로를 같은 토큰에 묶을 수 있습니다. 이름 바꾸기 응답은 프로토콜 동작을 증명하고, 선택적 토큰은 객체 연속성 주장을 강화합니다. 어느 쪽도 다른 쪽을 대체하지 않습니다.

필수 어휘가 파일시스템 보장은 아니었다

RFC 1123은 FTP 호스트 명령 요구사항에RNFR과RNTO를 유지했습니다. 이후RFC 5797은 두 명령을 필수 기본 명령에 포함시키고 레지스트리 클래스를 부여했습니다.IANA FTP Commands and Extensions 레지스트리는 그 항목들을 보존하고 있습니다.

이 기록들은 상호운용 가능한 프로토콜 어휘를 조율합니다. 특정 이름 바꾸기가 동시 읽기 관점에서 원자적인지, 목적지를 덮어쓸 수 있는지, 기존 경로와 새 경로가 파일시스템 경계를 넘는지, 저장소가 언제 내구화되는지, 서버가 장애 뒤에 어떻게 동작하는지는 명시하지 않습니다. 또한 어떤 공개 서버가 오늘날 그 명령을 허용하는지도 증명하지 않습니다.

좁은 주장이면 충분합니다. FTP는 클라이언트와 서버가 대기 중인 원본 선택과 완결된 이름 바꾸기를 구별하도록 요구했습니다. 그 명령 경계 아래의 모든 것은 구현과 정책에 대한 근거에 맡겨져 있었습니다.

두 이름 사이의 파일

이 오래된 명령 쌍은 제어 평면의 모델로서 살아남았습니다. 다단계 변경은 종종 서버가 "계속 진행할 만큼은 유효하다"고 말하는 것으로 시작됩니다. 그 응답은 커밋이 아니더라도 유용할 수 있습니다.

좋은 시스템은 중간 상태에 이름을 붙이고, 그것을 하나의 세션이나 트랜잭션에 묶고, 무엇이 그것을 무효화하는지 밝히며, 완결 언어는 완결 근거에만 사용합니다. 또한 원본에 대한 권한과 목적지에 대한 권한을, 그리고 기저 파일과 현재 표시 이름을 구별합니다.

FTP의350은 약한 성공이 아니었습니다. 그것은 정밀한 비최종 성공이었습니다. 파일은 새 경로명이 아니라 프로토콜 시퀀스에 들어선 것이었습니다. 이름 바꾸기는 아직 일어나지 않았고, 응답 코드가 그렇게 말하고 있었습니다.

출처