2013-07-03 1 views
0

(로그) 파일을 볼 수있는 코드를 작성 중입니다. 메모장 ++를 사용하여 파일을 업데이트합니다.
변경 이벤트를 수신하고 때때로 파일을 읽는 데 주변에 lock 문이 있어도 파일이 잠길 수 있습니다.
StreamReader 또는 FileStream은 파일을 릴리스하지만 운영 체제 (win8 with dotnet4.5.1)는 이 잠시 더 잠금을 유지합니다?왜 내가 FileSystemWatcher.Changed 및 StreamReader 또는 FileStream을 잠글 때 (...) {...} 그 파일을 잠글까요?

나는 Changed 이벤트가 twice이라고하는 경고를 알고 있지만 lock 문은이를 처리해야합니다. 나는 생각했다. 지금까지.

private static object _fileLock = new Object(); 
.. 
_watch.Changed += new FileSystemEventHandler(watch_Changed); 
.. 
void watch_Changed(object sender, FileSystemEventArgs e) 
{ 
    lock (_fileLock) 
    { 
     using (var sr = new FileStream(_pathAndFilename, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)) 
     { 
      // read in file... 
      sr.Close(); 
     } 
    } 
} 
+2

lock 문은 파일과 아무 관련이 없습니다. C#에는 파일 관련 기능이 없습니다. 그것은 너무 전문화 될 것입니다. – usr

답변

3

로킹의 개념을 심각하게 혼동하고 있습니다. Changed 이벤트 핸들러의 문은 다른 스레드가 공유 리소스를 사용하지 못하도록하는 잠금 장치입니다. 귀하의 스 니펫에 이러한 리소스가 사용 된 것을 볼 수 없습니다.

파일 잠금은 완전히 다른 종류의 동물입니다. FileShare 열거 형은 관련성이 있습니다. 다른 코드가 파일에 어떤 종류의 액세스 권한을 가지고 있는지 말합니다. 코드를 다른 프로세스에 포함 시키면 키워드로 절대로 존재하지 않습니다. FileShare.ReadWrite를 사용하면 코드에 매우 관대합니다. 다른 프로세스가 파일을 읽고 쓸 수 있습니다. 조금은 걱정할 필요가있는 부분이 있습니다. 코드를 읽는 동안 다른 프로세스가 파일에 쓸 수있을 때 코드가 제대로 작동합니까? 즉, 파일 데이터를 읽는 동안 으로 변경하면 처리 할 수 ​​있습니까? 아주 귀엽다.이 파일로 다른 프로세스가 무엇을하고 있는지 알 필요가있다. 또한 테스트하기가 매우 어렵습니다.

실제 문제에 대한 소개는 충분합니다. FileSystemWatcher.Change 이벤트는 으로 실행되고은 다른 프로세스에서 파일을 쓰는 중입니다. 이벤트 처리기에서 해당 파일을 열 수 있으려면 파일을 연 프로세스가 요청한 액세스 종류에 대한 공유 권한을 부여해야합니다. 귀하의 경우에는 적어도 FileShare.Read를 지정해야 FileAccess.Read 액세스 권한을 가질 수 있습니다.

항상 그렇다고 생각하지 마십시오. 파일을 작성하는 프로그래머에 대한 아주 건전한 추론은 "다른 사람이 내가 쓸 때이 파일을 올바르게 읽을 수있는 방법이 없습니다"라는 것입니다. 따라서 그는 FileShare.None을 지정합니다. Kaboom을 코드로 열면 안됩니다.

당신이 할 수있는 일은 아무 것도 없었습니다. 다른 프로그래머가 당신이 할 수 없다는 말입니다. 매우 높은 확률로 그는 그것에 대해 완전히 정확했습니다.

나중에 파일을 읽음으로써이 문제를 해결할 수 있습니다. 파일을 쓰고있는 프로세스가 끝난 후에. 파일의 경로를 기억하고 스레드 안전 큐에 넣으십시오. 이제 잠금 문을 사용할 수 있습니다. 정기적으로 타이머를 사용하여 파일을 다시 열어보십시오.