우분투에서 실행중인 프로그램을 이동할 수있는 이유는 무엇입니까?

방금 실행중인 활성 프로그램을 다른 디렉토리로 옮길 수 있다는 것을 깨달았습니다. 내 경험상 MacO 또는 Windows에서는 불가능했습니다. 우분투에서 어떻게 작동합니까?

편집 : Mac에서는 불가능하다고 생각했지만 주석이 확인하면 가능합니다. 아마도 Windows에서만 가능하지 않습니다. 모든 답변에 감사드립니다.

그것을 분해하겠습니다.

당신이 실행 파일을 실행하면 시스템 호출의 순서는, 특히 실행 fork()및 execve():

• fork()호출 프로세스의 하위 프로세스를 작성합니다.이 프로세스는 (대부분) 부모의 정확한 사본이며, 둘 다 여전히 동일한 실행 파일을 실행합니다 (기록 중 복사 메모리 페이지 사용). 두 번 리턴합니다. 상위에서 하위 PID를 리턴합니다. 자식에서는 0을 반환합니다. 일반적으로 자식 프로세스는 즉시 execve를 호출합니다.

• execve()실행 파일의 전체 경로를 인수로 사용하고 호출 프로세스를 실행 파일로 바꿉니다. 이 시점에서 새로 생성 된 프로세스는 자체 가상 주소 공간, 즉 가상 메모리를 가져오고 실행은 시작점에서 시작합니다 (새 프로세스에 대한 플랫폼 ABI의 규칙에 의해 지정된 상태에서).

이 시점에서 커널의 ELF 로더는 실행 파일 의 텍스트 및 데이터 세그먼트 를 마치 마치mmap() 시스템 호출을 (공유 읽기 전용 및 개인 읽기-쓰기 매핑으로) 메모리에 매핑했습니다. BSS는 MAP_ANONYMOUS를 사용하는 것처럼 매핑됩니다. (BTW, 여기서는 단순성을 위해 동적 링크를 무시하고 있습니다. 동적 링커 는 주 실행 파일의 진입 점으로 점프하기 전에 모든 동적 라이브러리를 open()s 및 mmap()s합니다.)

새로 실행 된 () 사용자가 자체 코드를 실행하기 전에 실제로 디스크에서 메모리로 몇 페이지 만로드됩니다. 프로세스가 가상 주소 공간의 해당 부분에 닿으면 추가 페이지가 필요에 따라 페이징됩니다 . (사용자 공간 코드를 실행하기 전에 코드 또는 데이터 페이지를 미리로드하는 것은 성능 최적화 일뿐입니다.)

실행 파일은 하위 레벨의 inode로 식별됩니다. 파일이 실행되기 시작한 후에 커널은 열린 파일 디스크립터 나 파일 백업 메모리 매핑과 같이 파일 이름이 아닌 inode 참조에 의해 파일 내용을 그대로 유지합니다. 따라서 실행 파일을 파일 시스템의 다른 위치 나 다른 파일 시스템으로 쉽게 옮길 수 있습니다. 참고로 프로세스의 다양한 통계를 확인하려면 /proc/PID(PID는 주어진 프로세스의 프로세스 ID) 디렉토리를 들여다 볼 수 있습니다 . /proc/PID/exe디스크에서 연결이 해제되어 있어도 실행 파일을으로 열 수도 있습니다 .

이제 움직임을 파헤쳐 보자.

동일한 파일 시스템 내에서 파일을 이동할 때 실행되는 시스템 호출 rename()은 파일 이름을 다른 이름으로 바꾸는 것만으로 파일의 inode는 동일하게 유지됩니다.

두 개의 서로 다른 파일 시스템 사이에서 두 가지 일이 발생합니다.

• 파일의 내용은 read()및로write()

• 그 후, 파일을 사용하여 소스 디렉토리에서 파일의 연결이 해제되고 unlink()파일이 새 파일 시스템에서 새 inode를 얻습니다.

rm 실제로는 unlink() 디렉토리 트리에서 주어진 파일을 가져 오기 때문에 디렉토리에 대한 쓰기 권한이 있으면 해당 디렉토리에서 파일을 제거 할 수있는 충분한 권한을 얻게됩니다.

이제 재미있게, 두 파일 시스템간에 파일을 이동할 때 어떤 권한이 없는지 상상해보십시오. unlink() 하고 소스에서 파일 대한 .

파일은 처음에 대상 ( read(), write()) 에 복사 된 다음 unlink()권한이 충분하지 않아 실패합니다. 따라서 파일은 두 파일 시스템 모두에 남아 있습니다 !!

글쎄, 그것은 꽤 단호하다. / usr / local / bin / whoopdeedoo라는 실행 파일을 보자. 그것은 단지 소위 inode (유닉스 파일 시스템상의 파일의 기본 구조)에 대한 참조 일뿐 입니다. "사용 중"으로 표시되는 것은 inode입니다.

이제 / usr / local / whoopdeedoo 파일을 삭제하거나 이동할 때 inode에 대한 참조 만 이동되거나 지워집니다. 아이 노드 자체는 변하지 않고 유지된다. 기본적으로 그렇습니다.

나는 그것을 확인해야하지만 Mac OS X 파일 시스템 에서도이 작업을 수행 할 수 있다고 생각합니다.

Windows는 다른 접근 방식을 취합니다. 왜? 누가 알아...? NTFS의 내부에 익숙하지 않습니다. 이론적으로, 파일 이름의 내부 구조에 대한 참조를 사용하는 모든 파일 시스템이이를 수행 할 수 있어야합니다.

나는 지나치게 단순화했지만, Wikipedia에 대한 "시사점"섹션을 읽으십시오.

다른 모든 대답에서 누락 된 것으로 보이는 것은 파일을 열고 프로그램이 열린 파일 설명자를 보유하면 해당 파일 설명자가 닫힐 때까지 파일이 시스템에서 제거 되지 않는다는 것입니다.

참조 된 inode를 삭제하려는 시도는 파일이 닫힐 때까지 지연됩니다. 동일하거나 다른 파일 시스템에서 이름을 바꾸면 이름 바꾸기 동작과 상관없이 열린 파일에 영향을 줄 수 없으며 파일을 새 파일로 명시 적으로 삭제하거나 덮어 씁니다. 파일을 엉망으로 만들 수있는 유일한 방법은 파일 이름 바꾸기 / 삭제와 같은 디렉토리에서의 조작이 아니라 명시 적으로 inode를 열고 내용을 엉망으로 만드는 것입니다.

또한 커널이 파일을 실행할 때 실행 파일에 대한 참조를 유지하므로 실행 중에 파일이 수정되는 것을 다시 방지합니다.

따라서 결국 실행중인 프로그램을 구성하는 파일을 삭제 / 이동할 수있는 것처럼 보일 지라도 실제로 해당 파일의 내용은 프로그램이 끝날 때까지 메모리에 보관됩니다.

Linux 파일 시스템에서 파일을 이동할 때 파일 시스템 경계를 넘지 않는 한 (읽기 : 동일한 디스크 / 파티션에 유지) 변경하는 모든 것은 ..(부모 디렉토리)의 새 위치에 대한 inode입니다. . 실제 데이터는 디스크에서 전혀 이동하지 않고 포인터만으로 파일 시스템이 데이터를 찾을 수있는 위치를 알 수 있습니다.

그렇기 때문에 이동 작업이 너무 빠르며 실제로 프로그램 자체를 이동하지 않아도 실행중인 프로그램을 이동하는 데 문제가없는 것 같습니다.

프로그램 이동은 시작된 프로세스 실행에 영향을 미치지 않기 때문에 가능합니다.

프로그램이 시작되면 온 디스크 비트를 덮어 쓰지 못하도록 보호되지만 파일 이름을 바꾸거나 동일한 파일 시스템의 다른 위치로 이동하거나 파일 이름을 바꾸는 것과 같은 위치로 이동할 필요는 없습니다. 다른 파일 시스템으로 복사하십시오. 파일 시스템을 다른 곳에 복사 한 다음 제거하십시오.

프로세스에 파일 디스크립터가 열려 있거나 프로세스가 실행 중이기 때문에 사용중인 파일을 제거하면 파일 데이터가 제거되지 않고 파일 inode에서 참조 상태를 유지하지만 디렉토리 항목 만 제거합니다. 즉, inode에 도달 할 수있는 경로입니다.

프로그램을 시작해도 모든 물리적 메모리에 한 번에 모든 내용이로드되지는 않습니다. 반대로 프로세스를 시작하는 데 필요한 엄격한 최소값 만로드됩니다. 그런 다음 프로세스의 전체 수명 동안 필요한 페이지가 필요할 때로드됩니다. 이를 수요 페이징이라고합니다. RAM이 부족한 경우 OS에서 이러한 페이지를 보유한 RAM을 자유롭게 해제 할 수 있으므로 프로세스가 실행 가능한 inode에서 동일한 페이지를 여러 번로드 할 수 있습니다.

Windows에서 가능하지 않은 이유는 원래 기본 파일 시스템 (FAT)이 디렉토리 항목과 inode의 분할 개념을 지원하지 않았기 때문일 수 있습니다. 이 제한은 NTFS에 더 이상 존재하지 않았지만 OS 디자인은 오랫동안 유지되어 새로운 버전의 바이너리를 설치할 때 재부팅 해야하는 불쾌한 제약이 생겨났습니다. 이는 최신 버전의 Windows에는 해당되지 않습니다.

기본적으로 Unix와 ilk에서는 파일을 열 때 파일을 연결 / 찾기 위해 파일 이름 (파일을 여는 디렉토리 경로 포함)이 사용됩니다 (파일 실행은 파일을 여는 방법 중 하나입니다). 그 순간, 파일의 신원 ( "inode"를 통해)이 확립되고 더 이상 의문의 여지가 없습니다. 파일을 제거하고 이름을 바꾸고 권한을 변경할 수 있습니다. 프로세스 또는 파일 경로에 해당 파일 / 아이 노드에 대한 핸들이있는 한 프로세스 간 파이프처럼 파이프가 고착됩니다 (사실 역사적인 유닉스에서 파이프 는 크기에 맞는 이름이없는 inode 였습니다 . inode에서 "직접 블록"디스크 저장소 참조 (10 개 블록과 같은)

PDF 파일에서 PDF 뷰어를 연 경우 해당 파일을 삭제하고 동일한 이름으로 새 파일을 열 수 있습니다. 기존 뷰어가 열려있는 한 기존 파일을 계속보고있는 경우가 아니라면 여전히 기존 파일에 액세스하는 것이 좋습니다 파일이 원래 이름으로 사라질 때 알 수 있도록 파일 시스템).

임시 파일이 필요한 프로그램은 해당 파일을 일부 이름으로 연 다음 즉시 동안 (또는 디렉토리 항목)을 제거 할 수 있습니다. 그 후에는 이름으로 파일에 더 이상 액세스 할 수 없지만 파일에 열린 파일 디스크립터가있는 프로세스는 여전히 파일에 액세스 할 수 있으며, 프로그램이 예기치 않게 종료되면 파일이 제거되고 스토리지가 자동으로 재생됩니다.

따라서 파일 경로는 파일 자체의 속성이 아니며 (실제로 하드 링크는 여러 다른 경로를 제공 할 수 있음) 이미 열려있는 프로세스에 의한 지속적인 액세스가 아니라 파일을 열 때에 만 필요합니다.