하드 링크와 심볼릭 링크의 차이점은 무엇입니까?

제목에서 알 수 있듯이 명령으로 만든 하드 링크와 소프트 링크의 차이점을 알고 싶습니다 ln. 이 명령 man ln은 정보를 제공하지만 내 질문에 충분히 대답하지 못합니다.

또한 누군가가 심볼릭 링크보다 하드 링크를 선호하는 설정을 제공 할 수 있다면 좋을 것입니다.

Linux / Unix에서 바로 가기는 링크라고합니다.

링크는 소프트 링크 (기호 링크) 또는 하드 링크의 두 가지 유형입니다.

1. 소프트 링크 (기호 링크)

   파일 및 디렉토리에 대한 링크를 만들 수 있으며 다른 파티션에서 원본과 다른 inode 번호로 링크 (바로 가기)를 만들 수 있습니다.

   경우 실제 사본이 삭제 링크가 작동하지 않습니다 .

2. 하드 링크

   하드 링크는 파일 전용입니다. 다른 inode 번호를 가진 다른 파티션의 파일에 링크 할 수 없습니다.

   경우 실제 사본이 삭제됩니다 링크는 작동 이 실제 사본이 접근 된 기본 데이터에 액세스하기 때문에.

질문 : 소프트 링크는 어떻게 만듭니 까?

답 : 소프트 링크는 ln -s; 먼저 소스를 정의한 다음 대상을 정의해야합니다. 소스와 대상의 전체 경로를 정의해야합니다. 그렇지 않으면 작동하지 않습니다.

 sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib32/libGL.so.1
             (----------Source-------)             ( Destination )

보시다시피 다른 inode를 가지고 있으며 다른 파티션에서 만들 수 있습니다.

질문 : 하드 링크는 어떻게 만드나요?

답 : 하드 링크는 ln; 먼저 소스를 정의한 다음 대상을 정의해야합니다. 소스와 대상의 전체 경로를 정의해야합니다. 그렇지 않으면 작동하지 않습니다.

/script디렉토리에 스크립트가 있다고 가정 해 봅시다 firefox.

 ls -i # Shows you the inode
 5898242 firefox

 ln /scripts/firefox /scripts/on-fire
       ( Source )    ( Destination )

보시다시피, 동일한 inode가 있습니다. 원본을 삭제하면 링크가 작동하고 원본으로 작동합니다.

위의 링크가 작동하는지 확인한 다음 원래 firefox 스크립트를 삭제하십시오.

당신은 질문 : 누군가가 기호 링크보다 하드 링크를 선호 할 수있는 설정을 제공 할 수 있다면 좋을 것입니다.

답변 : 디스크 파티션 레이아웃에 따라 하드 링크 는 동일한 파티션 (-1 포인트) 에 있어야 하고 파일 (-1 포인트) 에만 링크 할 수 있다는 제한이 있지만 원본이 링크를 삭제 한 경우 +1 포인트 작동하고 원본처럼 작동합니다.

반면, 소프트 링크는 디렉토리 또는 파일 (+1 포인트)을 가리킬 수 있으며 파티션 제한 (+1 포인트)은 없지만 소스가 삭제되면 (-1 포인트) 링크가 작동하지 않습니다.

하드 링크는 파일에 대한 포인터가 아니며 동일한 inode를 가리키는 디렉토리 항목 (파일)입니다. 다른 파일의 이름을 변경하더라도 하드 링크는 여전히 파일을 가리 킵니다. 다른 파일을 새 버전으로 바꾸면 (복사) 하드 링크가 새 파일을 가리 키지 않습니다. 동일한 파일 시스템 내에서만 하드 링크를 가질 수 있습니다. 하드 링크를 사용하면 원본 파일과 링크에 대한 개념이 없으며 모두 동일합니다 (객체에 대한 참조로 생각하십시오). 매우 낮은 수준의 개념입니다.

반면에 심볼릭 링크는 실제로 다른 경로 (파일 이름)를 가리 킵니다. 심볼릭 링크를 통해 파일에 액세스 할 때마다 파일 이름을 확인합니다. 파일을 이동하면 심볼릭 링크가 따르지 않습니다. 이름을 유지하면서 파일을 다른 파일로 바꾸면 symlink가 새 파일을 가리 킵니다. 심볼릭 링크는 파일 시스템으로 확장 될 수 있습니다. 심볼릭 링크를 사용하면 실제 파일과 심볼릭 링크를 명확히 구분할 수 있습니다. 심볼릭 링크는 가리키는 파일의 경로 옆에 정보를 저장하지 않습니다.

"그림은 천 단어의 가치가있다."

"예를 들어 백 단락의 가치가 있습니다 ..."

두 개의 파일을 작성하십시오.

$ touch blah1   
$ touch blah2

그들에 데이터를 입력하십시오 :

$ echo "Cat" > blah1
$ echo "Dog" > blah2

그리고 예상대로 :

$cat blah1; cat blah2
Cat
Dog

하드 링크와 소프트 링크를 만들어 봅시다 :

$ ln blah1 blah1-hard
$ ln -s blah2 blah2-soft

방금 일어난 일을 봅시다 :

$ ls -l

blah1
blah1-hard
blah2
blah2-soft -> blah2

blah1의 이름을 바꾸는 것은 중요하지 않습니다 :

$ mv blah1 blah1-new
$ cat blah1-hard
Cat

blah1-hard는 변경되지 않은 파일의 inode, 내용을 가리 킵니다.

$ mv blah2 blah2-new
$ ls blah2-soft
blah2-soft
$ cat blah2-soft  
cat: blah2-soft: No such file or directory

소프트 링크가 내용이 아닌 이름, 변경된 내용을 가리 키므로 파일의 내용을 찾을 수 없습니다.
마찬가지로 blah1이 삭제 되더라도 blah1-hard는 여전히 내용을 보유합니다. blah2가 삭제되면 blah2-soft는 존재하지 않는 파일에 대한 링크 일뿐입니다.

출처 : 굉장히 StackOverflow 에서 복사 !

둘 다 파일에 대한 포인터입니다. 차이점은 포인터 의 종류 입니다. 심볼릭 링크 는 이름 으로 다른 파일 을 가리 킵니다 . 여기에는 심볼릭 링크로 식별되는 특수 모드 비트가 있으며 그 내용은 실제 파일의 이름입니다. 이름 만 포함하기 때문에 해당 이름이 실제로 존재하지 않아도되거나 다른 파일 시스템에 존재할 수 있습니다. 이름이 지정된 파일을 바꾸면 (이름에 영향을주지 않고 내용 변경) 링크에 여전히 동일한 이름이 포함되므로 새 파일을 가리 킵니다. 심볼릭 링크를 쉽게 식별하고 해당 링크가 가리키는 파일 이름을 볼 수 있습니다.

하드 링크는 inode 번호로 파일을 가리 킵니다. 따라서 하드 링크는 파일의 이름과 다르지 않습니다. "실제"이름 대 하드 링크 이름은 없습니다. 모든 하드 링크는 파일의 유효한 이름입니다. 이 때문에, 링크하는 파일이 실제로 존재해야하며 링크를 작성하려는 동일한 파일 시스템에 있어야합니다. 원래 이름을 삭제해도 하드 링크는 여전히 동일한 파일을 가리 킵니다. 모든 하드 링크는 파일에 대해 동일한 유효한 이름이므로 파일을 볼 수 없으며 파일의 다른 이름을 볼 수 없습니다. 이것을 찾으려면 모든 파일을보고 inode 번호를 비교하여 동일한 inode 번호를 가진 다른 이름을 찾아야합니다.

의 출력에서 ​​파일의 이름 수를 알 수 있습니다 ls -l. 파일 모드 다음의 첫 번째 숫자는 링크 수입니다. 링크가 2 개 이상인 파일에는 다른 이름이 있고 반대로 링크 수가 1 인 파일에는 (다른) 하드 링크가 없습니다.

하드 링크는 동일한 파일 시스템에서만 작동 할 수 있으며 동일한 inode의 다른 이름 일뿐입니다 (파일은 inode에서 내부적으로 참조 됨). 파일은 inode에 대한 마지막 링크가 없어진 경우에만 디스크에서 삭제됩니다 (마지막 링크는 rmd 또는 unlinkd입니다). 하드 링크는 일반적으로 디렉토리가 아닌 파일에 대해서만 작동합니다.

심볼릭 링크 (기호 링크)는 다른 파일에 대한 경로를 포함하는 특수 파일입니다. 이 경로는 절대적이거나 상대적 일 수 있습니다. symlinks는 파일 시스템에서 작동 할 수 있으며, 예를 들어 외장 하드 드라이브를 분리하고 같은 경로에 다른 파일이있는 다른 하드 드라이브로 교체하는 경우 다른 파일을 가리킬 수도 있습니다. 심볼릭 링크는 파일이나 디렉토리를 가리킬 수 있습니다.

다른 스레드 (현재 게시물의 상단에서 링크)의 답변 중 하나는 이 페이지에 대해 언급 했으며이 페이지 는 상당히 중간 수준의 설명이라고 생각합니다. 아스키 아트에서 길을 잃었다면 여기에 tl; dr 버전이 있습니다.

• 표준 파일은 파일 시스템에서 inode 로의 포인터이며 실제 데이터를 가리 킵니다. 파일 구성 요소는 파일 시스템에 대한 링크 (본질적으로 경로)와 inode에 대한 링크를 저장합니다.
• 하드 링크는 파일과 같습니다. 그들은 단지 inode에 대한 추가 포인터 일뿐입니다.
• 심볼릭 링크는 파일 시스템 경로를 파일에 저장하는 별도의 파일 (별도의 inode 및 데이터 포함)입니다.

관련된 커널과 파일 시스템은 모든 것을 투명하게 번역합니다.

따라서이를 바탕으로 :

• 하드 링크는 동일한 파일 시스템 링크 만 허용합니다. 심볼릭 링크는 모든 경로를 가리킬 수 있습니다.
• 하드 링크는 기본적으로 절대 데이터를 가리 킵니다. 심볼릭 링크 (예 : 상대 경로를 가리킬 수 있습니다 ../parent.file)
• 또한 하드 링크의 대상 포인터를 이동하면 (하드웨어 자체는 본질적으로 inode를 가리키는 하드 링크 임) 하드 링크는 여전히 작동합니다. 심볼릭 링크의 대상을 이동하면 일반적으로 심볼릭 링크가 끊어집니다.
• 하드 링크를 해결하는 것이 더 빠르지 만 측정 할 수 없을 정도로 그렇습니다. 속도의 중요하지 않은 부분은 융통성없는 파일 시스템을 희생시킵니다.

나는 약간 혼란 스러울 수 있지만 다양한 내용을 읽고 표준 파일과 하드 링크의 차이점을 찾기 위해 고심하고 있습니다. 내가 읽는 방식은 모든 파일이 하드 링크 (파일 이름 저장)로 구성되어 실제 데이터를 가리키는 inode에 연결됩니다.

하드 링크를 추가하면 파일 시스템 기반 포인터가 추가로 inode에 제공됩니다. 맞습니까?

소프트 링크를 사용하는 경우 :

파일 시스템에서 링크 : 파일 시스템에서 파일을 링크하려면 symlinks / soft 링크 만 사용할 수 있습니다.

디렉토리 링크 : 디렉토리를 링크하려면 디렉토리에 대한 하드 링크를 만들 수 없으므로 소프트 링크를 사용해야합니다.

하드 링크를 사용하는 경우 :

스토리지 공간 : 하드 링크를 생성하는 동안 새로운 inode가 생성되지 않으므로 하드 링크는 매우 무시할만한 공간을 차지합니다. 소프트 링크에서 공간을 소비하는 파일을 만듭니다 (일반적으로 파일 시스템에 따라 4KB).

성능 : 다른 파일을 거치지 않고 디스크 포인터에 직접 액세스하므로 하드 링크에 액세스하는 동안 성능이 약간 향상됩니다. 파일 위치 이동 : 소스 파일을 동일한 파일 시스템의 다른 위치로 이동하면 하드 링크는 여전히 작동하지만 소프트 링크는 실패합니다.

중복성 : 데이터의 안전을 보장하려면 하드 링크와 같이 하드 링크를 사용해야합니다. 소프트 링크의 링크 대신 파일에 대한 모든 링크가 삭제 될 때까지 데이터는 안전합니다. 파일의 마스터 인스턴스가 삭제 된 경우 데이터

"파일 이름"과 하드 링크의 차이점이 없기 때문에 차이점을 찾으려고 할 때 혼란이 발생합니다.

생성하는 모든 파일은 디스크의 데이터와 하드 링크 ( 디렉토리의 파일 이름 및 디스크의 데이터에 대한 포인터)로 구성됩니다. 이야기의 끝. 마지막 (또는 유일한) 하드 링크가 삭제되면 OS는 데이터가 더 이상 필요하지 않다는 것을 알게됩니다.

이것으로부터 실제 데이터가 절대 삭제되지 않고 하드 링크 만 삭제됨을 알 수 있습니다. 디스크에 충분히 꽉 차면 다른 파일의 데이터가 데이터를 덮어 쓸 수 있습니다. 그때까지 삭제 된 파일의 데이터는 복구 될 수 있지만 하드 링크 없이는 찾기가 어렵습니다.

이전에 설명한대로 Symlink는 단순히 " <targetname>폴더에 이름이 지정된 파일이 있습니다"라고 알려줍니다 <targetfolder>. 그들은 하드 링크를 가리 킵니다. 그들은 데이터가 어디에 있는지 모릅니다. 하드 링크는 그것을 알고 있습니다.

매우 간단합니다. 파일 (및 디렉토리!)은 블록 장치의 주소 (HDD 등)에 저장됩니다. 일반적으로 단일 이름이 주소에 매핑되어 있으므로 파일을 얻는 방법입니다. 하드 링크는 동일한 주소에 매핑되는 두번째, 세번째, 등의 이름이다. 심볼릭 링크 이름 - - 대신 심볼을 의미하고 있으므로 제 이름에 매핑되는 제 이름이다. 커널에 관한 한, 심볼릭 링크 대상을 읽으면 커널이 멈추고 대상 값을 파일 이름 (더 많거나 적음)으로 시작으로 돌아가서 상대 심볼릭 링크는 가능하지만 크게 도움이되지 않습니다. 대상 이름은 사용자 공간 코드에서 명시 적으로 쿼리 된 경우를 제외하고 파일 시스템 레벨 이상으로 사용되지 않습니다.