Gungume BLOG

2008년 2월호 마이크로소프트웨어 책을 보다가 "CFileFind 안에 진짜 MAX_PATH 버그" 라는 권용휘님의 기사를 보게되었다.

CFileFind 클래스를 종종 이용하기 때문에 기사를 유심히 봤는데 문제가 되는 부분은 CFileFind 클래스의 FindFile() 멤버함수에서 경로를 설정하는 부분중 MAX_PATH를 사용하는데 해당되는 부분에서 영어인 경우는 문제가 없는데 한글인 경우에 문제가 생긴다는 내용인것 같다.

기사의 내용을 참조해 설명하자면 NTFS와 윈도우 커널자체에서는 유니코드를 사용한다고한다. 즉 윈도우에서 폴더나 파일명을 지정할때는 최대 256자(확장자, '.', null문자 등 포함 최대 260자...)를 지정할 수 있는데, NTFS를 사용하는 경우는 유니코드를 사용하기 때문에 영어, 한글 모두 260자까지 사용가능하다.

이때 문제가 되는 부분이 함수내에서 TCHAR가 사용된 부분인데 MFC에서 문자 집합을 "멀티바이트 문자 집합 사용" 으로 지정을 해 놓으면 TCHAR 부분이 ANSI 상태로 컴파일이 되므로 260바이트로 설정이된다.

그런데 한글의 경우 영어와 달리 문자열이 260자인 경우에 유니코드와 ANSI 문자열 모두 520바이트이다. 영어인 경우는 ANSI 문자열의 경우 260바이트이기 때문에 별다른 문제가 없지만 한글의 경우는 문자열이 길어져서 ANSI 문자열 기준으로 260바이트가 넘는다면 처리과정에서 MAX_PATH의 최대값을 넘어가기 때문에 오류가 발생한다..

즉, 한글로 된 폴더나 파일명의 길이가 ANSI 문자열 기준으로 260바이트가 넘게되는 경우에 오류가 발생하는 문제가 있다.

기사를 보고 직접 테스트했을 때 VisualStudio 2005에서 테스트했는데 기사내용처럼 문제가 생겼었고, 문자 집합을 "유니코드 문자 집합 사용"으로 설정한 경우는 정상작동을 했다.

아래는 마이크로소프트웨어에 있는 권용휘님 기사의 일부와 CFileFind의 FindFile 함수의 일부~.

BOOL CFileFind::FindFile(LPCTSTR pstrName /* = NULL */,
	DWORD dwUnused /* = 0 */)
{
	.
	.
	LPTSTR pstrRoot = m_strRoot.GetBufferSetLength(_MAX_PATH);
	LPCTSTR pstr = _tfullpath(pstrRoot, pstrName, _MAX_PATH);

	// passed name isn't a valid path but was found by the API
	ASSERT(pstr != NULL);
	.
	.

}