"하드 링크"는 단순히 동일한 기본 데이터 구조를 참조하는 파일 시스템 계층 구조에 있는 두 개(또는 그 이상) 항목의 경우입니다. 귀하의 사진은 이것을 완벽하게 보여줍니다!

여기 있는 모든 것이 그것입니다. 마치 "빵: 3페이지 참조" 및 "베이커리: 3페이지 참조"라는 색인이 끝에 있는 요리책과 같습니다. 이제 3페이지의 콘텐츠에는 두 개의 이름이 있습니다.

동일한 페이지를 가리키는 색인 항목을 필요한 만큼 가질 수 있습니다. 무엇인가요아니요작동하는 것은 다른 책의 내용에 대한 색인 항목이 있다는 것입니다. 다른 책은 전혀 없어요존재하다현재 책에서는 페이지를 인용하는 것이 작동하지 않습니다. 특히 다른 책의 다른 버전은 시간이 지남에 따라 다르게 번호가 매겨졌을 수 있기 때문입니다.

단일 파일 시스템은 자체 일관성만 보장할 수 있으므로 항상 손상되지 않고는 다른 파일 시스템의 inode와 같은 "기본 스토리지 시스템 세부 정보"를 참조할 수 없습니다. 따라서 다른 파일 시스템에 저장된 디렉토리 항목을 참조하려면 경로를 통해 참조해야 합니다. UNIX는 기호 링크를 통해 이를 달성하는 데 도움이 됩니다.

내가 본 유일한 문제는 여러 파일 시스템이 동일한 범위의 inode를 가질 수 있다는 것입니다(그러나 운영 체제에서는 inode가 제한되어 있으므로 그렇게 생각하지 않습니다).

이것은 사실도 아니고 논리적도 아닙니다. 내 하드 드라이브를 보내드릴 수 있습니다. 그렇죠. 하드 드라이브의 파일 시스템에 컴퓨터에 있는 많은 파일 시스템 중 하나에서 이미 사용 중인 inode 번호가 없는지 어떻게 확인합니까?

또한, inode 자체에 파일 시스템에 대한 새로운 정보를 추가하는 것이 왜 좋지 않을까요? 정말 편리하지 않을까요?

아니요. 파일 시스템을 "저장 매체의 바이트"의 추상화로 생각하십시오. 파일 시스템 자체는독립적인파일로 구성된 데이터를 포함하는 데이터 구조로, 완성을 위해 외부 데이터에 의존할 수 없습니다. 이를 위반하면 불일치만 발생할 것입니다. 독립성은 파일 시스템 B에 대해 알 필요 없이 파일 시스템 A의 inode 번호를 변경할 수 있음을 의미하기 때문입니다. 이제 B가 A에 의존한다면 B는 파괴될 것입니다.

이 질문의 문제점은 그것이 거짓말에 기초하고 있다는 것입니다. 그런 일은 어떤 상황에서도 불가능하다는 생각에 바탕을 두고 있다. 이것이 어떻게 작동할 수 있는지 상상하기 쉽기 때문에 이것이 가능하지 않은 이유를 설명하려고 해도 소용이 없습니다.

극복해야 할 두 가지 문제가 있습니다. 이러한 문제는 운영 체제 개발자가 구현을 시도하는 것을 방해하기에 충분합니다.

첫 번째는 인용 방법입니다.어느하드 링크는 다른 파일 시스템을 가리킵니다.

실행 중인 운영 체제 내에서 마운트된 각 파일 시스템에 고유 번호를 할당할 수 있습니다. 이를 통해 운영 체제는 어떤 마운트된 파일 시스템이 어떤 inode를 담당하는지 알 수 있습니다. 그러나 이 번호는 설치 중에만 유효합니다. 운영 체제를 다시 시작하거나 파일 시스템이 마운트 해제(이동, 플러그 해제 등)되면 이 숫자가 변경될 수 있습니다.

파일 시스템의 UUID를 사용할 수 있지만 신뢰성이 의심스럽다고 가정해 보겠습니다. 복제 및 마이그레이션으로 인해 파일 시스템에 중복된 UUID가 있을 수 있습니다.

이것이 불가능하지는 않지만 그렇게 하면 서로 다른 파일 시스템의 파일 시스템 드라이버 간에 디자인이 과도하게 결합될 수 있으므로 많은 개발자는 그렇게 하지 않는 것이 좋습니다.

두 번째 문제는 파일 시스템 자체가 파일에 존재하는 링크 수를 알아야 한다는 것입니다. 파일 시스템은 링크가 남아 있지 않은 경우에만 파일을 삭제합니다. 참조 카운트가 올바른지 확인하려면 파일 시스템 검사가 필요하므로 외부 참조 카운트를 인바운드에 저장해야 합니다. 그러나 개수를 유지하기 위해 두 파일 시스템이 항상 함께 마운트된다는 보장은 없습니다.

다른 파일 시스템이 하드 링크를 보유하고 있기 때문에 파일 시스템이 이러한 참조를 저장하고 파일을 삭제하는 대신 파일을 유지하는 경우 다른 파일 시스템이 지워지거나 손상되면 어떻게 됩니까?

이제 외부 파일 시스템에 액세스하지 않고 이를 삭제하려면 관리 작업을 수행해야 합니다. 이것은 실제로 매우 위험한 도구입니다.

일반적으로 파일 시스템 검사는 외부 링크를 감사하고 수정하기 어렵고, 다른 파일 시스템 대신 하나의 파일 시스템을 마운트함으로써 발생하는 불일치가 일반적입니다.

하드링크란 무엇인가

inode와 inode 참조를 혼동하고 있습니다. 하드 링크는 inode 참조입니다.

하드 링크는 존재하지 않으며 그런 것도 없습니다. 적어도 심볼릭 링크는 없습니다. 파일당 적어도 하나가 있습니다. 이는 파일 참조일 뿐입니다.

다른 파일 시스템에 대한 하드 링크를 가질 수 있습니까?

아니요

@MarcksMüller가 말했듯이 페이지 번호는 책의 페이지를 나타냅니다.

예

하지만 그것은 똑같지는 않을 것입니다: 그것은 하드 링크가 아닐 것입니다.

심볼릭 링크를 사용할 수 있습니다. 또는 UUID/inode 번호 또는 UUID/파일 경로를 사용하여 연결된 새로운 파일 형식을 구현할 수도 있습니다. 이것이 이미 존재하는지 모르겠지만 아직 본 적이 없습니다(NTFS에 있을 수 있다고 생각합니다).

질문에 대한 참고 사항

다이어그램이 올바른 것 같습니다.

그러나 인덱스 노드가 고유해야 한다는 귀하의 주장은 잘못되었습니다. USB 연결 장치를 한 컴퓨터에서 다른 컴퓨터로 이동한다고 상상해 보십시오. 작동해야 하지만 아마도 기존 장치와 동일한 inode 번호를 사용할 것입니다.

나는 당신의 질문에 대답하려고 노력하고 있지 않습니다. 그러나 ...

디렉토리의 모든 항목은 기호 링크를 포함하여 "하드 링크"입니다.

그건 틀렸어요.

실제로 첫 번째 부분이 정확합니다. 디렉토리의 각 항목은 하드 링크입니다. 그러나 심볼릭 링크는아니요디렉토리의 항목입니다. 심볼릭 링크는문서,inode의 플래그가 운영 체제에 프로그램이 기호 링크에 액세스하려고 시도할 때 운영 체제에서 액세스를 특별히 처리해야 한다는 점을 제외하고는 다른 파일과 같습니다. *

작성자는 아마도 이것을 알고 있었지만 심볼릭 링크가 아닌 하드 링크를 설명하는 데 게을러졌습니다. 그들이 그렇게 게으르지 않았다면 이렇게 말할 수도 있었을 것입니다.

디렉토리의 각 항목은 하드 링크입니다. 균등한 입장~을 위한기호 링크(기호 링크는 실제로 특수한 유형의 파일임)는 "하드 링크"입니다.도착하다심볼릭 링크 파일.

* 특수 처리**는 프로그램이 심볼릭 링크에 액세스하려고 시도할 때 제공됩니다.

1. 심볼릭 링크 파일을 열고,
2. 심볼릭 링크 파일에서 경로 이름을 읽습니다.
3. 심볼릭 링크 파일을 닫고,
4. 입장표적파일(즉, 심볼릭 링크 파일에서 읽은 경로 이름으로 명명된 파일)마치이것은 프로그램이 처음으로 열도록 요청하는 파일입니다.

대상 파일이 또 다른 기호 링크인 경우 비기호 링크 파일을 찾을 때까지 또는 다음 파일이 나올 때까지 프로세스가 반복됩니다.ELOOP에러 코드반환됩니다.

** 기호 링크를 "따르지" 않는 시스템 호출 내에는 일부 시스템 호출 및/또는 옵션이 있습니다. 그렇지 않으면 ls프로그램(예를 들어)이 어떻게 심볼릭 링크에 대한 정보를 제공하거나 심볼릭 링크를 생성 또는 파괴할 수 있기 때문에 이것이 필요합니다 .