하드 링크와 파일의 차이점은 무엇입니까?


37

하드 링크는 아이 노드에 대한 포인터로 정의됩니다. 심볼릭 링크 라고도 하는 소프트 링크 는 하드 링크의 제한없이 다른 링크를 가리키는 독립 파일로 정의됩니다.

파일과 하드 링크의 차이점은 무엇입니까? 하드 링크는 inode를 가리 키므로 파일이란 무엇입니까? 아이 노드 항목 자체? 아니면 하드 링크가있는 아이 노드?

터치로 파일을 작성한다고 가정 해 봅시다. 그런 다음 inode 테이블 에 inode 항목이 작성됩니다 . 그리고 파일과 동일한 inode 번호를 가진 하드 링크를 만듭니다. 새 파일을 만들었습니까? 아니면 파일이 방금 inode로 정의 되었습니까?



7
@infixed 정확하지는 않지만 파일과 하드 링크의 차이점을 묻습니다.
Levent Divilioglu 2013

그래서 나는 그 연결된 질문에 대한 답변에서도 다루었다고 생각하는 원래의 답변을 삭제 취소했습니다. 그래도 여전히 '정확하지 않습니다'입니까?
추가됨

7
파일과 하드 링크의 차이점은 전화 번호부에서 사용자와 이름이있는 회선의 차이점과 동일합니다.
Jörg W Mittag

답변:


61

가장 짧은 대답은 다음과 같습니다.

  • 파일은 익명의 데이터 덩어리입니다.
  • 하드 링크는 파일의 이름입니다
  • 심볼릭 링크는 내용이 경로 이름 인 특수 파일입니다.

유닉스는 파일과 디렉토리 작업을 정확하게 현실 세계에서 파일과 디렉토리 (그리고 같이 하지 같은 폴더 현실 세계에서); 유닉스 파일 시스템은 (개념적으로) 다음과 같이 구성됩니다 :

  • 파일은 익명의 데이터 덩어리입니다. 이름이없고 숫자 만 (inode)
  • 디렉토리는 파일에 대한 이름 매핑 (특히 inode)을 포함하는 특별한 종류의 파일입니다. 디렉토리 그냥 파일이기 때문에, 디렉토리는 재귀 유닉스 파일 시스템이 도입되었을 때,이 것을 (주 구현 방법, 디렉토리에 대한 항목을 가질 수 없는 모든 명백한에서, 운영 체제의 많은 디렉토리가 다시 디렉토리를 포함하는 것을 허용하지 않았다을 그때)
  • 이 디렉토리 항목을 하드 링크 라고합니다.
  • 심볼릭 링크는 내용이 경로 이름 인 또 다른 특별한 종류의 파일입니다. 이 경로 이름은 다른 파일의 이름으로 해석됩니다
  • 다른 종류의 특수 파일은 소켓, fifo, 블록 장치, 문자 장치입니다.

이 은유를 염두에두고 특히 Unix 디렉토리는 실제 폴더가 아닌 실제 디렉토리처럼 작동한다는 점을 명심해야 합니다. 초보자가 자주 접하는 "비정상"은 다음과 같습니다. 왜 파일을 삭제할 수 있습니까? 쓰기 권한이 없습니까? 글쎄, 하나는 파일을 삭제하지 않고 파일에 대해 가능한 많은 이름 중 하나를 삭제하는 것입니다.이를 위해서는 파일이 아닌 디렉토리에 대한 쓰기 액세스 만 필요합니다. 현실에서와 마찬가지로.

아니면 왜 매달린 심볼릭 링크를 가질 수 있습니까? 심볼릭 링크는 단순히 경로 이름을 포함합니다. 실제로 그 이름을 가진 파일이 있어야한다는 말은 없습니다.

내 질문은 단순히 파일과 하드 링크의 차이점은 무엇입니까?

파일과 하드 링크의 차이점은 전화 번호부에서 사용자와 이름이있는 회선의 차이와 동일합니다.

하드 링크가 inode를 가리키고 있으므로 파일이란 무엇입니까? 아이 노드 항목 자체? 또는 하드 링크가있는 Inode?

파일은 익명의 데이터입니다. 그게 다야. 파일은 파일이, 아이 노드 아닌 당신이, 당신이 사회 보장 번호없는 것처럼, 아이 노드를 가지고 소셜 시큐리티 번호를.

하드 링크는 파일의 이름입니다. 파일은 많은 이름을 가질 수 있습니다.

터치로 파일을 만든 다음 Inode 테이블 에 Inode 항목을 만듭니다 .

예.

그리고 파일과 동일한 Inode 번호를 가진 하드 링크를 만듭니다.

아니요. 하드 링크는 파일이 아니기 때문에 inode 번호가 없습니다. 파일에만 inode 번호가 있습니다.

하드 링크는 이름을 inode 번호와 연결합니다.

새 파일을 만들었습니까?

예.

또는 파일이 방금 Inode?

아니요. 파일에 아이 노드가 있으며 아이 노드 가 아닙니다 .


15
나는 "디렉토리"라는 단어 뒤에있는 은유가 무엇인지 실제로 이해하지 못했었다. 전화 번호부 예제는 훌륭합니다. 어쩌면 먼저 현실 세계를 언급 할 때 소개해야합니다. 마찬가지로 대부분의 사람들은 컴퓨터 외부의 "파일"을 거의 다루지 않으므로 "종이 파일과 같은 디렉토리 및 전화 번호부와 같은 디렉토리"라고 말하는 것이 더 명확 할 것입니다.
IMSoP

2
@IMSoP 세대 차이입니다. 컴퓨터 이전에는 전화 번호부가 일종의 디렉토리 중 하나였습니다. 케임브리지 사전은 말한다 : " 디렉토리 : 이름, 주소, 또는 다른 사실들의 목록을 제공하는 책 [... example] 전화 번호부에서 번호를
찾아라

2
@kubanczyk 실제로-사전 디지털 사무실에서 일하는 사람들에게 은유가 너무 분명 해져서 설명하기가 거의 모호하다고 생각합니다. 그러나 우리 세대와 그 이하의 사람들에게는 왜 자동차 뒷면의 저장 공간이 "부팅"또는 "트렁크"라고 불려 지므로 실제로 철자를 써야합니다.
IMSoP

"하드 링크에 inode 번호가 없습니다"라는 문구에서 "have"라는 단어는 "하드 링크가 이름을 inode 번호와 연결합니다"라고 말했기 때문에 오해의 소지가 있습니다. "hardlink"디렉토리 엔트리의 데이터 구조는 실제로 inode #를 포함합니다. 이것은 링크가 inode #와 "연관"되는 방식입니다. "하지 않았습니다"라는 말은 하드 링크에 디스크에 링크가 저장된 위치를 나타내는 inode #가 없다는 것을 의미합니다.
Kelvin

2
파일이 있음을 말하는 아이 노드 다소 뒤로이다. inode는 "데이터 범위"에 대한 정보를 포함하는 구조입니다. inode가 없으면 파일이 없습니다.
Barmar

18

하드 링크는 디렉토리 항목입니다. 파일 이름이 다르거 나 다른 디렉토리에있는 경우 파일에 여러 디렉토리 항목이있을 수 있습니다. 동일한 파일의 다른 디렉토리 항목과 관련하여 디렉토리 항목을 "하드 링크"라고합니다.

inode에는 파일 이름 및 내용 (내용 위치, 권한, 타임 스탬프 등) 이외의 파일 메타 데이터가 포함됩니다. 파일 당 하나의 inode가 있습니다. 모든 파일 시스템이 메타 데이터를 디스크에서 명확하게 식별 할 수있는 공간에 배치하는 것은 아니지만 "inode"라고 할 수 있지만 일반적인 아키텍처입니다. 디렉토리 항목은 이름을 inode에 연결합니다. 둘 이상의 디렉토리 항목이 동일한 inode에 링크 될 수 있으므로 용어 "link"가 가능합니다. 이러한 링크를 "소프트 링크"또는 "기호 링크"에 반대하여 "하드 링크"라고합니다. "이 이름에는이 inode를 사용하십시오"라는 말이 아니라 "이 이름에는 다른 이름을 찾으십시오"라고 말합니다.

파일을 방으로, 디렉토리 항목을 문으로 생각하십시오. “파일 열기 /foo/bar”는“복도 /foo로 이동하고 방으로 가십시오”를 의미 bar합니다. “방에 가라 bar”는 실제로“표시된 문을 열고 bar방에 들어간다”를 의미하지만“방에 가라 bar”는 똑같은 말을 더 짧은 방법으로 말할 수있는 탁월한 방법입니다. 같은 방으로 이어지는 두 개 이상의 문을 가질 수 있습니다.

기존 파일 ( ln existing new)에 대한 하드 링크를 만들면 동일한 파일에 대한 두 번째 링크를 작성하는 것입니다. 즉, 기존 파일에 링크하는 새 디렉토리 항목을 작성하는 것입니다. 생성 후 두 디렉토리 항목의 상태는 동일합니다. "기본"항목과 "보조"항목 중 하나는 없으며 동일한 파일에 대한 링크 일뿐입니다.

파일 자체를 제거하지 않고 파일에 대한 모든 링크를 제거 할 수도 있습니다. 프로그램이 여전히 파일을 연 상태에서 파일을 삭제하면 (즉, 모든 디렉토리 항목을 제거하는 경우) 발생합니다. 파일은 파일 시스템에 남아 있으며 파일을 연 마지막 프로세스가 파일 시스템을 닫을 때만 실제로 제거됩니다. 방 문 비유에서 문이없는 방은 여전히 ​​공간을 차지합니다.


하드 링크와 소프트 링크는 각각 처음 도입 된시기는 언제입니까?
n611x007

2
@ n611x007 : 새로운 질문 이나 후속 질문이있는 경우 새 질문을 열 수 있습니까? 의견 섹션은 새로운 질문이나 확장 된 토론에 적합하지 않습니다. 감사.
David Foerster

1
@ n611x007 하드 링크는 Unix보다 오래 되었습니다 . v1에는 링크가 있습니다 . 유닉스의 심볼릭 링크는 조금 더 최신입니다. 위키 백과 에는 몇 가지 역사가 있습니다.
Gilles 'SO- 악마 그만두 다'

방과 문은 대단합니다! 그러면 심볼릭 링크는 문 표시와 같습니다.
curiousdannii

1
@curiousdannii : 심볼릭 링크 더 "대신 # 234 오이 M8 잘못된 사무실 이동"을 말한다 그들에 앉아 사람과 실처럼
모니카와 밝기 경주

8

다른 모든 답변 외에도 다음과 같은 중요한 속성을 지적하고 싶습니다.

소프트 링크는 실제 참조입니다. 즉, 경로 이름이 포함 된 작은 파일입니다. 소프트 링크 해결은 응용 프로그램에 투명하게 발생합니다. 프로세스가 파일을 열면, /this/path/here이를 가리키는 심볼릭 링크 라고 말하면 /that/other/path전체 열기 처리 /that/other/path는 OS에 의해 수행됩니다. 또한 /that/other/path심볼릭 링크 자체 인 경우 OS에서도 처리됩니다. 실제로 OS는 다른 파일 (예 : 일반 파일)을 찾을 때까지 또는 많은 항목에 도달 할 때까지 SYMLOOP_MAX(링크 참조 sysconf(3)) OS (심볼 : 해당 시스템 호출)에서 오류를 반환하고 errnoELOOP. 따라서 순환 참조 xyz -> xyz는 프로세스를 중단시키지 않습니다. (Linux 시스템의 경우 자세한 내용 path_resolution(7)을 참조 하십시오.)

프로세스는 경로 이름이 심볼릭 링크인지 아닌지를 확인 lstat(2)하고 파일 속성 (아이 노드 테이블에 저장 됨)을 통해 lchown(2)다른 속성을 수정할 수 있습니다 ( symlink(7)전체 내용 참조 ).

이제 권한 측면에서 심볼릭 링크에는 항상 권한 rwxrwxrwx기호 (777 )가 있음을 알 수 있습니다. 어쨌든 실제 파일에 액세스하여 다른 권한을 무시할 수 있기 때문입니다. 반대로, 심볼릭 링크의 777은 심볼릭 링크 된 파일을 처음에 액세스 할 수없는 경우 액세스 가능한 파일로 만들지 않습니다. 예를 들어, 권한 777을 가진 파일을 가리키는 권한 777을 가진 심볼릭 링크는 파일이 "다른"(일반인)에게 액세스 할 수 없게합니다. 다시 말해서, 파일 xyz은 파일 이 직접 액세스 가능한 경우, 즉 간접적 인 경우에만 심볼릭 링크를 통해 액세스 할 수 있습니다. 따라서 심볼릭 링크의 권한은 보안에 아무런 영향을 미치지 않습니다.

하드 링크와 심볼릭 링크 (일명 소프트 링크)의 주요 차이점 중 하나는 심볼릭 링크가 파일 시스템에서 작동하지만 하드 링크는 하나의 파일 시스템으로 제한되어 있다는 것입니다. 즉, 파티션 A의 파일은 파티션 B에서 심볼릭 링크 될 수 있지만 거기서 하드 링크 할 수는 없습니다. 이것은 하드 링크가 실제로 파일 이름과 inode 번호로 구성된 디렉토리의 항목이며 inode 번호는 파일 시스템마다 고유하다는 사실에서 분명합니다.

하드 링크라는 용어는 실제로 다소 오해의 소지가 있습니다. 심볼릭 링크의 경우 소스와 대상을 명확하게 구분할 수 있지만 (심볼릭 링크는 inode 테이블에 고유 한 항목이 있음) 하드 링크에는 해당되지 않습니다. 파일에 대한 하드 링크를 만들면 원래 항목과 하드 링크를 처음에 있던 항목과 구별 할 수 없습니다. (동일한 inode를 참조하기 때문에 소유자, 권한, 타임 스탬프 등과 같은 파일 속성을 공유합니다.) 이는 모든 디렉토리 항목이 실제로 하드 링크이며 파일을 하드 링크하면 두 번째 ( 또는 세 번째 또는 네 번째 ...) 하드 링크. 실제로, 각 inode는 해당 inode에 대한 하드 링크 수에 대한 카운터를 저장합니다.

마지막으로 일반 사용자는 디렉토리를 하드 링크하지 않을 수 있습니다. 이것은주의를 기울여 수행해야하기 때문입니다.주의를 기울이지 않는 사용자는 엄격하게 계층적인 파일 트리에주기를 도입 할 수 있습니다.이 트리는 모든 일반적인 도구 (예 :) fsck및 OS 자체가 처리 할 준비가되어 있지 않습니다.


6

간단한 대답 :

  • 디렉토리의 파일 항목은 해당 파일에 대한 하드 링크입니다.

  • 동일한 파일에 대한 여러 개의 하드 링크가 허용되므로 일부 파일에는 하나 이상의 하드 링크가 있습니다.


3

유닉스 초기에는 파일이 내부적으로 특정 디스크 드라이브의 inode였습니다. 파일 이름은보다 친숙한 방법으로 액세스 할 수있었습니다.

하드 링크가 하나 이상의 파일 이름을 inode에 지정했습니다. 파일을 만들고, 두 번째 이름을 하드 링크하고 이름을 삭제하면 처음에 두 번째 이름으로 파일을 만든 것과 구분할 수 없었습니다.

실제로 프로그램이 파일을 삭제하는 데 사용해야하는 시스템 호출은 'unlink (2)`입니다. 성은 inode에서 연결이 해제 될 때까지 데이터가 사라지지 않습니다. (그리고 어딘가에 프로세스에 의해 inode가 열리지 않습니다)

이것이 리눅스가 프로그램을 실행하면서 더 쉽게 업그레이드 할 수있게하는 것입니다. 프로세스가 실행 파일을 실행 중이고 업데이트가 발생하면 프로그램 이름이 재사용되지만 이전 버전을 포함하는 inode가 여전히 존재하므로 계속 실행할 수 있습니다. 이전 버전을 실행하는 마지막 프로세스가 중지되면 해당 이전 버전 스토리지가 해제됩니다.

소프트 링크는 여러 개의 마운트 지점이있는 단일 파일 트리가있을 때 하나의 하드 드라이브에서 다른 하드 드라이브의 inode로 하드 링크를 만들 수 없기 때문에 발생했습니다. 그래서 소프트 링크가 발명되었습니다.



2
early days왜 지금 다른가? 당신의 대답은 어쨌든 그 견해를 반영하지 않는 것 같습니까?
n611x007

@ n611x007 리눅스와 같은 '일'은 inode 모델에 맞지 않는 비 유닉스 유형 파일 시스템을 마운트 할 수 있기 때문입니다. 예를 들어 FAT 파생물 및 ISO-9660과 같습니다. 대신 한 크기의 훨씬 더 다양한 파일 시스템 생태학 모두 맞는입니다
infixed

1

파일은 디스크에 기록 된 데이터입니다. 이 데이터는 inode에 의해 참조되는데, 여기에는 파일에 대한 메타 데이터가 포함되어 있으며이 파일에 사용되는 디스크의 블록을 시스템에 알려주는 파일에 대한 메타 데이터가 포함되어 있습니다. 하드 링크는이 파일의 inode 번호를 가리 킵니다.

기술적으로, 예, 새 파일을 작성하고 있지만이 파일에 포함 된 모든 파일은 참조하는 파일의 inode 번호와 이름입니다. 아이 노드에 대한 포인터 나 파일에 대한 포인터를 만드는 것으로 생각하는 것이 좋습니다.


1

파일은 파일 시스템의 항목에 대해 널리 사용되는 개념입니다.

일반적으로 Directory , Regular File (하드 링크) 및 Symbolic Link (소프트 링크)가 포함됩니다. 그리고 장치와 소켓을 포함 할 수도 있습니다.

내 질문은 단순히 파일과 하드 링크의 차이점은 무엇입니까? 하드 링크가 inode를 가리키고 있으므로 파일이란 무엇입니까? 아이 노드 항목 자체? 또는 하드 링크가있는 Inode?

터치로 파일을 만든 다음 Inode 테이블에 Inode 항목을 만듭니다. 그리고 파일과 동일한 Inode 번호를 가진 하드 링크를 만듭니다. 새 파일을 만들었습니까? 또는 파일이 방금 Inode?

심볼릭 링크조차도 일반적으로 파일로 계산되므로 하드 링크 자체도 파일로 계산할 수 있습니다. 하드 링크인지 소프트 링크인지에 관계없이 파일이라고 말할 수 있습니다.

개념은 약간 모호하므로 inode 항목은 파일이라고 말할 수도 있지만 실제로 데이터를 참조하고 싶을 수도 있습니다.

C ++ 또는 Java 프로그래머 인 경우 std :: filesystem :: file_type , java.io.Filejava.nio.file.Files에 대해 읽으려고 할 수 있습니다 .

하드 링크와 소프트 링크의 차이점에 대한 자세한 내용은 infixed의 주석 링크에서 찾을 수 있습니다.


1

주어진 이름을 가진 "파일"과 "하드 링크"의 차이점은 역사 중 하나입니다. 주어진 이름을 가진 (일반) 파일은 creat 시스템 호출을 사용하여 생성되고, 하드 링크는 링크 시스템 호출을 사용하여 생성됩니다.

그러나 인간은 디렉토리 항목의 역사에 대해 이야기하고 기억하고 파일과 하드 링크를 적절하게 호출하지만 파일 시스템은 그렇지 않습니다. "원본 파일"및 "하드 링크"의 디렉토리 항목은 품질면에서 완전히 구별 할 수 없습니다. 파일 이름과 파일의 inode 사이에 참조를 설정하고 마지막으로 참조가 사라지면 (참조는 파일 이름이 아니라 파일뿐만 아니라 열린 파일에 액세스 할 수있는 파일 디스크립터), 참조되지 않은 inode의 파일은 삭제 된 것으로 간주되고 inode 및 관련 파일 공간이 회수됩니다.

따라서 인간이 "파일"과 "하드 링크"를 대조 할 때, 첫 번째는 "링크 수 1"이되고 나머지는 모두 링크 수가 더 커졌습니다. 차이점은 학문적이며 실제로 한 번에 파일 이름을 바꾸면 대상 이름에 대한 하드 링크를 만든 다음 소스 이름에 대한 링크를 제거해야합니다. 요즘에는 일반적으로 단일 시스템 호출이 사용됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.