.png)
a읽기 위해 파일을 연다고 가정해 보겠습니다 . 애플리케이션(이렇게 부르자)이 무작위 간격으로 해당 파일에 쓰면 aWriter어떻게 될까요 ? 열어서 읽으 려고 하면 a잘못된 파일 내용을 받을 수 있나요 ?동시에 aWriter새로운 줄을 작성 중입니다. 파일은 어떻게 되며, 파일을 읽어서 얻은 콘텐츠는 어떻게 됩니까?
또 다른 상황. b100줄의 텍스트가 포함된 파일이 있다고 가정해 보겠습니다 . bWriter무작위로 쓰는 응용 프로그램 도 있습니다 . b파일의 처음 80줄을 삭제하고 싶습니다 b. bWriter글을 쓰고 싶다고 가정하면 , b열어본 이후에도 글을 쓸 수 있나요? 포기하고 쓰기 내용을 잃게 될까요?
Syslog 관련 Perl 스크립트를 작성하고 있어서 이런 질문을 드립니다. Syslog에 모든 로그를 파일에 기록하도록 지시했으며 스크립트는 (5분마다) 파일의 내용을 읽고 다른 작업을 수행한 다음 파일의 모든 줄을 삭제하고 이전 줄을 아카이브에 써야 합니다. 저는 이 파일을 스크립트와 로그의 최종 위치 사이의 중간 단계로 사용합니다.
누구든지 그것이 정확히 어떻게 작동하는지에 대한 통찰력을 줄 수 있습니까?
답변1
두 프로세스가 쓰기를 위해 동일한 파일 핸들을 열 수 있습니다. 여느 것과 마찬가지로 마지막으로 처형하는 사람이 승리합니다.
한 프로세스가 파일 핸들을 열고 다른 프로세스가 여기에 80줄을 쓰면 첫 번째 프로세스의 메모리 버퍼에는 이러한 80줄이 없습니다. 이후에 버퍼가 파일 핸들에 기록되면 파일의 내용은 단순히 두 번째 메모리 버퍼의 내용이 됩니다.
그런데 요즘 많은 프로그램에서는 원본 파일 내용이 마지막으로 열린 이후 변경되었음을 감지합니다. 일부는 쓰기를 거부하고 일부는 버퍼를 다시 로드하라는 메시지를 표시합니다. 일부는 다른 일을 할 수도 있습니다. 모든 프로그램에는 올바른 일을 수행하는지 확인할 책임이 있습니다. 커널/파일 시스템은 신경 쓰지 않으며 80라인이 누락된 메모리 버퍼가옳은복사.
이제 홈 디렉토리에 있는 일부 텍스트 파일이나 문서뿐만 아니라 데이터베이스와 같이 더 중요한 것이라면 파일 잠금을 사용할 가능성이 더 높습니다(잠금을 말하지 않거나 사용하지 않는다는 뜻이기도 함 vim) gedit. 데이터베이스에는 자체 내부 잠금 메커니즘이 있을 수도 있습니다.
UNIX 스타일 플랫폼의 일반적인 아이디어는 파일 핸들 쓰기에 대해 공동 작업을 수행하는 것입니다. 잠금은 보안 제어 메커니즘(권한/ACL의 목적)이 아니라 데이터 무결성 메커니즘입니다. 데이터를 쓰려는 두 프로그램은 일반적으로 데이터가 올바르게 기록되었는지 확인하기를 원하므로 서로의 잠금을 존중하는 것이 두 당사자 모두에게 이익이 됩니다. 커널/파일 시스템은 잠금에 대해 경고하지만 여전히 각 프로세스가 최선이라고 생각하는 작업을 수행하도록 허용합니다. 그러나 Linux는 설치 옵션으로 잠금 적용을 지원합니다(파일 시스템 지원이 필요할 수도 있지만 확실하지 않습니다).
잠금에 대해 자세히 알아볼 수 있습니다.Wikipedia 파일 잠금기사.