유닉스 시스템에서 왜 파일을`read ()`또는`write ()`할 수 있도록 명시 적으로`open ()`및`close ()`파일을 사용해야합니까?

왜 open()와 close()유닉스 파일 시스템 디자인에 존재 하는가?

OS가 처음 감지 read()하거나 write()호출되어 open()정상적으로 수행되는 작업을 수행 할 수 없었 습니까?

데니스 리치에 언급 «유닉스 시간 공유 시스템의 진화» 그 open와 close함께 read, write그리고 creat처음부터 시스템에 존재했다.

나는없이 시스템을 생각 open하고 close상상할 수없는 것, 그러나 나는 디자인을 복잡하게 할 생각합니다. 일반적으로 하나의 호출이 아닌 여러 번의 읽기 및 쓰기 호출을 원하며 이는 UNIX가 시작된 RAM이 매우 제한적인 이전 컴퓨터에서 특히 그렇습니다. 현재 파일 위치를 유지하는 핸들이 있으면이를 단순화합니다. 만약 read나write핸들을 반환해야했는데 핸들과 자신의 반환 상태 인 쌍을 반환해야했습니다. 쌍의 핸들 부분은 다른 모든 호출에 쓸모가 없으므로 배열이 어색합니다. 커서 상태를 커널에 남겨두면 버퍼링뿐만 아니라 효율성을 향상시킬 수 있습니다. 경로 조회와 관련된 비용도 있습니다. 손잡이를 사용하면 한 번만 지불하면됩니다. 또한 UNIX 월드 뷰의 일부 파일에는 파일 시스템 경로가 없거나 파일 시스템 경로가 없습니다 /proc/self/fd.

그런 다음 모든 read및 write호출은 각 작업에 대해이 정보를 전달해야합니다.

• 파일의 이름
• 파일의 권한
• 발신자가 추가하거나 생성하는지 여부
• 호출자가 파일 작업을 완료 했는지 여부 (사용되지 않는 읽기 버퍼를 버리고 쓰기 버퍼가 실제로 쓰기를 완료했는지 확인)

당신이 독립적 인 생각하든 전화를 open , read, write및 closeI / O의 단일 목적과 간단합니다 메시지가 당신의 디자인 철학을 기반으로합니다. 유닉스 개발자는 모든 작업을 수행하는 단일 작업 (또는 프로그램)이 아닌 여러 가지 방식으로 결합 할 수있는 간단한 작업 및 프로그램을 사용하기로 결정했습니다.

파일 핸들의 개념은 파일 시스템의 일부가 아닌 것을 포함하여 "모든 것이 파일"인 UNIX의 디자인 선택 때문에 중요합니다. 테이프 드라이브, 키보드 및 스크린 (또는 텔레타이프), 펀치 카드 / 테이프 리더, 직렬 연결, 네트워크 연결 및 (주요 UNIX 발명)와 같은 "파이프"라는 다른 프로그램에 직접 연결합니다.

당신이 좋아하는 간단한 표준 UNIX 유틸리티의 많은 보면 grep특히 원래 버전에서, 당신은 그들이 호출을 포함하지 않는 것을 알 수 있습니다 open()및 close()하지만 단지 read와 write. 파일 핸들은 셸에 의해 프로그램 외부 에서 설정되고 시작될 때 전달됩니다. 따라서 프로그램은 파일 또는 다른 프로그램에 쓰는지 신경 쓸 필요가 없습니다.

뿐만 아니라 open, 파일 설명을 얻을 수있는 다른 방법은 socket, listen, pipe, dup, 및 파이프를 통해 파일 기술자를 보내는 매우 히스 로빈슨 메커니즘 : https://stackoverflow.com/questions/28003921/sending-file-descriptor-by-linux -소켓

편집 : 간접 계층과 이것이 O_APPEND가 현명하게 작동하게하는 방법을 설명하는 강의 노트 . inode 데이터를 메모리에 유지하면 시스템이 다음 쓰기 작업을 위해 다시 가져와야 할 필요가 없습니다.

open ()과 close ()는 각각 핸들을 만들고 파괴하기 때문에 대답은 '아니요'입니다. 예상치 못한 파싱을 통해 파일에 쓰는 다른 호출자 (예를 들어)가 예기치 않게 떠날 수 있기 때문에 특정 액세스 수준의 유일한 발신자임을 보장하려는 경우가 있습니다 (실제로 항상). 알 수없는 상태의 응용 프로그램 또는 라이브 록 또는 교착 상태 (예 : 식당 철학자 보조)로 연결됩니다.

이러한 고려 사항이 없어도 고려해야 할 성능 관련 사항이 있습니다. close ()는 파일 시스템이 (적절한 경우 또는 호출 한 경우) 사용중인 버퍼를 비우도록합니다. 인 메모리 스트림에 대한 여러 번의 연속 편집은 파일 시스템에 대한 본질적으로 관련이없는 읽기 / 쓰기-수정 사이클보다 훨씬 효율적입니다. 로컬 스토리지에서도 메모리는 일반적으로 대량 스토리지보다 훨씬 빠릅니다.

Open ()은 사용중인 파일을 잠그는 방법을 제공합니다. 파일이 자동으로 열리고, 읽히고 쓴 다음 OS에 의해 다시 닫히면 다른 응용 프로그램이 작업간에 해당 파일을 변경하는 것을 막을 수있는 것은 없습니다.

간단하게 관리 할 수 ​​있지만 (많은 시스템에서 비 독점 파일 액세스를 지원) 대부분의 응용 프로그램은 열려있는 파일이 변경되지 않는다고 가정합니다.

파일의 경로는 동일하게 유지된다고 가정하는 동안 이동 될 수 있습니다.

파일 시스템을 읽고 쓰는 작업에는 다양한 버퍼링 체계, OS 하우스 키핑, 저수준 디스크 관리 및 기타 여러 가지 잠재적 인 작업 이 포함될 수 있습니다. 따라서 이러한 유형의 후드 활동에 대한 조치 open()및 close()설정이 수행됩니다. 파일 시스템의 다른 구현은 필요에 따라 고도로 사용자 정의 될 수 있으며 여전히 호출 프로그램에 투명하게 남아 있습니다.

OS에 개 / 폐가없는 경우 with read또는를 사용 write하면 해당 파일 작업은 매번 초기화, 버퍼 플러시 / 관리 등을 수행해야합니다. 반복적 인 읽기 및 쓰기를 위해 많은 오버 헤드가 발생합니다.

유닉스 만트라는 "일을하는 한 가지 방법을 제공한다"는 뜻대로 결합 할 수있는 (재사용 가능한) 조각들로 "인수 화"하는 것을 의미한다. 즉,이 경우 파일 핸들의 생성과 삭제는 사용에서 분리됩니다. 파이프와 네트워크 연결을 통해 중요한 이점이 생겼습니다 (파일 핸들을 통해서도 조작되지만 다른 방식으로 생성됨). 파일 핸들을 전달할 수있는 것 (예를 들어, 파일을 자식 프로세스에 "열린 파일"로 exec(2)전달하고 파이프를 통해 관련없는 프로세스로 전달하는 것)은이 방법으로 만 가능합니다. 특히 보호 된 파일에 대한 제어 된 액세스를 제공하려는 경우. 예를 들어 열 수 있습니다/etc/passwd 쓰기 위해 파일을 열 수없는 자식 프로세스에 전달하십시오 (예, 이것이 우스운 예라는 것을 알고 더 현실적인 것으로 자유롭게 편집하십시오).