파일 잠금

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
- 2.1. 메인프레임
3. 운영체제별 구현
4. 버전 관리 시스템
5. 잠금 파일 (Lock files)
6. Unlocker software
7. 기타 구현
참조

1. 개요

파일 잠금은 여러 프로세스가 동시에 파일에 접근하는 것을 제어하기 위한 메커니즘이다. 1963년 IBM의 OS/360에서 배타 제어라는 이름으로 처음 구현되었다.

Windows는 공유 액세스 제어, 바이트 단위 잠금, 실행 중인 파일에 대한 쓰기/삭제 거부 등 세 가지 방식으로 파일 접근을 관리하며, 파일 핸들 조작을 통해 파일에 접근한다. 유닉스 계열 운영 체제는 `flock`과 같은 파일 잠금 기능을 제공하지만, 버퍼링된 I/O 사용 시 주의가 필요하다. AmigaOS는 `Lock` 함수를 사용하여 파일 잠금을 구현하며, 잠금은 전체 개체에 적용된다. 버전 관리 시스템은 파일 잠금을 사용하여 동시 변경을 방지한다.

잠금 파일은 파일 잠금 방식이 어려운 경우에 사용되는 대체 기술로, 파일의 존재 여부만으로 리소스가 잠겨 있음을 나타낸다. 잠금 해제 도구는 잠긴 파일을 확인하고 관리하는 데 사용된다. TRON, Java, C/C++ 등 다른 운영체제 및 프로그래밍 언어에서도 파일 잠금 기능을 구현한다.

더 읽어볼만한 페이지

파일 시스템 - 부트 섹터
부트 섹터는 시스템 부팅 코드를 담은 저장 매체의 특정 영역으로, 볼륨 부트 레코드(VBR)와 마스터 부트 레코드(MBR)로 나뉘며, BIOS는 이를 실행하고 UEFI는 부트로더를 직접 로드하지만 바이러스 공격에 취약하다.
파일 시스템 - ZFS
ZFS는 Jeff Bonwick 등이 설계하고 구현한 파일 시스템으로, 데이터 무결성, 스냅샷, RAID-Z 등의 기능을 제공하며, 썬 마이크로시스템즈에서 개발되어 OpenZFS 프로젝트를 통해 다양한 운영체제에서 사용된다.

파일 잠금
파일 잠금
유형	동기화 메커니즘
사용 목적	동시에 여러 프로그램이 파일에 접근하는 것을 방지
관련 용어	데드락 경쟁 조건
상세 정보
설명	파일 잠금은 컴퓨터 운영 체제가 제공하는 동기화 메커니즘의 일종으로, 동시에 여러 프로그램이 파일에 접근하는 것을 방지한다. 이 메커니즘은 파일 내용의 일관성을 유지하고 데이터 손상을 방지하는 데 사용된다.
동작 방식	한 프로그램이 특정 파일에 잠금을 설정하면, 다른 프로그램은 해당 파일에 접근하거나 수정할 수 없다. 잠금을 설정한 프로그램이 파일을 사용한 후 잠금을 해제하면, 다른 프로그램이 해당 파일에 접근할 수 있게 된다.
주의 사항	파일 잠금을 사용할 때 데드락이나 경쟁 조건과 같은 문제가 발생할 수 있으므로 주의해야 한다.
파일 잠금의 종류
배타적 잠금 (Exclusive Lock)	한 프로그램만 파일에 쓰기 작업을 할 수 있도록 허용하는 잠금 방식.
공유 잠금 (Shared Lock)	여러 프로그램이 동시에 파일을 읽을 수 있도록 허용하는 잠금 방식. 하지만 쓰기 작업은 불가능하다.
권고적 잠금 (Advisory Locking)	운영체제가 강제하지 않고, 프로그램들이 자발적으로 잠금 규칙을 따르도록 하는 방식.
강제적 잠금 (Mandatory Locking)	운영체제가 잠금 규칙을 강제하는 방식. 권고적 잠금보다 더 강력한 데이터 보호를 제공한다.
파일 잠금의 문제점
데드락 (Deadlock)	여러 프로그램이 서로의 잠금 해제를 기다리면서 무한정 대기하는 상태.
경쟁 조건 (Race Condition)	여러 프로그램이 동시에 파일에 접근하려고 시도할 때, 실행 순서에 따라 예상치 못한 결과가 발생하는 문제.
파일 잠금의 활용
데이터베이스 관리 시스템 (DBMS)	여러 사용자가 동시에 데이터베이스에 접근할 때 데이터의 일관성을 유지하기 위해 파일 잠금을 사용한다.
파일 공유 시스템	여러 사용자가 동시에 파일을 공유하고 수정할 때 데이터 손상을 방지하기 위해 파일 잠금을 사용한다.
운영 체제	시스템 파일에 대한 접근을 제어하고 시스템의 안정성을 유지하기 위해 파일 잠금을 사용한다.

2. 역사

2. 1. 메인프레임

IBM은 1963년에 OS/360을 사용하는 메인프레임 컴퓨터에 사용하기 위해 파일 잠금을 구현하였는데, 이 기능의 이름은 배타 제어(exclusive control)이다.^[1]

3. 운영체제별 구현

3. 1. 마이크로소프트 윈도우

Windows에서의 공유 파일 액세스는 다음 세 가지 메커니즘으로 관리됩니다.^[2]^[3]

# 공유 액세스 제어를 사용하여 애플리케이션에 파일 전체에 대한 읽기/쓰기/삭제 권한을 부여합니다.

# 바이트 단위 잠금을 사용하여 파일 내의 일부에 대한 읽기/쓰기를 조정합니다.

# Windows의 파일 시스템은 실행 중인 파일에 대해 쓰기 또는 삭제를 위해 여는 것을 거부합니다.

Windows에서의 공유 액세스 제어는 MS-DOS 3.3에서 도입된 것을 계승하고 있습니다. 애플리케이션은 명시적으로 공유를 허용하거나, 파일에 대해 독점적인 읽기/쓰기/삭제를 수행합니다. 다른 액세스 유형으로는 파일 속성에 대한 액세스를 허용하는 것 등이 있습니다.^[2]

공유 액세스가 있는 파일에 대해 애플리케이션이 바이트 단위 잠금을 사용하여 파일의 특정 영역에 대한 액세스를 제어하는 경우도 있습니다. 바이트 단위 잠금은 파일의 일부(오프셋 및 길이)와 잠금 유형(공유 또는 배타)을 지정합니다. 잠금되는 영역이 실제 파일 크기에 맞을 필요는 없으며, 이 기능을 활용하는 애플리케이션도 있다는 점에 유의해야 합니다.^[3]

Windows에서 파일의 읽기/쓰기 API를 사용하는 애플리케이션의 경우, Windows 내의 파일 시스템이 강제로 바이트 단위 잠금을 설정합니다(''필수 잠금''이라고도 함). Windows에서 파일 매핑 API를 사용하는 애플리케이션의 경우, 바이트 단위 잠금은 강제되지 않습니다(''권고 잠금''이라고도 함). 바이트 단위 잠금에는 다른 부작용도 있습니다. 예를 들어, Windows의 파일 공유 메커니즘에서는 클라이언트가 파일 액세스 시 바이트 단위 잠금을 걸면 자동으로 모든 클라이언트의 파일 캐시를 비활성화합니다. 이 때문에 읽기/쓰기 요청이 모두 파일 서버상의 실제 파일에 대해 수행되므로 파일 액세스가 느려진 것처럼 느껴집니다.

애플리케이션의 오류 처리에 버그가 있으면 파일이 잠겨(공유 액세스 또는 바이트 단위 잠금) 다른 애플리케이션에서 액세스할 수 없게 됩니다. 이때, 잘못 동작하는 프로그램을 수동으로 종료하면 파일 액세스가 가능해질 것입니다. 이는 일반적으로 "[Windows 작업 관리자"를 사용하여 수행합니다.

파일의 공유 모드는 Windows API의 함수 CreateFile()^[12]에서 파일을 열 때 인자 ''dwShareMode''로 지정합니다. 파일을 열 때 읽기/쓰기/삭제 액세스와 관련하여 파일을 공유할 것을 허용합니다. 그 후의 동일한 파일의 열기는 이전에 열린 파일에서 허용된 유형만 허용됩니다. 파일을 닫으면 해당 닫기에 대응하는 열기의 설정된 공유 액세스 제한이 해제됩니다.

바이트 단위 잠금 유형은 API 함수 LockFileEx()^[13]에서 파일의 일부 영역을 잠글 때 인자 ''dwFlags''로 지정합니다. API 함수 LockFile()^[14]은 파일의 일부를 독점적으로 잠그는 데 사용할 수 있습니다.

프로그램으로 실행되는 파일(예: EXE, COM, DLL, CPL 등)은 일반적으로 쓰기/삭제 액세스를 위한 열기를 할 수 없도록 파일 시스템이 제한하며, 공유 위반 (sharing violation)이 보고됩니다. 그러나, 어떤 종류의 액세스는 허용됩니다. 예를 들어, 실행 중인 애플리케이션의 파일을 이름 변경하거나 복사(읽기)하는 것은 가능합니다.

Windows에서 애플리케이션은 "파일 핸들"의 조작을 통해 파일에 액세스할 수 있습니다. 앞서 언급한 API 함수 CreateFile()이 반환하는 HANDLE형은, Win32/Win64에서는 범용 포인터 void*의 별칭으로 정의되어 있으며, 내부적으로 존재하는 객체 유형에 대한 불투명한 참조입니다^[15]^[16]. 읽기/쓰기 작업을 마치고 필요 없어진 파일 핸들은, API 함수 CloseHandle()^[17]로 닫고, 시스템 리소스를 해제해야 합니다. 마이크로소프트가 배포하는 Process Explorer^[18]를 사용하면, 실행 중인 각 애플리케이션이 이용하고 있는 파일 핸들을 표시하거나, 애플리케이션을 강제 종료 (terminate) 시키지 않고 사용 중인 파일 핸들을 강제로 닫을 수 있습니다.

Windows XP 이후에는 NTFS에 볼륨 스냅샷 기능이 도입되었습니다. 이는 열려 있고 독점적으로 잠겨 있는 파일을 포함하여 백업 소프트웨어가 액세스할 수 있도록 하는 기능입니다. 단, 이 기능에 대응하도록 다시 쓰여진 소프트웨어가 아니면, 생성되는 스냅샷은 일관성이 없는 것이 됩니다(예: 파일의 일부만 다시 쓰여지는 등). 이 기능을 제대로 지원하는 백업 애플리케이션은 운영 체제의 기능을 사용하여 "처리상의 일관성"(transactionally consistent^영어)을 유지하는 스냅샷을 생성할 수 있습니다. 그 외에 잠긴 파일에 액세스할 수 있는 상용 소프트웨어로 File Access Manager 와 Open File Manager 가 있습니다.

Windows에서, 잠금이 걸리는 것은, 삭제와 파일 내용의 읽기 및 쓰기에 대해서만 해당하며, 그 외의, 폴더 내의 파일 목록이나 파일의 속성 읽기/쓰기 등의 조작에 대해서는, 잠금이 걸리지 않습니다. Vista 이후에는 트랜잭션 NTFS (TxF) 가 있으며, 여러 파일에 대한 일관된 조작을 위한 기능이 제공되고 있습니다^[19]. 다만, 나중에 TxF는 권장되지 않으며, 미래 버전의 Windows에서 제거될 가능성도 있다고 합니다.

3. 2. 유닉스 계열 운영 체제

wikitext

파일 잠금 실패의 한 가지 원인은 버퍼링된 I/O가 운영 체제 버퍼 풀이 아닌 사용자의 로컬 작업 공간에 할당된 버퍼를 갖는 경우에 발생한다. `fread`와 `fwrite`는 버퍼링된 I/O를 수행하는 데 일반적으로 사용되며, 파일의 한 섹션을 읽으면 해당 섹션을 다시 읽으려는 시도는 거의 대부분 로컬 버퍼에서 데이터를 가져온다. 문제는 동일한 파일에 연결된 다른 사용자가 자체 로컬 버퍼를 가지고 있으며, 그들에게도 동일한 상황이 발생한다는 것이다. `fread`에 의해 버퍼에서 가져온 데이터를 `fwrite`하면 '''''파일 자체에서''''' 데이터를 가져오지 않으며, 다른 사용자가 변경했을 수도 있다. 둘 다 동시에 쓰기를 방지하는 독점적 액세스를 보장하기 위해 `flock`을 사용할 수 있지만, 읽기는 파일 자체가 아닌 버퍼에서 읽으므로 사용자 #1에 의해 변경된 데이터는 사용자 #2에 의해 손실(덮어쓰기)될 수 있다.

이 문제에 대한 최상의 해결책은 `flock`과 함께 언버퍼링된 I/O(`read` 및 `write`)를 사용하는 것이며, 이는 `fseek` 및 `ftell` 대신 `lseek`를 사용하는 것을 의미하기도 한다. 물론, 함수 매개변수와 반환된 결과에 대한 조정을 해야 한다. 일반적으로 말해서, 버퍼링된 I/O는 공유 파일과 함께 사용될 때 ''안전하지 않다''.

3. 2. 1. POSIX 문제점

wikitext

여러 프로세스가 후속 `fork`를 통해 독점 잠금이 복제된 경우, 주어진 파일에 대해 독점 `flock`을 가질 수 있다. 이는 네트워크 서버 코딩을 단순화하고 경합 조건을 방지하는 데 도움이 되지만, 이를 모르는 사람에게는 혼란스러울 수 있다.

필수 잠금은 `unlink` 시스템 호출에 영향을 미치지 않는다. 결과적으로, 특정 프로그램은 사실상 필수 잠금을 우회할 수 있다. Stevens & Rago (2005)는 `ed` 편집기가 실제로 그렇게 한다는 것을 관찰했다.^[9]

`flock` 잠금이 NFS와 같은 네트워크 파일 시스템에서 작동하는지 여부와 방식은 구현에 따라 다르다. BSD 시스템에서 NFS로 마운트된 파티션의 파일에 대해 열린 파일 디스크립터에 대한 `flock` 호출은 성공적인 무효 작업이다. 리눅스 2.6.12 이전 버전에서 NFS 파일에 대한 `flock` 호출은 로컬에서만 작동했다. 커널 2.6.12 이상에서는 POSIX 바이트 범위 잠금을 사용하여 NFS 파일에 대한 `flock` 호출을 구현한다. 이러한 잠금은 `fcntl` 스타일 ''POSIX 잠금''을 구현하는 다른 NFS 클라이언트에 표시되지만, 그렇지 않은 클라이언트에는 표시되지 않는다.^[10]

잠금 업그레이드 및 다운그레이드는 새 잠금을 적용하기 전에 이전 잠금을 ''해제''한다. 다른 애플리케이션이 독점 잠금을 대기하면서 차단된 상태에서 애플리케이션이 독점 잠금을 공유 잠금으로 다운그레이드하면, 후자의 애플리케이션이 독점 잠금을 얻고 첫 번째 애플리케이션을 잠글 수 있다. 이는 잠금 다운그레이드가 차단될 수 있음을 의미하며, 이는 직관적이지 않을 수 있다.

주어진 프로세스에 대한 파일과 관련된 ''모든'' `fcntl` 잠금은 해당 파일에 대한 ''모든'' 파일 디스크립터가 해당 프로세스에 의해 닫힐 때 제거된다. 심지어 해당 파일 디스크립터에 대해 잠금을 요청하지 않은 경우에도 마찬가지이다. 또한, `fcntl` 잠금은 자식 프로세스에 상속되지 않는다. `fcntl` 닫기 의미 체계는 파일을 액세스할 수 있는 서브루틴 라이브러리를 호출하는 애플리케이션에 특히 문제가 된다. 이러한 "버그"는 실제 `flock` 스타일 잠금을 사용하면 발생하지 않는다.

유닉스 도메인 소켓을 사용하여 다른 프로세스에 전달된 열린 파일 디스크립터의 잠금 상태 유지는 구현에 따라 다릅니다.

`flock`과 `fcntl`에는 다른 운영 체제에 익숙한 프로그래머가 보기에는 기이한 점이 있다.

`flock`은 네트워크 파일 시스템 등의 분산 파일 시스템에서는 구현에 따라 작동하지 않는 경우가 있다. BSD에서는 아무 일도 일어나지 않고, Linux에서는 오류가 발생한다. 같은 파일에 대한 (하나의 프로세스로부터의) `flock` 호출은 잠금 상태를 변경한다 (공유에서 배타적으로, 또는 배타적에서 공유로). 그러나 이때 일시적으로 이전 잠금을 해제한 다음 새 잠금을 건다. 예를 들어, 배타적 잠금에서 공유 잠금으로 변경하려고 할 때, 순간적인 틈을 타서 다른 프로세스가 배타적 잠금을 걸면, 원래 잠금을 걸었던 프로세스가 쫓겨나게 된다.

프로세스는 하나의 파일에 대응하는 파일 디스크립터를 여러 개 가질 수 있다. 이 중 하나를 사용하여 `fcntl`로 잠금을 걸었다고 가정한다. 이때, 같은 파일에 대응하는 다른 파일 디스크립터를 닫으면, 해당 파일에 그 프로세스가 설정한 모든 잠금이 해제된다. 또한, `fcntl`의 잠금은 자식 프로세스에 상속되지 않는다. 이 `fcntl`의 닫기와 관련된 동작은, 라이브러리의 서브루틴 내에서 파일에 접근하는 경우가 많은 애플리케이션 등에서 문제를 일으키는 경우가 많다.

3. 2. 2. Buffered I/O 문제

파일 잠금 실패의 한 가지 원인은 버퍼링된 I/O가 운영 체제 버퍼 풀이 아닌 사용자의 로컬 작업 공간에 할당된 버퍼를 갖는 경우에 발생한다. `fread`와 `fwrite`는 버퍼링된 I/O를 수행하는 데 일반적으로 사용되며, 파일의 한 섹션을 읽으면 해당 섹션을 다시 읽으려는 시도는 거의 대부분 로컬 버퍼에서 데이터를 가져온다. 문제는 동일한 파일에 연결된 다른 사용자가 자체 로컬 버퍼를 가지고 있으며, 그들에게도 동일한 상황이 발생한다는 것이다. `fread`에 의해 버퍼에서 가져온 데이터를 `fwrite`하면 '''''파일 자체에서''''' 데이터를 가져오지 않으며, 다른 사용자가 변경했을 수도 있다. 둘 다 동시에 쓰기를 방지하는 독점적 액세스를 보장하기 위해 `flock`을 사용할 수 있지만, 읽기는 파일 자체가 아닌 버퍼에서 읽으므로 사용자 #1에 의해 변경된 데이터는 사용자 #2에 의해 손실(덮어쓰기)될 수 있다. 이 문제에 대한 최상의 해결책은 `flock`과 함께 언버퍼링된 I/O(`read` 및 `write`)를 사용하는 것이며, 이는 `fseek` 및 `ftell` 대신 `lseek`를 사용하는 것을 의미하기도 한다. 물론, 함수 매개변수와 반환된 결과에 대한 조정을 해야 한다. 일반적으로 말해서, 버퍼링된 I/O는 공유 파일과 함께 사용될 때 ''안전하지 않다''.

3. 3. AmigaOS

AmigaOS에서 파일(또는 디렉터리)에 대한 잠금은 `dos.library`에 있는 Lock 함수를 사용하여 획득할 수 있다. 잠금은 공유될 수 있으며(다른 프로세스는 파일/디렉터리를 읽을 수 있지만 수정하거나 삭제할 수 없음), 독점적으로 잠금을 성공적으로 획득한 프로세스만 개체에 접근하거나 수정할 수 있다. 잠금은 전체 개체에 적용되며 일부가 아니다. 잠금은 UnLock 함수로 해제해야 한다. 유닉스와 달리 운영 체제는 프로세스가 종료될 때 개체의 잠금을 암시적으로 해제하지 않는다.

4. 버전 관리 시스템

버전 관리 시스템에서 파일 잠금은 두 명의 사용자가 동시에 동일한 파일 버전을 변경하거나 저장 시 두 번째 사용자가 첫 번째 사용자의 변경사항을 덮어쓰지 못하게 한다. 이는 파일 시스템에서 잠금 파일을 읽기 전용으로 표시함으로써 구현된다. 파일을 변경하기를 원하는 사용자는 언락(체크아웃) 기능을 수행하며 체크인(스토어) 기능이 끝나거나 락이 반전될 때까지 당사자 이외에 아무에게도 파일 잠금의 해제가 허용되지 않는다.

5. 잠금 파일 (Lock files)

셸 스크립트 및 기타 프로그램은 파일 잠금과 유사한 전략을 사용하는 경우가 많다. 즉, 내용이 중요하지 않은(하지만 종종 파일에서 잠금 소유자의 프로세스 식별자를 찾을 수 있음) ''잠금 파일''을 생성하여 파일의 존재 여부만으로 일부 리소스가 잠겨 있음을 알린다.^[11] 잠금 파일은 제어할 리소스가 일반 파일이 아닌 경우, 따라서 파일 잠금 방식을 사용할 수 없는 경우 가장 좋은 방법이다. 예를 들어 잠금 파일은 여러 다른 파일, 디렉터리, 디스크 파티션 그룹 또는 서버나 데이터베이스 연결과 같은 상위 레벨 프로토콜에 대한 선택적 접근과 같은 관련 리소스 집합에 대한 접근을 제어할 수 있다.^[11]

잠금 파일을 사용할 때는 작업이 원자적으로 수행되도록 주의해야 한다.^[11] 잠금을 얻으려면 프로세스는 잠금 파일이 존재하지 않는지 확인한 다음 이를 생성해야 하며, 그동안 다른 프로세스가 이를 생성하지 못하도록 해야 한다. 이를 수행하는 다양한 방법에는 다음이 포함된다.^[11]

`lockfile` 명령 사용(procmail 패키지에 배포된 조건부 세마포어 파일 생성기).^[11]
파일을 생성하지만 파일이 이미 존재하면 실패하는 시스템 호출.(시스템 호출은 C 또는 C++와 같은 언어에서 사용할 수 있으며, 셸 스크립트는 noclobber를 사용할 수 있습니다)^[11]
`mkdir` 명령을 사용하고 실패에 대한 종료 코드를 확인^[11]

잠금 파일은 잠그는 파일 이름 앞에 물결표(`~`)를 붙이거나 전체 파일 이름을 `.LCK` 로 접미사로 붙여 이름을 지정하는 경우가 많다. 파일이 아닌 다른 리소스를 잠그는 경우 임의로 이름을 지정할 수 있다.^[11]

록 파일은 셸 스크립트와 같은 프로그램에서 파일 잠금의 대체로 사용되는 기법이다. 록 파일은 내용은 관계없으며 (단, 록 보유자의 프로세스 식별자를 기록해 두는 경우가 많다), 존재함으로써 다른 주체에게 어떤 자원이 잠겨 있음을 알리는 데 사용된다.^[11]

6. Unlocker software

잠금 해제 도구는 파일 잠금을 수행하는 프로세스를 확인하는 데 사용되는 유틸리티이다. 프로세스 목록과 함께 프로세스에 대한 작업(작업 종료, 잠금 해제 등) 선택 사항, 삭제 또는 이름 바꾸기와 같은 파일 옵션 목록을 표시한다. 그 목적은 충돌 또는 중단된 프로세스와 같이 소유 프로세스가 이미 종료되었음에도 파일 잠금이 지속되는 비정상적인 상황으로 인해 발생하는 부적절하거나 오래된 파일 잠금을 제거하는 것이다. 일부 유닉스 계열 시스템에서는 `fstat` 및 `lockf`와 같은 유틸리티를 사용하여 프로세스별, 파일 이름별 또는 둘 다를 기준으로 파일 잠금 상태를 검사할 수 있다.

Windows 시스템에서 파일이 잠겨 있으면 다음 재부팅 시 이동 또는 삭제를 예약할 수 있다. 이 방식은 일반적으로 잠긴 시스템 파일을 교체하기 위해 설치 프로그램에서 사용된다.

7. 기타 구현

7. 1. TRON

BTRON은 다른 주요 운영 체제와 근본적으로 다른 파일 시스템을 채택하고 있어, 엄밀히 말해 파일 잠금이라는 개념이 없다. 이 파일 시스템은 TAD라고 불리며, 가상체와 실체라고 불리는 요소로 구성된다.

가상체는 Windows 등의 환경에서의 아이콘과 같은 개념이지만, 하나의 가상체는 이중으로 열 수 없다. 한편, 실체는 파일의 실체이며, 하나의 실체에 여러 가상체를 존재시킬 수 있다. 만약 실체 안에 자신의 가상체를 만들면 루프가 생기고, 이 경우, 개별 BTRON 사양 OS의 구현을 별개로 한다면 이론상 메모리가 허용하는 한 무제한으로 열 수도 있게 된다. 이렇게 별개의 가상체에서 열린 동일 실체는, 어느 프로세스에서 갱신이 이루어지면, 이 갱신 정보를 기록하고, 동시에 열려 있던 "동일 실체"의 "다른 가상체"가 다시 저장을 시도하면 경고 알림을 보내 확인하는 구조로 되어 있다.

7. 2. Java

자바에서는 파일을 읽고 쓸 때, 윈도우상에서는 `FileInputStream`은 삭제 잠금이, `FileOutputStream`은 삭제 잠금과 쓰기 잠금이 걸린다. 명시적으로 읽기/쓰기 잠금을 사용하려면, `FileChannel`의 `lock()` 메서드를 사용한다.

7. 3. C/C++

C 언어의 표준 규격 C11 및 C++의 표준 규격 C++17에서는, `fopen()` 함수 및 `std::fopen()` 함수의 파일 액세스 모드 인수에 `w` 또는 `w+`를 지정할 때, 옵션으로 배타적 액세스 모드인 `x`를 지정할 수 있게 되었다^[24]^[25]。 이 옵션은 Microsoft Visual C++의 경우, 버전 2013 이전에는 구현되지 않았고^[26]^[27], 버전 2015 이후에 구현되었다^[28]^[29]。

참조

_[1] 서적 IBM System/360 Operating System: Job Control Language Reference http://www.bitsavers[...] IBM 1971-06-01
_[2] 웹사이트 CreateFileW function https://docs.microso[...] Microsoft Corporation 2018-11-07
_[3] 웹사이트 LockFileEx function https://docs.microso[...] Microsoft Corporation 2018-11-07
_[4] 웹사이트 LockFileEx function https://docs.microso[...] Microsoft Corporation 2020-07-05
_[5] 웹사이트 LockFile function https://docs.microso[...] Microsoft Corporation 2020-07-05
_[6] 웹사이트 Mandatory File Locking for the Linux Operating System http://kernel.org/do[...] 2011-10-08
_[7] 웹사이트 Use Setuid, Setgid, and Sticky Bits with Server for NFS https://technet.micr[...] 2011-10-08
_[8] 서적 Secure Programming Cookbook for C and C++ http://shop.oreilly.[...] O'Reilly Media
_[9] 서적 Advanced Programming in the UNIX Environment Addison-Wesley Professional 2005-06-27
_[10] 웹사이트 Commonly occurring error messages http://nfs.sourcefor[...] Source Forge
_[11] 웹사이트 Lock your script (against parallel run) http://wiki.bash-hac[...]
_[12] 웹사이트 CreateFileW function (fileapi.h) - Win32 apps | Microsoft Learn https://learn.micros[...]
_[13] 웹사이트 LockFileEx function (fileapi.h) - Win32 apps | Microsoft Learn https://learn.micros[...]
_[14] 웹사이트 LockFile function (fileapi.h) - Win32 apps | Microsoft Learn https://learn.micros[...]
_[15] 웹사이트 Windows Data Types (BaseTsd.h) - Win32 apps | Microsoft Learn https://learn.micros[...]
_[16] 웹사이트 Rules for Using Pointers - Win32 apps | Microsoft Learn https://learn.micros[...]
_[17] 웹사이트 CloseHandle function (handleapi.h) - Win32 apps | Microsoft Learn https://learn.micros[...]
_[18] 웹사이트 プロセスエクスプローラー - Sysinternals | Microsoft Learn https://learn.micros[...]
_[19] 웹사이트 Transactional NTFS (TxF) - Win32 apps | Microsoft Learn https://learn.micros[...]
_[20] 웹사이트 fcntl http://unixhelp.ed.a[...]
_[21] 웹사이트 flock http://unixhelp.ed.a[...]
_[22] 웹사이트 http://linuxjm.osdn.[...]
_[23] 웹사이트 Manpage of MOUNT http://linuxjm.osdn.[...]
_[24] 웹사이트 fopen, fopen_s - cppreference.com https://ja.cpprefere[...]
_[25] 웹사이트 std::fopen - cppreference.com https://ja.cpprefere[...]
_[26] 웹사이트 fopen, _wfopen | Microsoft Learn https://learn.micros[...]
_[27] 웹사이트 fopen_s, _wfopen_s | Microsoft Learn https://learn.micros[...]
_[28] 웹사이트 fopen, _wfopen | Microsoft Learn https://learn.micros[...]
_[29] 웹사이트 fopen_s, _wfopen_s | Microsoft Learn https://learn.micros[...]

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com