기술 · 실용 가이드
rsync가 코드 23으로 끝나나요? 권한 변경 전에 실패 객체를 찾으세요
코드 23은 하나 이상의 전송 오류를 뜻할 뿐 권한 진단이 아닙니다. 앞선 오류를 객체·측·작업·계정에 연결하고 의도한 집합이 도착했는지 증명합니다.
마지막 코드 23 줄은 요약입니다. 권한, 제외 또는 rsync 옵션을 바꾸기 전에 전체 출력을 보존하고 첫 구체적 실패를 찾으세요.
실패 객체, sender 또는 receiver/generator, 파일 작업, errno와 유효 계정을 한 장부에 기록합니다. 그 경계만 고치고 실제 명령과 의도한 집합을 검증합니다.
정확한 실행과 전체 로그를 보존하세요
양 끝점, 전체 명령, rsync 버전, 원격 사용자, 작업 디렉터리와 종료 상태를 기록합니다. 처음부터 stdout/stderr를 저장하거나 client log를 사용하세요. 마지막 23은 요약입니다.
sudo, chmod -R 777, 넓은 제외나 ignore부터 하지 마세요. 실패 객체를 알기 전에 identity와 scope가 달라집니다.
첫 구체적 실패를 분류하세요
각 오류의 정확한 path, sender/receiver/generator, open/stat/mkdir/write/rename/metadata 작업과 errno 문구를 적습니다.
원격 인증, protocol 오류와 코드 24는 별도 분기입니다. permission과 failed verification은 다른 test와 repair가 필요합니다.
같은 계정으로 객체를 재현하세요
원본은 부모 traverse, lookup, link target, read를 확인합니다. 대상은 임시 이름으로 traverse, create, write, close, rename과 필요한 metadata 작업을 확인합니다.
rsync와 같은 local/remote 계정, mount, container 또는 service context를 사용합니다. 기록한 작업에 필요한 공간, inode, quota, read-only, ACL과 mapping만 점검합니다.
증명된 경계만 수정하세요
재현한 owner, ACL, mount, capacity, missing path 또는 option mismatch를 최소 범위로 고칩니다. 제외는 누락이 의도이고 transfer contract를 명시적으로 바꿀 때만 사용합니다.
version-specific verification bug라면 지원되는 fixed build나 제한된 option으로 비교하고 일반 permission 해결책으로 확대하지 않습니다.
의도한 집합 전달을 증명하세요
수정 뒤 같은 의도의 실제 transfer를 실행해 code 0을 요구합니다. dry-run과 itemized changes로 예상 밖의 남은 작업을 찾고 더 강한 내용 증명이 필요할 때만 checksum I/O를 사용합니다.
dry-run은 데이터를 보내지 않고 같은 system call 실패를 만나지 않을 수 있어 실제 실행을 대체하지 못합니다. 실제 성공과 manifest 무누락으로 종료합니다.
