Skip to content
isdnetworks
Go back

로그의 경로를 바꾸면 없던 일이 생긴다

작업 폴더를 다른 계정으로 옮기면서 옛 홈 경로가 박힌 곳을 한 번에 바꾸려 했다. 목록을 세어 보니 천 개가 넘었다.

Table of contents

Open Table of contents

천 개가 넘는다는 숫자

그 숫자를 보고 잠깐 멈췄는데 이 프로젝트에 설정 파일이 그렇게 많을 리가 없었다. 저장소 메타와 의존성 폴더와 로그와 기록 폴더를 제외하고 다시 셌다.

한 개가 나왔고 그마저도 원격에서 목록 명령을 돌린 출력을 붙여 둔 임시 파일이었다. 나머지는 전부 실행 로그와 대화 기록이었다.

설정값과 사실의 차이

여기서 구분이 갈렸다. 설정 파일에 적힌 경로는 앞으로 무엇을 쓸지를 정하는 값이므로 바뀌면 바꿔야 한다.

로그에 적힌 경로는 그때 실제로 그 경로였다는 기록이다. 같은 문자열인데 하나는 앞으로의 지시이고 다른 하나는 지나간 사실이라 성격이 정반대다.

실행 순서를 뒤집었다

원래 순서는 전체를 치환하고 결과를 확인하는 것이었다. 제외 조건을 걸어 진짜 대상 건수를 먼저 산출하고 남은 건이 코드인지 기록인지 문맥까지 확인한 뒤에 치환하는 순서로 바꿨다.

앞의 두 단계를 합쳐도 몇 분이었다. 그 몇 분이 천 개의 기록을 지키는 값이었다.

이진 파일이라는 함정

검색에서 이진 파일을 제외하는 옵션을 붙인 것에도 이유가 있다. 그 옵션이 없으면 이진 파일 안의 우연한 일치까지 목록에 들어오고 치환하면 파일이 깨진다.

빌드 산출물이나 캐시가 섞여 있으면 특히 그렇다. 다시 만들면 되는 것들이라 깨져도 그 자리에서는 티가 안 나다가 나중에 원인 모를 오류로 나온다.

되돌릴 수 있는 것과 없는 것

설정 파일 치환은 잘못돼도 원래 값을 알고 있으므로 다시 바꾸면 된다. 로그 치환은 원래 값이 그 로그에만 있었으므로 바꾸는 순간 원본이 사라진다.

치환한 이력을 근거로 판단하는 사람은 일어나지 않은 일을 사실로 읽게 된다. 되돌릴 수 없는 쪽에 해당하면 실행 전에 한 번 더 세는데 이번 건은 세어 보니 결국 아무것도 치환하지 않았다.

정리


Share this post on:

Previous Post
자동으로 채워지지 않는 데이터
Next Post
로그인과 인증 사이