파일 잠금

File locking

파일 잠금은 컴퓨터 파일 또는 파일 영역에 대한 액세스를 제한하는 메커니즘입니다.특정 시간에 한 명의 사용자 또는 프로세스만 파일을 수정 또는 삭제할 수 있으며 파일이 수정 또는 삭제되는 동안 파일을 읽을 수 없도록 합니다.

시스템은 업데이트 프로세스의 시리얼화를 지정된 파일에 적용함으로써 전형적인 레이스 조건의 예인 기존의 인터셉트 업데이트 시나리오를 방지하기 위해 잠금을 구현합니다.다음 예시는 인터시딩 업데이트 문제를 나타내고 있습니다.

  1. 프로세스 A는, 고객의 어카운트 잔액이나 전화 번호를 포함한 어카운트 정보를 포함한 파일로부터 고객 레코드를 읽어냅니다.
  2. 프로세스 B는 동일한 파일에서 동일한 레코드를 읽기 때문에 자체 복사본을 가집니다.
  3. 프로세스 A는 고객 레코드 복사본에서 계정 잔액을 변경하고 레코드를 파일에 다시 씁니다.
  4. 프로세스 B는 고객 레코드의 복사본에 계정 잔액의 원래 오래된 값을 여전히 가지고 있으며, 계정 잔액을 갱신하고 고객 레코드를 파일에 다시 씁니다.
  5. 이것으로 프로세스 B는 오래된 계정 잔액 값을 파일에 기입하여 프로세스A에 의한 변경이 없어집니다.

대부분의 운영체제는 레코드 잠금 개념을 지원합니다.즉, 특정 파일 내의 개별 레코드가 잠길 수 있기 때문에 동시 업데이트 프로세스의 수가 증가합니다.데이터베이스 유지보수는 파일 잠금을 사용하여 데이터베이스의 기반이 되는 전체 물리적 파일에 대한 액세스를 직렬화할 수 있습니다.이로 인해 다른 프로세스가 파일에 액세스할 수 없지만 각 잠금을 취득하고 해제하는 오버헤드를 제거함으로써 파일 내의 많은 영역을 개별적으로 잠그는 것보다 효율적일 수 있습니다.

다른 컴퓨터 잠금과 마찬가지로 파일 잠금을 잘못 사용하면 성능이 저하되거나 교착 상태가 될 수 있습니다.파일 잠금이란 Windows 보안, NTFS 권한을 사용하거나 서드파티 파일 잠금 소프트웨어를 설치하여 컴퓨터 사용자가 적용하는 추가 보안을 의미할 수도 있습니다.

메인프레임 내

IBM은 1963년 OS/360을 사용하는 메인프레임 컴퓨터에서 사용하기 위해 파일 잠금을 개척했으며, 여기서 파일 잠금을 "배타적 제어"[1]라고 불렀습니다.

Microsoft Windows 의 경우

Microsoft Windows 에서는, 다음의 3개의 다른 메카니즘을 사용해 공유 파일에의 액세스를 관리합니다.

  1. 응용 프로그램이 읽기, 쓰기 또는 삭제를[2] 위해 전체 파일 액세스 공유를 지정할 수 있는 공유 액세스 제어 사용
  2. 바이트 범위 잠금을 사용하여 단일 파일[3] 내의 영역에 대한 읽기 및 쓰기 액세스 조정
  3. by Windows 파일 시스템에서 실행 중인 파일을 쓰기 또는 삭제 액세스에 대해 열지 못하도록 합니다.

Windows는 MS-DOS 3.3에서 공유가 도입된 MS-DOS 시스템으로부터 공유 액세스 제어의 의미를 계승합니다.따라서, 애플리케이션은 파일을 열 때 명시적으로 공유를 허용해야 합니다.그렇지 않으면, 닫힐 때까지 파일에 대한 배타적인 읽기, 쓰기 및 삭제 액세스 권한을 가집니다(예를 들면, 파일의 속성을 취득하는 액세스).파일이 허용됩니다.)

공유 액세스로 열려 있는 파일의 경우, 애플리케이션은 바이트 범위 잠금을 사용하여 파일의 특정 영역에 대한 액세스를 제어할 수 있습니다.이러한 바이트 범위 잠금은 파일의 영역(오프셋 및 길이)과 잠금 유형(공유 또는 배타적)을 지정합니다.잠겨 있는 파일의 영역은 파일 내에 데이터를 포함할 필요가 없으며, 애플리케이션은 이 기능을 이용하여 기능을 구현하는 경우가 있습니다.

Windows에서 파일 읽기/쓰기 API를 사용하는 응용 프로그램의 경우 Windows에서 실행되는 파일 시스템에 의해 바이트 범위 잠금(필수 잠금이라고도 함)이 적용됩니다.Windows에서 파일 매핑 API를 사용하는 응용 프로그램의 경우 바이트 범위 잠금(권고 잠금이라고도 함)은 적용되지 않습니다.바이트 범위 잠금은 Windows 시스템에 다른 부작용도 일으킬 수 있습니다.예를 들어, Windows 파일 공유 메커니즘은 바이트 범위 잠금이 클라이언트에서 사용되는 경우 일반적으로 모든 클라이언트의 파일 클라이언트 측 캐시를 비활성화합니다.읽기 및 쓰기 작업이 파일이 저장된 서버로 전송되어야 하므로 클라이언트는 액세스 속도가 느려집니다.

응용 프로그램에서의 부적절한 에러 처리는, 파일이 잠기고(「공유」액세스 또는 바이트 범위 파일 잠금 사용) 다른 응용 프로그램에서 액세스 할 수 없는 상황을 초래할 수 있습니다.이 경우, 사용자는 오작동하는 프로그램을 수동으로 종료함으로써 파일 액세스를 복원할 수 있습니다.이 작업은 일반적으로 태스크 관리자 유틸리티를 통해 수행됩니다.

의 공유 모드(dwShareMode) 파라미터CreateFile[2] function(파일 오픈에 사용)은 파일 공유를 결정합니다.공유 모드를 지정하여 읽기, 쓰기 또는 삭제 액세스 또는 이들의 조합을 위해 파일을 공유할 수 있습니다.이후 파일을 열려는 시도는 이전에 부여된 모든 공유 액세스와 호환되어야 합니다.파일이 닫히면 공유 액세스 제한이 조정되어 열려 있는 특정 파일에 의해 부과된 제한이 제거됩니다.

바이트 범위 잠금 유형은 의 파라미터에 의해 결정됩니다.LockFileEx[4] 파일의 영역을 잠그는 데 사용되는 함수입니다.Windows API 기능LockFile[5] 를 사용하여 파일 영역에 대한 배타적 잠금을 획득할 수도 있습니다.

컴퓨터 시스템에서 프로그램으로 현재 실행 중인 실행 가능한 프로그램 파일을 포함하는 파일(예:EXE, , 또는 기타 바이너리 프로그램 파일 형식)은 일반적으로 운영 체제 자체에 의해 잠기므로 응용 프로그램이 이를 수정하거나 삭제할 수 없습니다.프로그램 파일이 응용 프로그램에 의해 열리지 않는 경우에도 공유 위반 오류로 인해 모든 시도가 거부됩니다.그러나 일부 액세스는 여전히 허용됩니다.예를 들어 실행 중인 응용 프로그램 파일의 이름을 변경하거나 실행 중에도 복사(읽기)할 수 있습니다.

Windows 의 애플리케이션에서는, 파일 핸들을 사용해 파일에 액세스 합니다.이러한 파일 핸들은 프로세스 탐색기 유틸리티를 사용하여 탐색할 수 있습니다.이 유틸리티는 핸들을 유지하는 응용 프로그램을 종료할 필요 없이 핸들을 강제로 닫는 데도 사용할 수 있습니다.강제 종료 핸들을 사용하면 프로그램이 예기치 않은 오류를 수신하고 핸들 번호가 재사용될 수 있으므로 [citation needed]정의되지 않은 동작을 일으킬 수 있습니다.

Microsoft Windows XP 및 Server 2003 에디션에서는 볼륨 스냅샷이 도입되었습니다.VSS)의 기능을 통해 NTFS에 접속할 수 있습니다.백업 소프트웨어에서 열려 있는 파일에 액세스 할 수 있습니다.다만, 이 기능을 서포트하도록 소프트웨어를 고쳐 쓰지 않는 한, 스냅샷은 크래시 정합성이 유지되는 것에 한정해, 적절히 서포트되고 있는 애플리케이션은, operating system이 「트랜잭션 정합성이 있는」스냅샷을 작성하는 것을 서포트할 수 있습니다.Windows에서 잠긴 파일에 액세스하기 위한 기타 상용 소프트웨어로는 File Access Manager와 Open File Manager가 있습니다.커널 모드에서 파일에 액세스하기 위해 자체 드라이버를 설치하는 방식으로 작동합니다.

Unix 계열 시스템

Unix와 유사한 운영 체제(Linux 및 Apple의 MacOS 포함)는 일반적으로 열려 있는 파일을 자동으로 잠그지 않습니다.여러 종류의 파일 잠금 메커니즘을 다양한 버전의 Unix에서 사용할 수 있으며, 많은 운영 체제가 호환성을 위해 여러 종류를 지원합니다.가장 일반적인 메커니즘은fcntl기타 두 가지 메커니즘은 다음과 같습니다.lockf(3)(개별 또는 위에서 구현할 수 있음)fcntl일부 유형의 잠금을 필수로 구성할 수 있지만 Unix에서 파일 잠금은 기본적으로 권장됩니다.즉, 협력 프로세스는 서로 간에 파일에 대한 액세스를 조정하기 위해 잠금을 사용할 수 있지만, 비협력 프로세스는 잠금을 무시하고 원하는 방식으로 파일에 액세스할 수 있습니다.즉, 파일 잠금은 I/O가 아닌 다른 파일 잠금 장치만 잠급니다.

공유 잠금과 전용 잠금 두 가지 종류의 잠금 장치가 제공됩니다.의 경우fcntl, 파일의 다른 섹션(바이트 범위) 또는 파일 전체에 다른 종류의 잠금을 적용할 수 있습니다.공유 잠금은 여러 프로세스에서 동시에 유지할 수 있지만 배타적 잠금은 한 프로세스에서만 유지할 수 있으며 공유 잠금과 공존할 수 없습니다.공유 잠금을 취득하려면 프로세스가 배타적 잠금을 보유하지 않을 때까지 대기해야 합니다.배타적 잠금을 취득하려면 프로세스가 어느 쪽도 잠금을 보유하지 않을 때까지 대기해야 합니다.에 의해 작성된 잠금과는 달리fcntl, 에 의해 작성된 것flock에 걸쳐 보존되어 있다fork서버 포킹에 도움이 됩니다.따라서 이들 프로세스가 효자관계를 공유하고 배타적 잠금이 처음에 1개의 프로세스로 작성된 후 여러 프로세스 간에 복제될 경우 동일한 파일에 대한 배타적 잠금이 유지될 수 있습니다.fork.

공유 잠금은 "읽기 잠금"이라고도 하며 배타적 잠금은 "쓰기 잠금"이라고도 합니다.단, Unix의 잠금은 권장사항이기 때문에 강제되지 않습니다.따라서 데이터베이스에는 "공유 쓰기"와 "배타적 쓰기"라는 개념이 있을 수 있습니다. 예를 들어, 공유 액세스에서는 필드를 변경할 수 있지만, 가비지 수집 및 다시 쓰기는 배타적 액세스가 필요할 수 있습니다.

파일 잠금은 파일 이름이 아닌 실제 파일에 적용됩니다.Unix 에서는, 복수의 이름이 같은 파일을 참조할 수 있기 때문에, 이것은 중요합니다.비필수 잠금과 함께 여러 프로세스에서 파일에 액세스할 수 있는 뛰어난 유연성을 제공합니다.한편, 공동 잠금 방식은 프로세스가 다른 프로세스에 의해 설정된 파일 잠금을 따르지 않고 파일에 쓸 때 문제를 일으킬 수 있습니다.

이러한 이유로 일부 Unix 계열 운영 체제에서는 의무 [6]잠금이 제한적으로 지원됩니다.이러한 시스템에서는, 다음의 파일,setgidbit는 켜져 있지만 해당 파일을 열 때 그룹 실행 비트가 꺼져 있는 경우 기본 파일 시스템이 지원하는 경우 자동 필수 잠금이 적용됩니다.그러나 로컬이 아닌 NFS 파티션은 이 [7]비트를 무시하는 경향이 있습니다.파일이 필수 잠길 경우 배타적 잠금으로 잠긴 영역에서 읽거나 공유 또는 배타적 잠금으로 잠긴 영역에 쓰기를 시도하면 잠금이 해제될 때까지 차단됩니다.이 전략은 System V에서 처음 시작되었으며 현재 Solaris, HP-UX 및 Linux 운영 체제에서 볼 수 있습니다.그러나 POSIX의 일부가 아니며 FreeBSD, OpenBSD, NetBSD 및 Apple의 macOS와 같은 BSD에서 파생된 운영 체제에서는 [8]지원되지 않습니다.Linux는 파일 시스템 마운트용 특수 파라미터를 통한 잠금도 지원합니다(mount(8))는 거의 사용되지 않습니다.

일부 Unix와 유사한 운영 체제에서는 실행 중인 프로그램의 실행 파일을 쓰기 위해 열려고 하지 않습니다. 이것은 세 번째 형태의 잠금이며, 다음 운영 체제와는 다릅니다.fcntl그리고.flock.

문제

둘 이상의 프로세스가 배타적 요소를 보유할 수 있습니다.flock나중에 배타적 잠금이 중복된 경우 특정 파일에 대해fork이것에 의해, 네트워크 서버의 코딩을 심플화해, 레이스 상황을 회피할 수 있습니다만, 모르는 사람에게는 혼란스러울 가능성이 있습니다.

필수 잠금 기능은unlink시스템 콜을 실행합니다.따라서 특정 프로그램은 사실상 강제 잠금을 회피할 수 있습니다.Stevens & Rago(2005)는 다음과 같이 말했다.ed편집자분께서도 [9]그러셨네요.

여부 및 방법flockNFS와 같은 네트워크 파일 시스템에서 작동하는 잠금 기능은 구현에 따라 다릅니다.BSD 시스템에서는flockNFS 마운트 파티션의 파일에 대해 열려 있는 파일 기술자의 콜은 no-ops 성공입니다.Linux 2.6.12 이전 버전에서는flockNFS 파일에 대한 호출은 로컬에서만 작동합니다.커널 2.6.12 이상의 실장flockPOSIX 바이트 범위 잠금을 사용하여 NFS 파일을 호출합니다.이러한 잠금은 구현된 다른 NFS 클라이언트에서 확인할 수 있습니다.fcntl- 스타일 POSIX 잠금 장치, 그러나 [10]잠금 장치에는 보이지 않습니다.

잠금 업그레이드 및 다운그레이드는 새 잠금을 적용하기 전에 이전 잠금을 해제합니다.다른 애플리케이션이 배타적 잠금을 기다리는 동안 응용 프로그램이 배타적 잠금을 공유 잠금으로 다운그레이드하면, 후자의 응용 프로그램은 배타적 잠금을 얻고 첫 번째 응용 프로그램을 잠글 수 있습니다.즉, 잠금 다운그레이드가 차단될 수 있으며 이는 직관에 반할 수 있습니다.

모든. fcntl특정 프로세스의 파일과 관련된 잠금은 해당 파일의 파일 기술자가 해당 프로세스에 의해 닫히면 해당 파일 기술자에 대한 잠금이 요청되지 않았더라도 제거됩니다.또한.fcntl잠금은 하위 프로세스에 의해 상속되지 않습니다.그fcntlclose semantics는 파일에 액세스할 수 있는 서브루틴 라이브러리를 호출하는 어플리케이션에서 특히 문제가 됩니다.이러한 "버그"는 모두 실제를 사용하여 발생하지 않습니다.flock- 스타일의 잠금 장치.

UNIX 도메인 소켓을 사용하여 다른 프로세스에 전달된 열린 파일 기술자의 잠금 상태 보존은 구현에 따라 달라집니다.

버퍼링된 I/O 문제

버퍼링된 I/O에 운영 체제 버퍼 풀이 아닌 사용자의 로컬 워크스페이스에 버퍼가 할당되어 있는 경우 잠금 실패의 한 원인이 발생합니다. fread그리고.fwrite버퍼링된 I/O를 수행하기 위해 일반적으로 사용되며, 파일의 한 섹션을 읽으면 동일한 섹션을 다시 읽으려고 시도하면 로컬 버퍼에서 데이터를 얻을 수 있습니다.같은 파일에 접속되어 있는 다른 사용자가 자신의 로컬버퍼를 가지고 있는데, 이 사용자에게도 같은 일이 일어나고 있다는 것이 문제입니다.안fwrite버퍼에서 얻은 데이터의fread파일 자체에서 데이터를 가져오지 않으며 다른 사용자가 데이터를 변경했을 수 있습니다.둘 다 사용할 수 있습니다.flock배타적 액세스의 경우 동시 쓰기를 방지하지만 파일 자체가 아닌 버퍼에서 읽기를 수행하므로 사용자 #1이 변경한 모든 데이터는 사용자 #2에 의해 손실될 수 있습니다(덮어쓰기).이 문제에 대한 최선의 해결책은 버퍼링되지 않은 I/O를 사용하는 것입니다.read그리고.write)와 함께flock즉,lseek대신fseek그리고.ftell물론 함수 파라미터와 반환되는 결과에 대한 조정이 필요합니다.일반적으로 버퍼링된 I/O는 공유 파일과 함께 사용하면 안전하지 않습니다.

인아미가OS

AmigaOS 에서는, 파일(또는 디렉토리)의 잠금을 취득할 수 있습니다.Lock기능하다dos.library잠금을 공유하거나(다른 프로세스는 파일/디렉토리를 읽을 수 있지만 수정 또는 삭제할 수 없음), 또는 잠금을 성공적으로 획득한 프로세스만 개체에 액세스하거나 수정할 수 있도록 배타적으로 설정할 수 있습니다.그 자물쇠는 그것의 일부가 아니라 전체 물체에 있다.잠금장치는 다음과 같이 해제해야 합니다.UnLockfunction: UNIX와 달리 운영체제는 프로세스가 종료될 때 암묵적으로 오브젝트의 잠금을 해제하지 않습니다.

파일 잠금

셸 스크립트 및 기타 프로그램에서는 종종 파일 잠금 사용법과 유사한 전략을 사용합니다.파일 잠금 파일 작성은 내용이 무관하고(종종 파일 내의 잠금 홀더의 프로세스 식별자를 발견하지만), 유일한 목적은 일부 리소스가 잠겨 있음을 알리는 것입니다.제어할 리소스가 일반 파일이 아니므로 파일을 잠그는 방법을 사용할 필요가 없는 경우 잠금 파일이 가장 좋은 방법입니다.예를 들어 잠금 파일은 여러 개의 서로 다른 파일, 디렉터리, 디스크 파티션 그룹 또는 서버 또는 데이터베이스 연결과 같은 고급 프로토콜에 대한 선택된 액세스와 같은 관련 리소스 집합에 대한 액세스를 제어할 수 있습니다.

잠금 파일을 사용할 때는 작업이 원자성이 되도록 주의해야 합니다.잠금을 얻으려면 잠금 파일이 존재하지 않는지 확인한 후 생성해야 하며, 그 사이에 다른 프로세스가 잠금을 생성하지 않도록 해야 합니다.여기에는 다음과 같은 다양한 방법이 있습니다.

  • 사용방법lockfile명령어(로 배포되는 조건부 세마포 파일 작성자)procmail패키지)
  • 파일을 생성하지만 파일이 이미 존재하는 경우 실패하는 시스템콜(시스템 콜은 C 또는 C++ 등의 언어에서 사용할 수 있으며 셸 스크립트는 noclobber를 사용할 수 있습니다.)
  • 사용방법mkdir명령어 및 종료 코드의 장애[11] 확인

잠금 파일의 이름은 보통 칠드(tilde)로 지정됩니다.~잠글 파일 이름 앞에 접두사를 붙이거나 전체 파일 이름에 접두사를 붙입니다..LCK파일 이외의 자원을 잠그고 있는 경우는, 보다 임의로 이름을 붙일 수 있습니다.

특정 Mozilla 제품(Firefox, Thunderbird, Sunbird 등)은 이러한 유형의 파일 리소스 잠금 메커니즘을 사용합니다("parent.lock"이라는 임시 파일 사용).

언락러 소프트웨어

언락러는 어떤 프로세스가 파일을 잠그고 있는지를 판별하기 위해 사용되는 유틸리티로 프로세스 목록과 프로세스 처리(킬 태스크, 잠금 해제 등)에 대한 선택사항이 삭제 또는 이름 변경 등의 파일 옵션 목록과 함께 표시됩니다.일부 Unix 계열 시스템에서는 다음과 같은 유틸리티가 있습니다.fstat그리고.lockf는, 프로세스별, 파일명별, 또는 [citation needed]양쪽 모두의 파일 잠금 상태를 검사하기 위해서 사용할 수 있습니다.

Windows 시스템에서는, 파일이 잠겨 있는 경우, 다음의 재기동시에 이동 또는 삭제를 실행하도록 스케줄 할 수 있습니다.이 방법은 일반적으로 설치 관리자가 잠긴 시스템 파일을 교체하기 위해 사용합니다.

버전 관리 시스템

버전 관리 시스템에서는 파일 잠금을 사용하여 두 사용자가 동일한 파일 버전을 병렬로 변경하는 것을 방지하고 저장 시 두 번째 사용자가 첫 번째 사용자가 변경한 내용을 덮어씁니다.이는 파일 시스템에서 잠긴 파일을 읽기 전용으로 표시함으로써 구현됩니다.파일 변경을 원하는 사용자는 잠금 해제(체크아웃이라고도 함) 조작을 실행하고 체크인(스토어) 조작이 실행되거나 잠금이 반환될 때까지 누구도 파일의 잠금을 해제할 수 없습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ IBM System/360 Operating System: Job Control Language Reference (PDF). IBM. June 1971. pp. 162–164. GC28-6704-1.
  2. ^ a b "CreateFileW function". Windows Software Development Toolkit. Microsoft Docs. windows-sdk-content. Microsoft Corporation. Retrieved 2018-11-07.
  3. ^ "LockFileEx function". Windows Software Development Toolkit. Microsoft Docs. windows-sdk-content. Microsoft Corporation. Retrieved 2018-11-07.
  4. ^ "LockFileEx function". Windows Software Development Toolkit. Microsoft Docs. windows-sdk-content. Microsoft Corporation. Retrieved 2020-07-05.
  5. ^ "LockFile function". Windows Software Development Toolkit. Microsoft Docs. windows-sdk-content. Microsoft Corporation. Retrieved 2020-07-05.
  6. ^ "Mandatory File Locking for the Linux Operating System". kernel.org. Documentation / File Systems. Retrieved 2011-10-08.
  7. ^ "Use Setuid, Setgid, and Sticky Bits with Server for NFS". cc731734(WS.10). Retrieved 2011-10-08.
  8. ^ Viega, John; Messier, Matt (2003). "2.8 Locking Files". Secure Programming Cookbook for C and C++ (1st ed.). Sabastopol, CA: O'Reilly Media. p. 792. ISBN 978-0-596-00394-4. Support for mandatory locks varies greatly from one Unix variant to another. Both Linux and Solaris support mandatory locks, but Darwin, FreeBSD, NetBSD, and OpenBSD do not, even though they export the interface used by Linux and Solaris to support them. On such systems, this interface creates advisory locks. Support for mandatory locking does not extend to NFS.
  9. ^ Stevens, W. Richard; Rago, Stephen A. (27 June 2005). Advanced Programming in the UNIX Environment (Second ed.). Addison-Wesley Professional. p. 456. ISBN 978-0201433074.
  10. ^ "Commonly occurring error messages". nfs.sourceforge.net. Linux NFS FAQ: D. Source Forge.
  11. ^ "Lock your script (against parallel run)".

외부 링크

  • 파일 잠금, UNIX 파일 잠금 옵션 및 그 문제에 대해 알고 싶지 않은 모든 것(2010년 12월 13일 날짜)
  • 파일 개인 POSIX 잠금: 상속 및 종료 시 동작에 대해 POSIX 잠금과 다르게 동작하는 Linux에서 지원되는 파일 잠금에 대한 LWN.net 기사