버전이 아니었던 버전 필드

출처를 모르는 데이터 파일 백업이 여러 개 있었고 분류하려면 버전을 알아야 했다. 덤프 도구로 내용을 뽑아 버전 레코드를 찾으니 알 수 없는 값 하나가 들어 있었다.

Open Table of contents

상수 목록과의 불일치

이 프로젝트는 포맷 세대를 상수 목록으로 정의하고 있었다. 뽑은 값은 그 목록 어디에도 없었고 가장 큰 상수보다도 훨씬 큰 숫자였다.

웹에서 그 값을 찾아도 안 나왔고 상수 목록을 다시 대조해도 여전히 안 맞았다. 내가 모르는 최신 상수가 있는지 아니면 다른 구현체인지를 뒤지면서 한참 헤맸다.

거기서 멈춰 생각하니 이 필드가 포맷 버전이라는 것 자체가 내 전제였다. 필드 이름이 버전이라고 해서 그것이 포맷 버전이라는 보장은 없다.

여기서 질문이 바뀌었다. 상수 목록은 그 프로젝트의 소스에 있으므로 부족할 리가 없고 대조가 완전히 실패하면 대조 대상이 틀린 것이다.

그래서 프로젝트 소스를 직접 받아 그 값을 저장하는 코드를 찾았다. 거기서는 포맷 버전이 아니라 클라이언트 버전 상수를 쓰고 있었다.

그 상수를 따라가니 주 버전과 부 버전과 빌드 번호를 자릿수로 조합하는 계산식이었다. 역산하니 특정 판이 나왔고 해당 태그의 소스로 확인했다. 즉 그 값은 이 파일을 마지막으로 연 클라이언트의 버전이었다.

그러면 포맷 세대는 어디에 있는지도 이어서 찾아봤다. 최소 버전을 담는 별도 필드가 있었고 그 값이 상수 목록과 정확히 맞아떨어졌다.

결국 필드가 둘이었고 내가 처음부터 엉뚱한 쪽을 보고 있었던 것이다. 헤맨 흐름을 정리하면 이름을 보고 포맷 버전이라고 가정했고 대조가 실패하자 목록이 부족한지를 물었는데 거기서 전제가 틀렸는지를 물었어야 방향이 맞았다.

검색으로는 안 나오던 것이 소스를 받아 읽으니 30분 만에 풀렸다. 경로는 저장하는 코드를 찾아 무슨 값을 쓰는지 보고 그 값의 정의로 내려간 뒤 계산식이면 역산하는 순서다.

원래 목적으로 돌아가면 이 값이 오히려 유용했다. 그 백업을 마지막으로 연 클라이언트 버전을 알 수 있으므로 출처를 모르는 파일들을 그 값으로 분류할 수 있었다. 틀린 전제로 읽었으면 이 쓸모도 못 봤을 것이다.