파일명 규칙은 코드 한 줄로 만들 수 있습니다. 하지만 실행하는 순간부터는 다른 문제입니다. 두 파일이 같은 이름으로 바뀌거나, 대소문자만 다른 이름을 파일 시스템이 같게 보거나, 클라우드 동기화가 중간 상태를 올릴 수 있습니다. 따라서 대량 작업은 이름 제안, 충돌 검사, 임시 실행, 복원 확인, 실제 승인으로 나눕니다.
실제 사용자 파일을 넘겨보지 않았습니다.
실험 코드는 운영체제의 임시 영역에 새 폴더를 만들고, 세 파일을 직접 생성했습니다. 사용자 문서·다운로드·클라우드 폴더를 인자로 받지 않았습니다.
report final.txt -> 01-report-final.txt
00123.csv -> 02-00123.csv
한글 메모.md -> 03-한글-메모.md예정표를 실행한 뒤 이름을 역순으로 되돌렸습니다. 복원 후 이름 3개와 내용 SHA-256 3개가 전부 일치했습니다.
목표 이름 중복은 쓰기 전에 멈추게 합니다.
A?.txt와 A*.txt에서 기호를 대시로 바꿀 때 둘 다 a-.txt가 될 수 있습니다. 코드는 이 충돌 예제를 stop-before-write로 기록합니다. 이 단계에서는 어느 파일도 바꾸지 않아야 전체 원상 복구가 쉽습니다.
- 목표 이름끼리 중복
- 기존 파일과의 충돌
- 대소문자를 무시하는 파일 시스템
- Unicode NFC/NFD 차이
- Windows 예약 이름·현재 경로 길이
실제 폴더는 자동 승인하지 않습니다.
- 읽기 전용으로 예정표를 만들고 작업 폴더 밖에 저장합니다.
- 충돌·권한·동기화 상태를 확인합니다.
- 새 임시 복사본에서 일부만 실행하고 복원을 해시로 확인합니다.
- 예정표를 사람이 확인한 뒤에만 실제 범위를 점진적으로 늘립니다.
이 글의 재현 자료
전체 자료의 범위·실행 방법·주의사항은 재현 자료 안내에서 한번에 확인할 수 있습니다.
원문과 함께 읽기
목표 이름으로 바로 옮기지 않습니다.
대규모 이름 변경에서는 원본→임시 고유 이름→최종 이름의 두 단계를 사용할 수 있습니다. 원본 A의 목표가 현재 B의 이름과 같은 경우, A를 먼저 옮기면 B와 충돌합니다. 모든 파일을 임시 고유 이름으로 옮긴 뒤 최종 이름으로 옮기면 이런 교환 충돌을 줄일 수 있습니다.
그러나 두 단계 변경도 목표 이름 중복·기존 파일·권한·심볼릭 링크를 자동으로 해결하지는 못합니다. 이름 변경 전에 예정표를 검토하고, 임시 이름 규칙이 기존 파일과 충돌하지 않는지 확인해야 합니다.
복원 명세서는 실행 전에 완성합니다.
| 필드 | 이유 |
|---|---|
| source_path | 원본 위치를 정확히 복원 |
| source_hash | 내용이 바뀌지 않았는지 확인 |
| temporary_path | 중간 실패 시 현재 위치 찾기 |
| target_path | 최종 목표와 충돌 검사 |
| status | planned·moved-temp·moved-final·rolled-back |
| error | 중단 원인과 수동 확인 항목 |
코드가 중간에 멈춰을 때 파일 시스템만 보고 상태를 추측하지 않도록, 각 이동을 성공한 직후에 상태를 기록합니다. 로그는 원본 폴더와 다른 위치에 저장해 같은 작업으로 이름이 바뀌지 않게 합니다.
클라우드 동기화 폴더는 임시 실험과 다른 환경입니다.
파일 이름 변경은 삭제와 생성의 조합으로 동기화될 수 있고, 다른 기기의 편집과 충돌할 수 있습니다. 따라서 로컬 임시 폴더에서의 성공을 클라우드 폴더의 승인으로 보지 않습니다. 동기화 일시정지·복원 기능·버전 기록·다른 사용자의 편집 여부를 해당 제품의 방식으로 따로 확인합니다.
