안전한 unlink 방법에 대해서..
글쓴이: aswip / 작성시간: 토, 2006/04/29 - 9:56오전
특정 스레드에서 다음과 같이 쓰기 락을 걸어놓은 상태에서..
fl.l_type= F_WRLCK;
fl.l_whence = SEEK_SET;
fl.l_start = 0;
fl.l_len = 0;
if ( fcntl(nFD, nMode, &fl) != -1 )
... 이 하 생 략 ...임의의 또 다른 쓰레드에서, 위에서 락이 걸린 파일에 대해서 unlink을
할 경우, 실제로 파일이 삭제됩니다.
제가 예상한 결과는 어느 한쪽이 락을 걸고 있기 때문에, unlink가 fail이
될 것 같았는데, 그게 아니더라구요. ^^;;;
움.. 이러한 상황이 비단 저에게만 찾아오지는 않았을 거 같다는 생각과,
좀 더 현명한 해답을 찾기위해서 이렇게 질문을 올립니다. ^^
좀 더 Smart 한 Unlink 방법 없을까요?
Forums:
fcntl(F_SETLK)을 이용한
fcntl(F_SETLK)을 이용한 락킹은 "mandatory"가 아닌 "advisory" 방식입니다. 즉, 고의 또는 실수로 fcntl(F_SETLK)을 호출하지 않음으로써 다른 프로세스가 락을 획득한 것을 무시할 수 있습니다. 따라서 unlink()를 실행하기 전에 명시적으로 락을 확인해 주셔야 합니다.
읽어도그만안읽어도그만류의 영양가 없는 내용을 추가하자면...
advisory locking의 약점이 분명하기에 모든 프로세스에 적용되는 mandatory locking을 원하는 이들이 있었고, 따라서 구현도 되어 있습니다. fcntl(2) manpage의 "Mandatory locking" 절에 나오는 내용이 그것입니다. 하지만 이 방법은 대상 파일이 포함된 파일시스템을 마운트 할 때 "mand" 옵션을 줘야 하고, 대상 파일에 g-x+s 속성을 줘야 한다는 제한이 있습니다. 더불어 강제적 락의 영향을 받는 시스템 호출 종류에 unlink()는 포함되어 있지 않습니다.
다른 유닉스 계열 운영체제에선 unlink() 호출시 다른 프로세스가 파일을 사용하고 있으면 실패하면서 EBUSY를 반환한다고 하지만 리눅스에서는 다르게 동작합니다. unlink()는 일단 성공하고, 파일을 사용하던 프로세스가 파일을 닫으면 그 때 파일이 실제로 삭제됩니다. (물론 ls 등으로 확인해 보면 unlink() 직후부터 파일이 사라진 것처럼 '보이며' 따라서 다른 프로세스가 새로 파일을 여는 것이 불가능합니다.)
----
$PWD `date`
$PWD `date`
advisory locking의 문제가 맞군요.
답변 감사합니다. ^^
결국 그 방법밖에는 없군요.
가장 처음 위에서 언급한 문제에 직면하였을 당시에, 저도 잠깐 고민 한 후,
다음과 같이 구현하였습니다.
if ( !IsLocked ( ... ) ) unlink( ... );어디까지나 개인적인 생각입니다만.. 아무리 advisory locking의 약점이라
할지라도, unlink() 라는 함수는 그 약점에 대해서 인지하고, 다음과 같이
충분한 Lock 체크를 해야 하는것이 맞지 않을까요?
예를 들면 다음과 같습니다.
int unlink(const char *pszPath) { if ( Islocked(pszPath) ) return error("file is busy"); unlink(...); }unlink() 안쪽에서 수행해주어야 할일을, unlink() 바깥쪽에서
수행하고 있다는 생각을 지워버릴수가 없네요. ^^;;
- 인생은 스스로 -
댓글 달기