열린 파일 핸들은 죽을 때 어디로 가나 요?

파일 핸들이 열려있는 동안 삭제 된 파일은 어떻게됩니까?

MPlayer 에서 재생하는 동안 비디오 파일을 삭제할 수 있으며 끝까지 계속 재생 될 것으로 생각한 이후로 이것이 궁금했습니다 . 데이터를 어디에서 가져 옵니까? 여전히 하드 드라이브에서 나옵니까? 파일을 삭제하면 RAM에 복사 되었습니까?

하드 드라이브에 여전히 있으면 프로그램이 실행 중일 때 파일 시스템을 가득 채우면 할당되지 않은 공간이 무엇입니까? RAM에 버퍼링 된 경우 버퍼를 플러시하면 어떻게됩니까?

파일이 NFS 공유에있는 경우 어떻게됩니까? 서버에 저장되어 있습니까? (수많은 원격 파일 핸들이 보안 상 위험하지 않습니까?)

이렇게는 lsof -n |grep '(deleted)'종종 흥미로운 결과를 얻을; 공유 라이브러리 파일을 스왑 아웃하는 패키지를 업그레이드하는 경우 해당 라이브러리를 사용하고 있던 프로그램을 실행하면 아무것도 변경되지 않은 것처럼 계속 사용할 수 있습니다.

보너스 질문 :이 상황에서 데이터를 다시 가져 오는 방법이 있습니까?

아이 노드에 대한 하드 링크가 더 이상 존재하지 않더라도 아이 노드는 디스크에 계속 남아 있습니다. 파일 디스크립터가 닫히면 삭제됩니다. 그때까지 파일 이름 / 하드 링크가 필요한 작업을 금지하고 파일을 정상적으로 수정할 수 있습니다.

debugfs 유사한 툴을 사용하여 inode의 내용을 복구 할 수 있습니다.

커널은 inode에 대한 참조 계산을 참조합니다. 내 대답을 참조하십시오 때 가까이 () 파일 디스크립터를 어떻게됩니까을? .

열린 파일을 삭제하는 것은 파일을 여는 것보다 DOS 메커니즘보다 효과적이지 않을 수 있습니다. ulimit열려있는 파일에이 DOS 시도에 대한 몇 가지 보호 기능을 제공합니다. 삭제 여부에 관계없이 열려있는 모든 파일에 적용됩니다.

파일에 대한 모든 참조가 사라지면 파일 시스템에서만 파일이 지워집니다. 이름과 열린 핸들은 모두 참조로 계산됩니다. 파일이 프로그램에서 열려있는 한 대부분의 시스템에서는 파일 이름을 다시 만들 수 없지만 파일은 삭제되지 않습니다.

데이터는 여전히 드라이브에 있지만 파일의 링크 수는 0으로 표시됩니다. 시스템이 충돌하면 다음에 다시 부팅 할 때 fsck가 데이터를 삭제해야 함을 알고 있습니다. 이것은 삭제되지 않은 파일보다 더 이상 서비스 거부로 이어지지 않습니다.

내가 아는 한 (주식 파일 시스템 드라이버를 사용하지 debugfs않거나 비슷한 방법으로) 스톡 Linux 시스템에서 파일에 대한 링크를 다시 만들 수 없지만 내용을 쉽게 복구 할 수 있습니다.cat /proc/12345/fd/42 여기서 12345는 파일이 열려있는 프로세스 ID입니다. 42는 파일 디스크립터 번호이다.

NFS를 통해 일부 클라이언트에서 열려있는 파일을 삭제하면 NFS 서버는 서버의 파일 이름을 바꾸지 만 모든 클라이언트가 파일을 해제 할 때까지 파일을 삭제하지 않습니다. 내 경험상 새 .nfs…NFS 이름은 모든 NFS 구현에서 이름이 같은지 모르겠지만.