SQLite와 8+3 파일 이름

SQLite의 기본 구성은 기본 파일시스템이 긴 파일 이름을 지원한다고 가정해요.

SQLite는 데이터베이스 파일에 어떤 이름 규칙도 강요하지 않아요. SQLite는 어떤 파일 이름 확장자를 가진 데이터베이스 파일이나 확장자가 전혀 없는 파일과도 잘 동작해요.

롤백 저널이나 write-ahead 로그, 또는 다른 종류의 임시 디스크 파일을 위한 보조 파일이 필요할 때, 보조 파일의 이름은 보통 데이터베이스 파일 이름 끝에 접미사를 붙여서 만들어진답니다. 예를 들어 원래 데이터베이스가 "app.db"라면 롤백 저널은 "app.db-journal", write-ahead 로그는 "app.db-wal"이라고 불러요. 이런 보조 파일 이름 지정 방식은 긴 파일 이름을 지원하는 시스템에서는 잘 동작해요. 하지만 8+3 파일 이름 제약을 적용하는 시스템에서는 원래 데이터베이스 파일이 8+3 형식을 갖추고 있어도 보조 파일은 8+3 형식에 맞지 않아요.

출처: 문서

본문

파일시스템 변경 (Changing Filesystems)

이 문제에 대한 권장 해결책은 다른 파일시스템을 선택하는 것이에요. 요즘에는 긴 파일 이름을 지원하는 고성능·신뢰성·무특허 파일시스템의 선택지가 매우 넓어요. 가능하다면 임베디드 장치는 이 중 하나의 파일시스템을 사용하는 것이 권장돼요. 이렇게 하면 호환성 문제와 8+3 파일 이름의 불일치한 사용으로 인한 데이터베이스 손상의 위험을 피할 수 있어요.

8+3 파일 이름을 사용하도록 SQLite 조정 (Adjusting SQLite To Use 8+3 Filenames)

일부 장치는 이전 버전과의 호환성이나 다른 비기술적 요인 때문에 8+3 파일 이름 제약이 있는 오래된 파일시스템을 사용해야 해요. 이런 상황에서 SQLite가 다음과 같이 8+3 패턴에 맞는 보조 파일을 사용하도록 강제할 수 있어요.

SQLite 라이브러리를 컴파일 타임 옵션 SQLITE_ENABLE_8_3_NAMES=1 또는 SQLITE_ENABLE_8_3_NAMES=2로 컴파일하세요. 8+3 파일 이름 지원은 약간의 오버헤드를 도입하기 때문에 SQLite에 기본적으로 포함되지 않아요. 오버헤드는 아주 작지만, 그렇다고 해도 8+3 파일 이름 지원이 필요 없는 수십억 개의 SQLite 애플리케이션에 부담을 주고 싶지 않아요.
SQLITE_ENABLE_8_3_NAMES=1 옵션을 사용한다면 SQLite는 8+3 파일 이름을 사용할 수 있지만 그 기능은 비활성화되어 있어요. 각 데이터베이스 연결에 대해 URI 파일 이름을 사용해 데이터베이스 파일을 열거나 ATTACH할 때 URI에 "8_3_names=1" 쿼리 매개변수를 포함시켜 각 연결마다 별도로 활성화해야 해요. SQLITE_ENABLE_8_3_NAMES=2로 컴파일하면 8+3 파일 이름이 기본으로 활성화되어 이 단계를 건너뛸 수 있어요.
데이터베이스 파일 이름이 8+3 파일 이름 형식을 따르고 빈 이름이나 확장자가 없도록 하세요. 즉 데이터베이스 파일 이름은 기본 이름에 1~~8자, 확장자에 1~~3자를 포함해야 해요. 빈 확장자는 허용되지 않아요.

위 단계를 사용하면 SQLite는 확장자의 마지막 3자만 사용해 파일 이름 확장자를 줄여요. 예를 들어 보통 "app.db-journal"이라고 불리는 파일은 "app.nal"로 짧아져요. 마찬가지로 "app.db-wal"은 "app.wal"이, "app.db-shm"은 "app.shm"이 돼요.

데이터베이스 파일 이름이 어떤 종류의 확장자를 가지는 것이 매우 중요하다는 점에 주의하세요. 확장자가 없으면 SQLite는 파일의 기본 이름에 붙여 보조 파일 이름을 만들어요. 따라서 "db01"이라는 이름의 데이터베이스는 "db01-journal"이라는 롤백 저널 파일을 가지게 돼요. 이 파일 이름은 3자로 줄일 확장자가 없으므로 그대로 사용되며 8+3 이름 규칙을 위반하게 돼요.

데이터베이스 손상 경고 (Database Corruption Warning)

데이터베이스 파일을 기본 긴 파일 이름이 아니라 8+3 이름으로 접근한다면, 매번 열 때마다 모든 데이터베이스 연결이 일관되게 8+3 이름으로 접근해야 해요. 그렇지 않으면 데이터베이스가 손상될 위험이 있어요.

보조 롤백 저널과 write-ahead 로그 파일은 SQLite가 크래시에서 복구할 수 있게 하는 데 필수적이에요. 애플리케이션이 8+3 이름을 사용하다가 크래시가 나면, 크래시에서 안전하게 복구하는 데 필요한 정보가 ".nal" 또는 ".wal" 확장자를 가진 파일에 저장돼요. 다음에 그 데이터베이스를 열 애플리케이션이 "8_3_names=1" URI 매개변수를 지정하지 않으면 SQLite는 긴 파일 이름을 사용해 롤백 저널이나 write-ahead 로그 파일을 찾으려고 해요. 하지만 크래시가 난 애플리케이션이 8+3 이름으로 그 파일들을 저장했으므로 찾지 못할 거예요. 따라서 데이터베이스가 제대로 복구되지 못하고 손상될 가능성이 커요.

어떤 경우에는 8+3 파일 이름으로, 또 어떤 경우에는 긴 파일 이름으로 데이터베이스 파일을 사용하는 것은 핫 저널 삭제와 동등한 행위예요.

SQLite와 8+3 파일 이름