내가 가진 예는 Minecraft입니다. Linux에서 Bukkit을 실행할 때 / plugins 폴더에서 .jar 파일을 제거하거나 업데이트하고 단순히 ‘reload’명령을 실행할 수 있습니다.
Windows에서는 .jar 파일을 제거하거나 교체하려고 할 때 현재 사용 중이라는 불만이 있기 때문에 전체 서버 프로세스를 중단해야합니다.
이것은 나에게 굉장하지만 왜 그렇게됩니까? 여기서 리눅스는 다르게 무엇을하고 있습니까?
답변
Linux는 Windows와 완전히 다른 방식으로 파일을 삭제합니다. 먼저, * unix 고유 파일 시스템에서 파일을 관리하는 방법에 대한 간단한 설명.
파일은이라는 멀티 레벨 구조로 디스크에 보관됩니다 i-node. 각 i- 노드는 단일 파일 시스템에서 고유 한 번호를 갖습니다. i- 노드 구조는 파일의 크기, 파일에 할당 된 데이터 블록 등과 같이 파일에 대한 다른 정보를 유지하지만이 대답을 위해 가장 중요한 데이터 요소는입니다 link counter. 는 directories파일에 대한 기록을 보관하는 파일입니다. 각 레코드에는 참조하는 i- 노드 번호, 파일 이름 길이 및 파일 이름 자체가 있습니다. 이 체계를 사용하면 이름이 다른 여러 위치에서 같은 파일에 대한 ‘포인터’를 가질 수 있습니다. i- 노드의 링크 카운터는 실제로이 i- 노드를 참조하는 링크 수를 유지합니다.
일부 프로세스에서 파일을 열면 어떻게됩니까? 먼저 open()함수는 파일 레코드를 검색합니다. 그런 다음이 i- 노드의 메모리 내 i- 노드 구조가 이미 존재하는지 확인합니다. 일부 응용 프로그램에서이 파일을 이미 연 경우이 문제가 발생할 수 있습니다. 그렇지 않으면, 시스템은 새로운 메모리 내 i- 노드 구조를 초기화합니다. 그런 다음 시스템은 메모리 내 i- 노드 구조 개방 카운터를 증가시키고 파일 디스크립터를 애플리케이션으로 리턴합니다.
파일을 삭제하기위한 Linux 라이브러리 호출을이라고 unlink합니다. 이 기능은 디렉토리에서 파일 레코드를 제거하고 i- 노드의 링크 카운터를 감소시킵니다. 시스템이 메모리 내 i- 노드 구조가 존재하고 개방 카운터가 0이 아닌 것을 발견하면이 호출은 제어를 응용 프로그램으로 리턴합니다. 그렇지 않으면 링크 카운터가 0이되었는지 확인하고, 그렇지 않으면 시스템은 i- 노드 및 i- 노드 자체에 할당 된 모든 블록을 해제하고 애플리케이션으로 리턴합니다.
응용 프로그램이 파일을 닫으면 어떻게됩니까? 이 기능 close()은 열린 카운터를 감소시키고 그 값을 확인합니다. 값이 0이 아닌 경우 함수는 응용 프로그램으로 돌아갑니다. 그렇지 않으면 i- 노드 링크 카운터가 0인지 확인합니다. 0이면 응용 프로그램으로 돌아 가기 전에 파일의 모든 블록과 i- 노드를 해제합니다.
이 메커니즘을 사용하면 파일을 여는 동안 파일을 “삭제”할 수 있습니다. 동시에 파일을 연 응용 프로그램은 여전히 파일의 데이터에 액세스 할 수 있습니다. 따라서 예제에서 JRE는 디스크에 업데이트 된 다른 버전이있는 동안 파일의 버전을 계속 열어 둡니다.
또한이 기능을 사용하면 정상적인 작동을 방해하지 않고 시스템에서 모든 응용 프로그램의 핵심 라이브러리 인 glibc (libc)를 업데이트 할 수 있습니다.
윈도우
20 년 전 우리는 DOS에서 FAT 이외의 다른 파일 시스템을 몰랐습니다. 이 파일 시스템은 다른 구조 및 관리 원칙을 가지고 있습니다. 이러한 원칙에 따라 파일을 열 때 파일을 삭제할 수 없으므로 DOS와 Windows는 열려있는 파일에 대한 삭제 요청을 거부해야합니다. 아마도 NTFS는 * nix 파일 시스템과 동일한 동작을 허용하지만 Microsoft는 파일 삭제의 습관적인 동작을 유지하기로 결정했습니다.
이것이 답입니다. 짧지는 않지만 이제는 아이디어가 있습니다.
편집 : Win32혼란의 출처에 대한 좋은 읽을 거리 : https://blogs.msdn.microsoft.com/oldnewthing/20040607-00/?p=38993
@Jon의 크레딧
