UNIX / Linux에서 디렉토리에 대한 하드 링크가 허용되지 않는 이유는 무엇입니까?

이것은 단지 나쁜 생각입니다. 하드 링크와 원래 이름의 차이를 구분할 수있는 방법이 없습니다.

디렉토리에 대한 하드 링크를 허용하면 파일 시스템의 방향성 비순환 그래프 구조가 깨져서 디렉토리 루프와 매달려있는 디렉토리 하위 트리가 생성 될 수 있습니다. fsck 및 기타 파일 트리 워커 오류가 발생하기 쉽습니다.

먼저, 이것을 이해하기 위해 inode에 대해 이야기하겠습니다. 파일 시스템의 데이터는 디스크에있는 블록과 그 블록은 inode에 의해 함께 수집됩니다. inode를 THE 파일로 생각할 수 있습니다. Inode에는 파일 이름이 없지만 링크가 들어오는 곳입니다.

링크는 inode에 대한 포인터. 디렉토리는 링크를 보유하는 inode입니다. 디렉토리의 각 파일 이름은 inode에 대한 링크 일뿐입니다. Unix에서 파일을 열면 링크가 생성되지만 다른 유형의 링크입니다 (이름이 지정된 링크가 아님).

하드 링크는 해당 inode를 가리키는 추가 디렉토리 항목입니다. ls -l 경우 권한 뒤의 숫자가 명명 된 링크 수입니다. 대부분의 일반 파일에는 하나의 링크가 있습니다. 파일에 대한 새로운 하드 링크를 생성하면 두 파일 이름이 동일한 inode를 가리 킵니다. 참고 :

% ls -l test ls: test: No such file or directory % touch test % ls -l test -rw-r--r-- 1 danny staff 0 Oct 13 17:58 test % ln test test2 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 % touch test3 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 ^ ^ this is the link count 

이제 하드 링크와 같은 것이 없다는 것을 분명히 알 수 있습니다. 하드 링크는 일반 이름과 동일합니다. 위의 예에서 test 또는 test2는 원본 파일이고 하드 링크는 무엇입니까? 결국 두 이름이 동일한 내용, 동일한 inode를 가리 키기 때문에 실제로 알 수는 없습니다 (타임 스탬프로도).

% ls -li test* 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 14445892 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 

iv ls에 대한 id = “0c65772eaa”>

바인드 마운트를 사용하여 하드 링크 디렉토리를 시뮬레이션 할 수 있습니다.

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory sudo umount /else/dummy_but_existing_directory 

마운트 지점을 제외하고 각 디렉토리에는 하나의 상위 항목 인 ..가 있습니다.

do pwd는 device : inode에서 “.”를 확인하는 것입니다. 그리고 “..”. 동일하다면 파일 시스템의 루트에 도달 한 것입니다. 그렇지 않으면 부모에서 현재 디렉터리의 이름을 찾아 스택에 푸시하고 “../”비교를 시작합니다. “../ ..”다음에 “../../.” “../../ ..”등을 사용합니다. 루트에 도달하면 스택에서 이름을 표시하고 인쇄하기 시작합니다.이 알고리즘은 각 디렉토리에 부모가 하나만 있다는 사실에 의존합니다.

디렉토리에 대한 하드 링크가 허용 된 경우 여러 상위 중 하나가 ..를 가리켜 야합니까? 이것이 디렉토리에 대한 하드 링크가 허용되지 않는 이유 중 하나입니다.

디렉토리에 대한 심볼릭 링크는 그 문제를 일으키지 않습니다. 프로그램이 원하는 경우 경로 이름의 각 부분에 대해 lstat()를 수행하고 심볼릭 링크가 발견되면 감지 할 수 있습니다. pwd 알고리즘은 대상 디렉토리에 대한 실제 절대 경로 이름을 반환합니다. 대상 디렉토리를 가리키는 텍스트 (심볼 링크)가 어딘가에 있다는 사실은 거의 관련이 없습니다. 이러한 심볼릭 링크가 있다고해서 그래프에 루프가 생기지는 않습니다.

댓글

• 잘 모르겠습니다. ..를 부모에 대한 일종의 가상 하드 링크라고 생각하면 링크 대상이 하나의 다른 링크 만 가질 수 있다는 기술적 이유가 없습니다. pwd는 경로를 확인하기 위해 다른 알고리즘을 사용해야합니다.

이 질문에 대해 몇 가지 요점을 추가하고 싶습니다. 디렉토리에 대한 하드 링크는 리눅스에서 허용되지만 제한된 방식입니다.

이를 테스트 할 수있는 한 가지 방법은 디렉토리의 내용을 나열 할 때 두 개의 특수 디렉토리 “.”를 찾을 때입니다. 그리고 “..”. 아시다시피 “.” 같은 디렉토리를 가리키고 “..”는 부모 디렉토리를 가리 킵니다.

그러므로 “a”가 디렉토리 “b”를 자식으로 갖는 부모 디렉토리 인 디렉토리 트리를 만들 수 있습니다.

 a `-- b 

“a”디렉토리의 inode를 기록해 둡니다. “a”디렉토리에서 ls -la를 수행하면 “.” 디렉토리도 동일한 inode를 가리 킵니다.

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a 

여기서 우리는 디렉토리 “a”에 세 개의 하드 링크가 있음을 알 수 있습니다. 이것은 inode 797358에 “.”라는 이름의 하드 링크가 세 개 있기 때문입니다. “a”디렉토리 내부에 “..”디렉토리 “b”내부와 “a”itslef 이름을 가진 이름입니다.

$ ls -ali a/ 797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 . $ ls -ali a/b/ 797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .. 

그래서 여기서 우리는 이해할 수 있습니다. 하드 링크는 디렉토리가 상위 및 하위 디렉토리와 연결될 때만 있습니다. 따라서 자식이없는 디렉토리는 하드 링크가 2 개뿐이므로 “b”디렉토리에는 하드 링크가 2 개만 있습니다.

디렉토리의 하드 링크가 자유롭게 금지 된 한 가지 이유는 무한 참조 루프를 피하는 것입니다. 파일 시스템을 순회하는 프로그램을 혼동합니다.

파일 시스템이 트리로 구성되고 트리가 순환 참조를 가질 수 없기 때문에 피해야합니다.

코멘트

• 좋은 예. 그것은 내 의심을 해소했다. 따라서 이러한 경우는 무한 루프를 피하기 위해 특별한 방식으로 처리됩니다. 권리?
• 디렉토리 (예 : ” .. ” 및 “. ” 무한 루프에 도달하지 않을 것이므로 이러한 현상이 발생하지 않으므로이를 방지하기위한 특별한 방법이 필요하지 않습니다. 🙂

다음 중 어느 것도 디렉토리에 대한 하드 링크를 허용하지 않는 실제 이유가 아닙니다. 각 문제는 매우 쉽게 해결할 수 있습니다.

• 트리 구조의 순환으로 인해 순회가 어려워집니다.
• 여러 부모가 “실제”문제입니까?
• 파일 시스템 가비지 수집

실제 이유 (@ Thorbjørn Ravn에 의해 암시 됨) Andersen)은 iv id = “a7e4d30def”가 가리키는 디렉토리에서 여러 상위가있는 디렉토리를 삭제 할 때 나타납니다. >

디렉토리에 대한 하드 링크 생성은 되돌릴 수 없습니다. 다음이 있다고 가정합니다.

/dir1 ├──this.txt ├──directory │ └──subfiles └──etc 

/dir2에 하드 링크합니다.

그래서 /dir2에는 이제 이러한 모든 파일과 디렉토리도 포함됩니다.

마음이 바뀌면 어떻게합니까? rmdir /dir2 (비어 있지 않기 때문에)

/dir2에서 재귀 적으로 삭제하면 안됩니다. .. /dir1에서도 삭제됩니다!

IMHO it “은이를 피할 수있는 충분한 이유입니다!

편집 :

댓글은 rm를 수행하여 디렉토리를 제거하도록 제안합니다. .그러나 비어 있지 않은 디렉토리에 대한 rm는 실패하며 디렉토리가 하드 링크되었는지 여부에 관계없이이 동작은 유지되어야합니다. 따라서 링크를 해제하기 위해 rm 할 수는 없습니다. rm에 대한 새 인수가 필요합니다. 참조 횟수가 1보다 크면 디렉토리 링크 만 해제합니다. “

교대로 최소한의 놀라운 원칙을 위반하는 경우 : 방금 만든 디렉토리 하드 링크의 제거가 제거와 동일하지 않음을 의미합니다. 일반 파일 하드 링크의 …

내 문장을 다시 표현하겠습니다. 추가 개발없이 하드 링크 생성은 되돌릴 수 없습니다 (현재 명령이 현재 동작과 일치하지 않고 제거를 처리 할 수 없기 때문에)

사례, 함정 수 및 데이터 손실 위험 을 처리하기 위해 더 많은 개발을 허용하는 경우 “시스템이 작동하는 방식을 충분히 알지 못한다는 것은 IMHO가 디렉토리에 대한 하드 링크를 제한 할 충분한 이유입니다.

댓글

• 그것은 문제가되지 않습니다. 귀하의 경우 dir2에 대한 하드 링크를 만들 때 dir1의 모든 내용에 대한 하드 링크를 만들어야하므로 dir2의 이름을 바꾸거나 삭제하면 inode에 대한 추가 링크 만 삭제됩니다. 그리고 그것은 inode에 대한 링크 (dir1)가 하나 이상 있기 때문에 dir1과 그 내용에 영향을주지 않아야합니다.
• 당신의 주장이 잘못되었습니다. rm -rf가 아니라 링크를 해제하면됩니다. 링크 수가 0에 도달하면 시스템은 모든 콘텐츠도 삭제할 수 있음을 알게됩니다.
• 그 ‘는 거의 모든 rm는 어쨌든 아래에 있습니다 (연결 해제). 참조 : unix.stackexchange.com/questions/151951/ … 이것은 실제로는 아닙니다. ‘ 하드 링크 파일보다 문제가되지 않습니다. 링크를 해제하면 명명 된 참조가 제거되고 링크 수가 감소합니다. rmdir가 ‘ 비어 있지 않은 디렉토리를 삭제하지 않았다는 사실은 관련이 없습니다. ‘ dir1도 마찬가지입니다. 하드 링크는 ‘ 데이터의 사본이 아니며 실제 파일과 동일하므로 실제로 ” 삭제 ” dir2 파일은 dir1에 대한 디렉토리 목록을 지 웁니다. 항상 연결을 해제해야합니다.
• rm 때문에 일반 파일처럼 연결을 해제 할 수 있습니다. ‘ 디렉토리가 비어 있지 않은 경우 연결 해제 ‘하지 ‘. 편집을 참조하십시오.

좋은 설명입니다. “여러 부모 중 어느 하나를 .. 가리켜 야합니까?” 한 가지 해결책은 프로세스가 inode 또는 문자열로 전체 wd 경로를 유지하는 것입니다. 이름이 변경 될 수 있기 때문에 inode는 더 강력합니다. 적어도 옛날에는 파일이 열릴 때마다 증가하고 닫을 때 감소하는 모든 열린 파일에 대한 인 코어 inode가있었습니다. 그것이 0에 도달하면 그것이 가리키는 스토리지가 해제됩니다. 파일이 더 이상 열리지 않으면 해당 파일 (핵심 사본)이 폐기됩니다. 이것은 다른 프로세스가 다른 프로세스의 경로에있는 동안 다른 프로세스가 디렉토리를 다른 디렉토리로 이동 한 경우 경로를 유효한 것으로 유지합니다. 열린 파일을 삭제할 수있는 방법과 비슷하지만 단순히 디렉토리에서 제거되지만 파일을 연 모든 프로세스에 대해 여전히 열려 있습니다.

하드 링크 디렉토리는 Bell Labs UNIX에서 자유롭게 허용 되곤했습니다. 최소한 V6 및 V7, Berkeley 이상에 대해 모릅니다. 플래그가 필요하지 않습니다. 루프를 만들 수 있습니까? 예, 그렇게하지 마십시오. 루프를 만들면 무엇을하고 있는지 매우 분명합니다. 네더는 다른 쪽 끝이 벌크 헤드의 고리에 편리하게 매달린 경우 비행기에서 스카이 다이빙 할 차례를 기다리는 동안 목에 매듭을 묶는 연습을해야합니다.

무엇이 오늘이 작업을 수행하고 싶었습니다. lhome을 홈에 하드 링크하여 / home이 집에 대한 automout으로 은폐되었는지 여부에 관계없이 / home / administ를 사용할 수 있도록했습니다. 자동 마운트에는 administ라는 심볼릭 링크가 있습니다. / lhome / administ로. 이를 통해 기본 홈 파일 시스템의 상태에 관계없이 작동하는 관리 계정을 가질 수 있습니다. 이 IS 는 리눅스 실험이지만 UCB 기반 SunOS에서 자동 마운트가 ascii 문자열 수준에서 수행된다는 사실을 한 번에 배웠습니다. 임의의 FS 위에 레이어로 다른 방법으로 수행 할 수있는 방법을 알기는 어렵습니다.

다른 곳에서. 및 ..는 더 이상 디렉토리의 파일이 아닙니다. 나는이 모든 것에 대한 좋은 이유가 있고, 우리가 즐기는 것 (NTFS를 마운트 할 수있는 것과 같은)의 대부분이 그러한 것들 때문에 가능하다고 확신하지만, UNIX의 우아함 중 일부는 구현에있었습니다.이 우아함이 제공 한 보편성 및 가단성과 같은 이점으로 인해 견고하고 40 년 동안 견딜 수 있습니다. 우리가 우아한 구현을 잃어 버리면 결국 Windows처럼 될 것입니다 (제가 틀렸기를 바랍니다!). 누군가는 우아한 원칙에 기반한 새로운 OS를 만들 것입니다. 생각할 것. 아마도 내가 틀렸을 수도 있고, 현재 구현에 대해 (분명히) 익숙하지 않습니다. 30 년 동안의 이해가 Linux에 얼마나 적용될 수 있는지는 놀랍습니다 . 대부분의 경우입니다.

댓글

• 내가 틀렸을 지 모르지만 . 및 ..는 최신 파일 시스템의 경우 파일 시스템의 하드 링크가 아니라고 생각합니다. 그러나 파일 시스템 드라이버는이를 위조합니다. 하드 링크 디렉토리를 중지하는 것은 이러한 파일 시스템입니다. 오래된 파일 시스템에서는 가능했지만 위험했습니다. 시도중인 작업을 수행하려면 mount --bind를보고 mount --make… 및 컨테이너도 참조하세요.

내가 수집 한 내용에서 주된 이유는 디렉토리 이름을 사용하는 프로그램을 엉망으로 만들지 않고 디렉토리 이름을 변경할 수 있다는 것입니다. 다른 파일을 참조하기위한 작업 디렉토리입니다. Wine을 사용하여 ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe를 실행하고 대신 전체 접두사를 ~/.wine로 이동하려한다고 가정 해보십시오. 이상한 이유로 Firefox가 ../../windows를 참조하여 drive_c/windows에 액세스하고 ~/.newwineprefix 이름을 바꾸면 중단됩니다. 부모 디렉터리를 inode 대신 텍스트 문자열로 추적하는 ..의 구현입니다.

단일 부모 디렉터리의 inode를 저장하는 것은 시도하는 것보다 간단해야합니다. 모든 경로를 텍스트 문자열과 일련의 inode로 추적합니다.

또 다른 이유는 오작동입니다. 응용 프로그램에서 루프를 만들 수 있습니다. 동작하는 응용 프로그램은 “이동중인 디렉토리의 inode가 디렉토리를 자신으로 이동할 수없는 것처럼”이동되는 중첩 된 디렉토리의 inode와 동일한 지 확인할 수 있어야합니다. 파일 시스템 수준에서는 적용되지 않을 수 있습니다.

또 다른 이유는 디렉토리를 하드 링크 할 수 있다면 수정할 수없는 디렉토리를 하드 링크하지 않으려는 것입니다. find는 임시 디렉토리에서 다른 사용자가 만든 파일을 지우는 데 사용되기 때문에 보안 고려 사항이 있습니다. find가 다른 명령을 호출하고 있습니다. 중요한 디렉토리를 하드 링크 할 수 있으면 관리자가 영향을받지 않도록 find에 추가 테스트를 추가해야합니다. (좋아, 이미 파일에 대해이 작업을 수행 할 수 없으므로이 이유는 유효하지 않습니다.

또 다른 이유는 상위 디렉토리의 inode를 저장하면 파일 시스템 손상 또는 손상시 추가 중복성을 제공 할 수 있다는 것입니다. ..가이 디렉토리에 하드 링크 된 모든 상위 디렉토리를 나열하기를 원했기 때문에 현재 디렉토리가 링크 해제되면 다른 임의의 상위 디렉토리를 쉽게 찾을 수 있습니다. 링크가 같으면 파일 시스템이 inode를 저장하고 사용하는 방법을 변경해야합니다. 프로그램이 경로를 시리즈로 처리하도록합니다 (uniq 각 하드 링크로 인해) 디렉토리 inode의 경우이를 피할 수 있지만 “파일 시스템 손상시 중복성을 얻을 수 없습니다.