일부 프로세스가 심볼릭 링크를 읽으려고 할 때 무슨 일이 일어나고 있습니까? 읽기 또는 쓰기 프로세스 중에 무언가 심볼릭 링크를 변경하면 어떻게됩니까?
예를 들어 : 2 개의 비슷한 100G 파일 /mnt/1과 2 개가 있습니다 /mnt/2. /mnt/1symlink를 통해 사용할 수 있습니다 /home/user/file. 일부 프로그램 A은 읽기 시작합니다 /home/user/file. 그리고 잠시 후에 링크가에서 (으) /mnt/1로 변경 /mnt/2되었지만 A여전히 파일을 읽고 있습니다.
프로그램이 절대 경로를 캐시합니까?
심볼릭 링크가 변경 되었기 때문에 실패하고 오류가 발생합니까?
/home/user/file블록 장치 (예 : 2 개의 복제 된 iscsi 디스크)에 연결된 경우와 다릅니 까?
답변:
심볼릭 링크 는 파일 시스템 의 실제 파일 이름 ( inode )을 가리 킵니다 . 시스템이 해당 심볼릭 링크를 확인하여 실제 파일을 찾아서 열면 파일의 inode를 찾아서 사용합니다. 이때 파일에 도달하는 데 사용 된 경로는 중요하지 않습니다. OS가 캐시하지 않는 것은 inode로 파일에서 읽습니다. 내가 이해하는 것처럼 하드 링크를 통해 파일을 읽기 시작하고 하드 링크를 제거하면 (파일이 다른 곳에서 여전히 링크되어있는 한) 파일이 해결되는 한 문제가 발생하지 않습니다. 이름 문자열-> 노이드).
심볼릭 링크가 포함 된 작은 파일 위치 는 심볼릭 링크의 것을 나타내는 디렉토리 항목에 플래그, 대상 파일의 (즉, 경로와 파일 이름을).
심볼릭 링크를 열면 OS가 위치를 따라 대상 파일을 찾습니다. 대상 자체가 심볼릭 링크 인 경우 위치 가 심볼릭 링크 가 아닌 파일을 가리킬 때까지 (1) (2) 해당 위치를 따릅니다 (FinalFile이라고 함 ). 그런 다음 OS는 FinalFile 의 inode 를 가져 옵니다 (inode에는 수정 시간과 같은 메타 데이터가 포함되어 있으며 파일 데이터에 대한 포인터도 포함되어 있음). 마지막으로 FinalFile 의 inode 가 열립니다. 이제부터 프로세스는 해당 inode를 사용하여 파일을 읽고 씁니다. 결과적으로 심볼릭 링크 이름 또는 경로 변경, 심볼릭 링크 삭제, FinalFile 경로 또는 이름 변경 또는 FinalFile 삭제(3) 프로세스에 영향을 미치지 않습니다. 여전히 같은 아이 노드에서 읽습니다.
대부분의 경우 symlink에 대한 파일 데이터 작업은 FinalFile에 영향을 미치지 만 (예 : symlink 읽기 및 쓰기는 FinalFile 에서 읽기 / 쓰기 ) readlink()시스템 예외 는 symlink 자체의 내용을 읽습니다.
반면 파일 메타 데이터 작업 (이름 바꾸기 또는 삭제 등)은 일반적으로 심볼릭 링크에 영향을줍니다. 그러나 여기에도 예외가 있습니다. lstat()시스템 호출은 FinalFile (2)이 stat()아닌 심볼릭 링크 자체에 대한 정보를 반환한다는 점을 제외하고 는 비슷 합니다 .
(1) 레벨 수에 제한이 있으며 심볼릭 링크의 위치가 상대 경로 인 경우 상황이 조금 더 복잡해집니다.
(2) symlink (7 )를 읽으십시오 : 자세한 내용은 심볼릭 링크 처리 를 참조하십시오.man 7 symlink
(3) rm명령이나 unlink()시스템 호출은 실제로 파일을 제거하지 않습니다. 파일의 inode를 가리키는 디렉토리 항목을 제거합니다. 파일 자체는 경우에만 제거 모두 의 아이 노드를 참조 b)는 어떤 프로세스가 열려있는 파일이 없습니다 더 이상 디렉토리 엔트리 (하드 링크)가없는)가.
Linux에서는 거의 투명하며 운영 체제보다 사용중인 파일 시스템과 훨씬 관련이 있습니다.
VFAT 파티션에서 작동하는 심볼릭 링크를 만들 수 없기 때문에 파일 파일에 의해 직접 기록되기 때문에 VFAT 파티션에서 작동하는 심볼릭 링크를 만들 수 없기 때문에 일반 파일 또는 매우 작은 파일이 아닙니다.
하드 링크에 대한 심볼릭 링크의 차이점은 하드 링크와 같이 데이터 섹터에 연결하는 대신 하드 링크에 대한 지정이 있다는 것입니다.
예:
시험 1 :
echo 'data' >file.txt
그러면 섹터 10 ~ 20 *을 가리키는 하드 링크 file.txt가 생성됩니다 (* 설명 용 번호).
시험 2 :
이제 어쩌면?
ln file.txt file_2.txt
이로 인해 섹터 10 ~ 20 (file.txt와 동일)을 가리키는 하드 링크 file_2.txt가 생성되었으므로 file.txt를 삭제해도 섹터 10 ~ 20은 여전히 예약되어 있으며 file_2.txt 내부의 데이터를 볼 수 있습니다. . (file.txt와 file_2.txt는 모두 원본과 같습니다)
시험 3 :
ln -s file.txt file_sym.txt
기호 링크 file_sym.txt가 하드 링크 file.txt를 가리 키므로 file_sym.txt에 액세스하려고하면 file.txt가 표시되지만 file.txt를 삭제하면 file_sym이 더 이상 대상을 찾지 못합니다.
파일 시스템, 예를 들어 Linux 용 ext4 모듈 (또는 커널에서 컴파일 된 경우)에 의해 관리되며, Linux 또는 기타 Unix를 사용 중인지 여부는 중요하지 않습니다.