/ bin에 심볼릭 링크와 하드 링크가 혼합되어있는 이유는 무엇입니까?


10

심볼릭 링크와 하드 링크의 기술적 차이점을 이해합니다. 실제로 사용되는 것에 대한 질문입니다. 특히 /bin디렉토리가 비슷한 조건에서 왜 사용되는지 궁금합니다 .

내 시스템에 목록이있는 조각이 있습니다.

~$ ls -lai /bin
total 10508
32770 drwxr-xr-x  2 root root    4096 Jun 14 11:47 .
    2 drwxr-xr-x 28 root root    4096 Sep  6 13:15 ..
  119 -rwxr-xr-x  1 root root  959120 Mar 28 22:02 bash
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bunzip2
  127 -rwxr-xr-x  1 root root 1832016 Nov 16  2012 busybox
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzcat
 6191 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzcmp -> bzdiff
 5640 -rwxr-xr-x  1 root root    2140 Dec 15  2011 bzdiff
 5872 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzegrep -> bzgrep
 3520 -rwxr-xr-x  1 root root    4877 Dec 15  2011 bzexe
 6184 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzfgrep -> bzgrep
 5397 -rwxr-xr-x  1 root root    3642 Dec 15  2011 bzgrep
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzip2
 2851 -rwxr-xr-x  1 root root   10336 Dec 15  2011 bzip2recover
 6189 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzless -> bzmore
 5606 -rwxr-xr-x  1 root root    1297 Dec 15  2011 bzmore

더 나은 가시성을 위해 동일한 inode에 대한 하드 링크를 들여 쓰기했습니다. 그래서 심볼릭 링크는 경우에 사용되는 bzcmp, bzegrep, bzfgrep, bzless의 경우와 하드 링크 bzip2, bzcat, bunzip2?

그것들은 모두 디렉토리가 아닌 일반 파일이며, 하나의 파일 시스템 안에 있으며, 시스템 유틸리티이며 bzip 아카이브와 같은 작업을하기 위해 만들어졌습니다. 이 특별한 경우에 하드 링크 / 심볼릭 링크를 사용하는 이유는 순수한 역사적입니까? 아니면 뭔가 빠졌습니까?

내 질문에 대한 설명 :

나는 묻지 않았다 .

  • 심볼릭 링크와 하드 링크의 기술적 차이점
  • 이론적 장단점

이 질문들은 SO의 다른 스레드에서 해결되었습니다. 관련 시스템 유틸리티 그룹에 대해 특정 경우에 다른 결정이 내려진 이유를 이해하려고합니다. 기술적으로는 모두 심볼릭 링크이거나 하드 링크 일 수 있습니다. 두 옵션 모두 작동합니다 (두 경우 모두 프로그램을 통해 어떻게 호출했는지 파악할 수 있음 argv[0]). 여기에 의도가 있다면 이해하고 싶습니다.

관련 :


패키지 관리자가 결정해야 할 부분이라고 생각합니다. fe 나는 gentoo를 실행하고, 나의 /bin세 번째 열에 ls -lai는 항상 1소프트 링크 만 사용하는 것 같습니다. 어떤 배포판을 사용하십니까?
재생

나는 Ubuntu 12.04를 사용한다
Dmitry Pashkevich

1
언뜻보기에는 "바이너리에 대한 하드 링크, 스크립트 / 래퍼에 대한 심볼릭 링크" 유형의 규칙으로 보입니다 .
peterph

답변:


5

하드 링크와 심볼릭 링크를 사용하는 이유

이 시나리오에서 기호 링크보다 하드 링크를 사용하면 주로 3 가지 장점이 있습니다.

하드 링크

  1. 하드 링크를 사용하면 링크가 inode를 직접 가리 킵니다.
  2. 하드 링크는 여러 개의 실행 파일 사본을 갖는 것과 같지만 하나의 디스크 공간 만 사용합니다.
  3. 아무것도 끊지 않고 하드 링크의 분기 이름을 바꿀 수 있습니다.

심볼릭 링크

  1. 링크는 객체를 가리킨 다음 inode를 가리 킵니다.
  2. 파일 시스템을 확장 할 수 있지만 하드 링크는 할 수 없습니다.

일반적으로 연결의 장점

이러한 링크는 많은 실행 파일이 호출 방식에 따라 다르게 작동하기 때문에 존재합니다. 예를 들어 2 개 개의 명령의 경우 bzlessbzmore, 실제로 하나의 실행 파일입니다 bzmore. 실행 파일은 실행하는 데 사용 된 이름에 따라 다르게 작동합니다.

이것은 여러 가지 이유로 수행됩니다. 다음은 더 확실한 것들입니다.

  1. 다수가 아닌 단일 실행 파일을 쉽게 개발
  2. 디스크 공간 절약
  3. 보다 쉬운 배포

왜 둘 다 사용됩니까?

이 특정 응용 분야에서 어느 쪽을 선택하든 문제가 없습니다. 단일 실행 파일이 오버로드 될 수 있도록 별명으로 작동하는 기능을 용이하게 할 수 있습니다. 그것은 실제로 다양한 프로그램의 개발자들에 의해 악용되는 핵심 기능입니다.

상기 찾고에서 FHS (파일 시스템 계층 구조 표준) 심지어이 될 수있다, 이런 식으로 지정합니다.

발췌

/ bin / sh가 실제 Bourne 쉘이 아닌 경우 실제 쉘 명령에 대한 하드 링크 또는 기호 링크 여야합니다.

이것의 근거는 sh와 bash가 반드시 같은 방식으로 동작하지 않을 수도 있기 때문입니다. 또한 심볼릭 링크를 사용하면 / bin / sh가 진정한 Bourne 쉘이 아님을 쉽게 확인할 수 있습니다.

...

...

gunzip 및 zcat 프로그램이 존재하는 경우 gzip에 대한 심볼릭 링크 또는 하드 링크 여야합니다. / bin / csh는 / bin / tcsh 또는 / usr / bin / tcsh에 대한 심볼릭 링크 일 수 있습니다.

참고 문헌


예, 이해합니다.하지만 때로는 심볼릭 링크가 사용되는 경우가 있고 때로는 하드 링크가 사용되는 이유는 무엇입니까?
위에서

@DmitryPashkevich-확인 답변을 리팩토링했습니다. 더 나은지 알려주세요.
slm

어쩌면 나는 멍청한 질문을하고 있지만 여전히 답이 없다고 생각합니다. 그렇습니다. 나는 두 종류의 링크의 기술적 차이점과 장점 / 단점에 익숙합니다. 특정 사례를 이해하려고합니다. 왜 내 /bin/디렉토리 에 하드 링크와 심볼릭 링크가 모두 있습니까? 이러한 유틸리티 의 개발자가 왜 하나의 링크 유형을 고수 하지 않았 습니까?
Dmitry Pashkevich

(희망
스럽게

@DmitryPashkevich-추가 콘텐츠가 추가되었습니다. 도움이되는지 알려주세요.
slm

5

기존의 관행에서 어떤 종류의 링크를 사용할지 알려주는 비 기술적 규칙이 있는지 알아 내려고하는 것 같습니다. ( 기술적 인 이유를 이미 알고 있기 때문에 비 기술적 이라고합니다.)

대답은 다른 규칙이 없다는 것입니다. 우분투 bzip2패키지 에서 지적한이 예제 는 많은 개발자들이 많은 예고없이 그것들을 혼합한다는 것을 보여줍니다. 기술적 인 차이 외에 다른 강력한 지침이 없기 때문에 차이가 작기 때문입니다.

개인적으로, 나는 항상 자신의 문서화 특성과 대가로 작은 오버 헤드를 지불하기 때문에 symlink를 선호합니다.

다른 개발자들은 그들이 제공하는 작은 효율성을 위해 하드 링크를 선택할 것입니다.

이 문제는 스페이스 대 탭 또는 동적 대 정적 타이핑 또는 Emacs 대 vi 매우 유사 하여 거룩한 전쟁 을 일으키기에 충분하지 않습니다 . 더 흥미로운 전투와 마찬가지로 두 가지 옵션 중 하나를 선택해야 할 이유가 있지만, 어느 쪽을 사용해야하는지 알려주지 않으면 자신에게 더 적합한 것을 선택해야합니다.


1
당신의 관점을 공유해 주셔서 감사합니다! 나는 심볼릭 링크의 "자기 문서화"자연이 간과 종종 뭔가 생각
드미트리 Pashkevich
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.