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


답변:


40

하드 링크와 소프트 링크 사이의 다른 의미는 다른 것들에 적합합니다.

하드 링크 :

  • 모든 디렉토리 항목은 하드 링크 이기 때문에 다른 디렉토리 항목과 구별 할 수 없음
  • 동일한 원본에 대한 다른 하드 링크를 끊지 않고 "원본"을 이동하거나 삭제할 수 있습니다
  • 동일한 파일 시스템 내에서만 가능
  • 권한은 "원본"의 권한과 동일해야합니다 (권한은 디렉토리 항목이 아닌 inode에 저장 됨)
  • 디렉토리가 아닌 파일 에만 만들 수 있습니다

심볼릭 링크 (소프트 링크)

  • 단순히 다른 파일 경로를 가리키는 레코드입니다. ( ls -l심볼릭 링크가 가리키는 경로를 보여줍니다)
  • 원본을 옮기거나 삭제하면 끊어집니다. (어떤 경우에는 링크가 현재 특정 위치를 차지하는 파일을 가리키는 것이 바람직합니다)
  • 다른 파일 시스템의 파일을 가리킬 수 있습니다
  • 디렉토리를 가리킬 수있다
  • 일부 파일 시스템 형식에서는 심볼릭 링크가 가리키는 파일과 다른 권한을 가질 수 있습니다 (드문 경우 임)

1
좋은 목록입니다. 심볼릭 링크 자체를 이동하여 상대 경로 심볼릭 링크를 끊을 수도 있다고 덧붙였습니다.
jw013

4
"[E] 모든 디렉토리 항목은 하드 링크입니다." 그것은 내가 전에 표현한 적이없는 훌륭한 요점이지만, 누군가 링크를 감싸기 시작한 누군가가 그것을 얻지 못할 것이라고 걱정합니다. 이 상황의 사용자를위한 힌트는 다음과 같습니다. ls 명령을 실행할 때 표시되는 파일 및 디렉토리의 레이아웃은 그것이 나타내는 스토리지 시스템과 정확히 동일하지 않습니다. 하드 링크는 스토리지 시스템의 개별 파일에 대한 참조입니다. 파일이 한 번 저장됩니다. "아이 노드"를 읽어보십시오.
마리오

@ 마리오 : p. 모든 디렉토리 항목은 이름을 inode에 연결합니다. 파일 이름을 삭제하기위한 시스템 호출을 호출하기도합니다 unlink(2). "일반적인"파일 (링크 수 1)은 특별한 경우입니다. 도움이된다면 inode를 객체로, 이름을 ref-counted 포인터로 생각할 수 있습니다 (inode의 링크 수는 참조 수입니다).
Peter Cordes

1
심볼릭 링크는 이름이있는 텍스트 파일로 생각할 수 있습니다. 파일에 대한 특수 플래그로 인해 기호 링크로 해석됩니다. 알고있는 하드 링크 예는 ...입니다.
Ned64


18

두 유형의 링크의 요점은 파일을 동시에 두 위치에 표시하는 방법을 제공하는 것입니다. 이것은 많은 용도가 있습니다. 10 중 9 번은 심볼릭 링크를 사용하려고합니다.

심볼릭 링크 또는 "심볼릭 링크"는 Windows 바로 가기와 약간 비슷합니다. 심볼릭 링크의 내용은 파일 / 디렉토리의 실제 위치에 대한 포인터입니다. 실제 파일을 삭제하면 심볼릭 링크가 "매달려"작동하지 않습니다. 심볼릭 링크를 삭제해도 실제 파일은 삭제되지 않습니다. 단일 파일 (또는 다른 심볼릭 링크)에 원하는만큼의 심볼릭 링크를 가질 수 있습니다.

그러나 Windows와 달리 셸이나 응용 프로그램 수준이 아닌 파일 시스템 수준에서 작동하므로 거의 모든 응용 프로그램이 예상대로 심볼릭 링크를 "따릅니다". ls -al심볼릭 링크가 가리키는 위치를 확인하는 빠른 방법으로 사용할 수 있습니다.

하드 링크는 낮은 수준에서도 작동합니다. 하드 링크는 파일의 실제 물리적 파일 시스템 수준 디렉토리 항목입니다. 기술적으로 디렉토리 항목은 하드 링크이므로 각 파일에는 디렉토리 어딘가에 하나 이상의 하드 링크가 있습니다. 하드 링크는 그들이 가리키는 파일과 분리되지 않습니다. 파일에 다른 디렉토리에 여러 개의 하드 링크가있는 경우 rm모든 하드 링크가 사라질 때까지 유틸리티를 사용하여 하드 링크를 삭제해도 파일이 실제로 삭제되지는 않습니다.

의도적으로 파일이 삭제되는 것을 방지하거나 파티션이나 다른 파일 시스템 관련 작업으로 이상한 저수준 작업을 수행하지 않는 한 하드 링크 사용이 일반적이거나 필요한 상황을 생각할 수 없습니다. 편집 : 그러나이 질문에 대한 다른 답변에는 훌륭한 아이디어가 있습니다!


또한 심볼릭 링크에는 일반 파일과 같은 권한이 있지만 운영 체제는 해당 파일을 참조하지 않고 대신 권한 대상 파일을 참조하여 동작을 결정합니다. 그리고 원형 고리 체인을 수행하지 마십시오. 아주 나쁜.
LawrenceC

3
정말 나쁜가요? 무슨 일이 일어날 것? 내가 다시 만들 수있는 가장 흥분은 "너무 많은 수준의 심볼릭 링크"오류 메시지입니다.
mattdm

1
ls -lsymlink로 연결된 내용을 확인하기에 충분합니다.의 a약자 --all, 맨 페이지를 참조하십시오. 파일 시스템에서 심볼릭 링크가 작동하더라도 심볼릭 링크를 파일 대신 파일로 사용하는 대체 기능이 있습니다.
D4RIO

4
Windows 바로 가기는 실제로 심볼릭 링크와는 상당히 다릅니다. 대상을 따르며 일반 파일이기도합니다. (Windows에도 심볼릭 링크가 있지만 많이 사용되지는 않습니다.) 심볼릭 링크는 순전히 텍스트이므로 파일에 액세스 할 때마다 대상 텍스트를 읽습니다. symlink 권한이 중요한지 여부는 OS 및 파일 시스템에 따라 다릅니다.
Gilles

AFAIK에서 심볼릭 링크 파일의 내용은 심볼릭 링크가 가리키는 경로이며 심볼릭 링크 파일의 크기를 볼 때 볼 수 있습니다 ln -s /home 1; ls -l 1. 심볼릭 링크 1의 길이는 5 바이트 인 반면 ln -s /usr/share/ 2; ls -l 22의 길이는 11 바이트 인 것을 나타냅니다.
다니엘 쿨만

13

하드 링크는 디스크 기반 백업 메커니즘에 매우 유용합니다. 변경되지 않은 파일의 공간을 공유하는 동안 각 백업에 대한 전체 디렉토리 트리를 가질 수 있으며 파일 시스템은 참조 횟수를 추적하므로 마지막 참조 시점 공간이 부족하여 백업이 만료 / 제거되어 지정된 버전이 사라지면 사용 된 공간이 자동으로 회수됩니다. 일부 메일 클라이언트는 같은 이유로 여러 폴더에 보관 된 메시지에도이 메일을 사용합니다.


5
디스크 기반 버전 관리 메커니즘일까요? 무언가를 하드 링크하면 백업이 아닙니다. 원본 파일이 손상되면 모든 하드 링크도 손상됩니다.
D4RIO

1
Apple Time Machine과 같은 증분 백업 시스템을 생각해보십시오. (이것은 재난 복구 유형 백업이 아니라는 점이 분명합니다. 그러나 실수로 파일을 삭제했습니다.) 증분 백업에서 변경되지 않은 모든 파일은 함께 하드 링크됩니다. 파일이 변경되면 다음 증분은 이전 버전에 연결하는 대신 파일을 복사합니다.
geekosaur

감사합니다. 그러면 증분 백업 시스템은이 방식으로 버전 제어 시스템과 매우 유사합니다. = D
D4RIO

그러나 증분 백업 메커니즘은 파일의 "이전"버전을 어떻게 보존합니까? 1) 백업 A가 작성되어 파일 F를 하드 링크했습니다. 2) 파일 F 수정; 3) 다음 날 백업 B가 생성되었습니다 ... 내가 얻지 못한 것 같습니다
Dmitry Pashkevich

3

하드 링크는 동일한 디스크 공간에 대한 참조 일 뿐이므로 다른 파일 시스템에서 무언가를 하드 링크 할 수없는 '이유'입니다.

심볼릭 링크는 다른 파일 (Windows 바로 가기 등)을 연결하는 파일로, 같은 파일 시스템에있을 수도 있고 아닐 수도 있습니다.

편집 : 나는 뭔가 더 설명 할 것입니다. 존재하는 모든 파일에는 최소 1 개의 하드 링크가 있습니다. 하드 링크는 파일 시스템의 inode 컨텐츠에 액세스 하는 방법 입니다. 을 사용하여 파일의 inode 번호를 ls -i얻을 수 있으며이 stat예제에서 다음과 같이 하드 링크 수를 얻을 수 있습니다 .

$ stat plantilla-disenos.odt 
  File: «plantilla-disenos.odt»
  Size: 12367       Blocks: 32         IO Block: 4096   fichero regular
Device: 803h/2051d  Inode: 319875      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   d4rio)   Gid: ( 1000/   d4rio)
Access: 2011-02-11 21:36:19.000000000 -0300
Modify: 2010-03-02 23:27:28.000000000 -0300
Change: 2010-04-10 17:46:27.000000000 -0300

이 참조에 대해 @geekosaur에게 감사드립니다.

커널은 심볼릭 링크를 확장하기 위해 경로 이름 대 아이 노드 변환 (디렉토리 트리를 통과)을 다시 시작해야하지만 하드 링크는 모두 동일한 inode를 사용합니다. (종종 전통적인 유닉스에서 이것을 한 커널 함수의 이름에서 이것을 namei라고합니다.)

그리고 이것은 (편집) :

하드 링크는 Apple Time Machine과 같은 디스크 기반 증분 백업 메커니즘에 매우 유용합니다. 변경되지 않은 파일의 공간을 공유하면서 각 백업에 대한 전체 디렉토리 트리를 가질 수 있으며 파일 시스템은 참조 횟수를 추적하므로 공간 때문에 백업이 만료 / 제거되어 지정된 버전에 대한 마지막 참조가 사라지면 사용 된 공간이 자동으로 회수됩니다. 일부 메일 클라이언트는 같은 이유로 여러 폴더에 보관 된 메시지에도이 메일을 사용합니다.

건배


하드 링크를 사용하면 성능 이점이 있습니까? 아니면 왜 심볼릭 링크 대신 하드 링크를 사용하겠습니까?
ripper234

커널은 심볼릭 링크를 확장하기 위해 경로 이름 대 아이 노드 변환 (디렉토리 트리를 통과)을 다시 시작해야하지만 하드 링크는 모두 동일한 inode를 사용합니다. ( namei전통적인 유닉스에서 이것을 수행 한 커널 함수의 이름에서 이것을 종종이라고합니다 .)
geekosaur

@ ripper234 : 하드 링크는 디스크 공간 절약 솔루션입니다. 심볼릭 링크를 만들기 위해 파일 시스템에 대해 알 필요는 없지만 루프 또는 긴 해상도 경로를 만들 수 있으므로 심볼릭 링크를 만들기 전에 생각해야합니다 stat.
D4RIO

@geekosaur : 나는 그것이 매우 유용하기 때문에 당신의 대답을 추가하고 있습니다
D4RIO

문제 없어요. 나는 실제로 그것을 당신의 의견으로 쓰기 시작했지만 의견은 너무 짧습니다.
geekosaur

3

소프트 링크는 다른 경로 이름을 가리 킵니다. 해당 경로 이름이 실제로 존재하거나 존재하지 않을 수 있습니다. 심볼릭 링크에 액세스 할 때까지 경로를 찾지 않습니다. 액세스하려고 할 때 경로가 존재하지 않으면 심볼릭 링크가 손상된 것입니다.

하드 링크를 사용하면 여러 이름을 가진 하나의 파일이 있습니다. 그중 하나는 "실제"파일이고 다른 하나는 그 파일에 대한 링크 일뿐입니다. 그들은 모두 평등합니다. 심볼릭 링크가 끊어지는 방식으로 하드 링크가 끊어진 것과 같은 것은 없습니다.

하드 링크는 단일 파일 시스템 내에서만 작동합니다. 다른 파일 시스템 (예 : 다른 파티션 또는 네트워크 공유)에있는 파일에 연결하려면 소프트 링크 를 사용해야합니다 .

또 다른 큰 차이점은 링크 된 파일을 삭제할 때 발생하는 것입니다. 하드 링크 된 파일 쌍 중 하나를 삭제 한 다음 동일한 이름으로 새 파일을 생성하면 두 개의 별도 파일이 생성됩니다 (링크가 사라짐). 심볼릭 링크의 대상을 삭제하고 동일한 이름으로 새 파일을 만들면 링크가 새 파일을 가리 킵니다.


3

"하드"링크는 동일한 inode를 공유

$ touch foo
$ ln foo foolink # Creates a hard  link
$ ls -li foo foolink
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foo
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foolink

foo 또는 foolink를 편집하면 파일이 하나만 있으며 업데이트됩니다. 파일 이름 중 하나만 제거하면 inode와 데이터가 지속되고 foolink는 유지됩니다.

$ rm foo
$ ls -li foo foolink
ls: cannot access foo: No such file or directory
54996 -rw-r--r-- 1 bsd users 0 2011-12-11 09:06 foolink

"소프트"또는 심볼릭 링크를 사용하여 동일하게 만들려면 하나의 파일, 하나의 inode 및 자체의 inode가 첫 번째를 가리키는 새 파일이 있습니다.

$ touch foo
$ ln -s foo foolink # Create symlink
$ ls -li foo foolink
55029 -rw-r--r-- 1 bsd users 0 2011-12-11 09:11 foo
55033 lrwxrwxrwx 1 bsd users 3 2011-12-11 09:11 foolink -> foo

foo 또는 foolink를 편집해도 여전히 하나의 파일 만 있으며 업데이트됩니다.

심볼릭 링크 만 제거하면 inode와 데이터가 지속됩니다. foo를 제거하면 데이터가 사라지고 symlink는 유지되지만 존재하지 않는 파일을 가리 킵니다.

$ rm foo
removed `foo'
$ ls -l foo foolink 
ls: cannot access foo: No such file or directory
lrwxrwxrwx 1 bsd bsd 3 2011-12-11 09:11 foolink -> foo

1
그러나 이것에 대한 실제 사용 사례는 무엇입니까?
ewwhite

1
"바로 가기"와 동일한 사용 시스템에 여러 버전의 응용 프로그램이있는 또 다른 사용은 전체 경로로 앱을 지정하고 빈 버전의 심볼릭 링크를 프로덕션으로 지정하면서 새 버전을 설치하고 테스트 할 수 있습니다. 테스트가 완료되면 새 버전으로 심볼릭 링크를 변경 한 후 버전 종속 코드가있는 모든 사용자를 위해 이전 버전을 그대로 두십시오. Perl, python 등을 생각하십시오.
bsd

1
하드 링크의 실제 사용 사례. 현재 내 파일 시스템에서 / usr / share / zoneinfo에서 많은 수의 하드 링크를 발견했습니다. 시간대를 나타내는 모든 명명 된 파일을 생각해보십시오. 모두 EST와 동일합니다. 중복 사본이 없어 파일 시스템 공간을 절약하고 패키지를 설치 / 삭제할 때 symlinks의 관리 오버 헤드를 설치 / 삭제하지 않고도 패키지를보다 쉽게 ​​관리 할 수 ​​있습니다. 하나를 제거하더라도 원래 데이터는 보존됩니다. 좀 더 설명 할 시간이 없었습니다.
bsd

1

하드 링크는 동일한 파일에 대한 추가 디렉토리 항목입니다. 그것의 의미는

  • 디렉토리 항목이 다른 파일 시스템의 파일을 가리킬 수 없기 때문에 파일에 대한 모든 하드 링크는 동일한 파일 시스템에 있어야하지만 반드시 동일한 디렉토리에있을 필요는 없습니다.
  • 원래 디렉토리 항목과 새 하드 링크 사이에는 차이가 없습니다. 운영 체제의 관점에서 볼 때, 이들은 동일한 파일에 대한 두 개의 디렉토리 항목입니다. 모든 하드 링크가 삭제 된 경우에만 파일이 삭제됩니다 (또한 해당 파일이 열려있는 프로세스가 남아 있지 않음).
  • "원본"을 다른 파일 시스템으로 옮기지 않는 한 다른 파일 시스템으로 옮기거나 이름을 바꾸면 다른 하드 링크는 영향을받지 않습니다. 그들은 여전히 ​​같은 파일을 가리 킵니다.
  • 많은 편집자들이 저장할 때 새 컨텐츠를 동일한 파일에 쓰지 않고 다음 절차를 수행합니다.

    1. 새 컨텐츠를 파일에 작성 하십시오.
    2. 이전 파일의 이름을 백업 이름으로 바꾸십시오 (또는 이전 파일 버전의 백업을 유지하지 않는 경우 간단히 삭제하십시오).
    3. 새로 작성된 파일의 이름을 이전 파일 이름으로 바꿉니다.

    이 체계는 동일한 파일에 대한 다른 모든 하드 링크가 더 이상 현재 파일을 가리 키지 않고 이전 버전을 가리킴을 의미합니다 (유닉스에서 파일을 "삭제"하기 때문에 편집기가 이전 파일을 삭제하는 경우에도 마찬가지입니다) 삭제 된 링크가 실제 파일이 삭제되는 유일한 링크 인 경우에만 해당 링크를 삭제하는 것을 의미합니다.

  • 하드 링크는 파일로 직접 연결되므로 해당 파일의 원래 위치에 액세스 할 수없는 경우에도 해당 파일에 액세스 할 수 있습니다 (예 : 원래 항목이있는 디렉토리에 대한 권한이 없기 때문에) . 액세스 권한을 결정하는 유일한 권한은 파일 자체의 액세스 권한 (링크가 아닌 파일과 연결되어 있으며 동일한 파일에 대해 서로 다른 권한으로 하드 링크를 만들 수 없음)과 하드 링크 경로에 대한 액세스 권한입니다. 에 포함됩니다 (기본적으로 링크가있는 디렉토리의 실행 권한 및 모든 직간접 상위 디렉토리).

반면에 심볼릭 링크는 다른 파일 의 경로 이름 (파일의 이름 또는 디렉토리 항목 ( /bin/sh또는 경로를 포함하여 잠재적으로 포함 subdir/foo.bar))을 저장합니다. 경로 이름이 상대 경로 인 경우 경로가 포함 된 디렉토리를 기준으로 항상 해석됩니다. 이는 다음을 의미합니다.

  • 심볼릭 링크는 다른 파일 시스템 (FAT와 같은 하드 또는 소프트 링크를 자체적으로 지원하지 않는 파일 시스템)의 파일을 가리킬 수 있습니다.

  • 원본 파일이 삭제되면 심볼릭 링크는 파일 내용을 유지하지 않습니다. 동일한 파일에 대한 다른 하드 링크가 없으면 파일 내용이 사라집니다. 그런 다음 심볼릭 링크는 매달려 있습니다 (즉, 디렉토리 항목에 해당하지 않는 경로 이름 참조). 반면에 심볼릭 링크를 삭제해도 경로 이름 만 참조하므로 원본 파일에는 영향을 미치지 않습니다.

  • 원본 파일을 이동하거나 이름을 바꾸면 심볼릭 링크가 업데이트되지 않고 매달려 있습니다. 심볼릭 링크를 이동하면 상대 경로가 포함 된 링크 만 끊어지고 새 위치에서 경로가 더 이상 유효하지 않습니다.

  • 원본 파일이 동일한 이름의 새 파일로 대체되면 (위에서 설명한 편집기 시나리오에서와 같이) 링크는 새 파일을 나타냅니다.

하드 링크의 대부분의 사용은 기본적으로 파일 내용을 두 번 저장하지 않고도 파일 사본을 갖는 방법입니다. 이것은 파일이 다시 변경되지 않는 경우에 가장 효과적입니다. 그렇지 않으면 실수로 링크를 끊기가 쉽습니다 (위의 편집기 시나리오 참조). 이 경우, 물론 있습니다 원하는 새로운 백업에서 변경된 파일, 당신은 이전 백업에서 복사뿐만 아니라 변경하지 않는 경우 : 링크는 여러 백업을 유지하는 경우와 같이 나누어 질 수 있습니다.

일반적으로 링크를 원하면 기호 링크를 사용합니다. 예를 들어 디렉토리를 다른 파티션으로 옮길 때 (파티션이 가득 찼기 때문에) 이전 위치에서 새 파티션으로 소프트 링크를 설정할 수 있으므로 이전 위치의 디렉토리에 액세스하려는 모든 프로그램은 대신 새 장소에서 액세스하십시오. 하드 링크에서는 불가능합니다. 그러나 이동 된 디렉토리의 심볼릭 링크에 이동 된 디렉토리에서 나오는 상대 경로가 포함되어 있으면 끊길 수 있습니다.


1

하드 링크 (파일 만) vs 소프트 링크 (파일 또는 디렉토리) vs BIND (하드 디렉토리)

읽기 전에이 이미지를보십시오
(출처 : freesoftwareservers.com )

daxelrod의 답변이 질문을 잘 설명하지만,이 경우의 그림은 특히 inode와 복잡한 Linux 전문 용어를 아직 이해하지 못하는 초보자에게 큰 차이가 있다고 생각했습니다.

이것을 생각하십시오. 드라이브에서 모든 것을 "삭제"하면 1과 0이 여전히 있기 때문에 소프트웨어를 실행하여 데이터를 복원 할 수 있습니다. 모든 하드 링크를 삭제했습니다. 복구 소프트웨어의 목적은 하드 링크를 재구성하여 0과 1을 이해하는 것입니다.

나는이 모든 것이 의미가있는 위대한 "한 줄짜리"를 읽었고 공유하고 싶었다!

Linux의 모든 파일은 디스크의 0과 1에 대한 "하드 링크"입니다. 데이터 (0 및 1)를 만들면 OS는 파일 트리에 하드 링크를 만들어 하드 디스크의 해당 지점을 참조합니다.

HARD LINK 2를 작성하고 HARD LINK 1 원본 파일을 삭제하십시오 .

다른 하드 링크를 만들고 원본 파일을 삭제해도 새로 만든 하드 링크에 계속 액세스 할 수 있습니다.

다음으로 링크 된 파일 (HARD LINK 1)을 삭제하십시오.

HARD LINK 1을 삭제 한 경우 SOFT LINK가 작동한다고 생각하십니까? 아니요, OS는 HARD LINK 1이 존재하지 않는다고보고합니다.

하드 링크를 삭제하려면 소프트 링크를 삭제하십시오.

반대로, SOFT LINK를 삭제하면 HARD LINK가 작동합니까? 예. OS에 하드 링크 파일 이 하나 있으면 채우기가 삭제되지 않은 것으로보고됩니다.

-연구 / 주목할 가치가있는 것은 BIND입니다. 두 디렉토리를 심볼릭 링크하는 것과 같이 두 디렉토리를 바인딩하는 방법이지만 OS에 투명합니다 (OS는 Symlink를 알 수 있으며 날씨에 관한 규칙이 Symlink를 따를 수있는 규칙이 있음을 알려줍니다). LS가 아닌 마운트를 사용하며 FSTAB를 통해 구성 할 수 있습니다.

바인드 마운트 란?


1
그것은 특히 첫 번째 게시물에 대한 야심 찬 노력입니다. 불행히도, 나는 "바인드"(요청하지 않은)에 자료를 추가하는 것이 문제를 혼란스럽게한다고 생각합니다. 특히 "바인드"마운팅 을 설명 하기 위해 많은 노력을 기울이지 않은 것 같습니다 . 또한, 나는 하드 및 소프트 / 심볼릭 링크를 매우 잘 이해하고 있으며 귀하의 사진을 거의 이해하지 못합니다. 초보자가 무언가를 배울 수 있다면 매우 놀랐습니다.
G-Man

디렉토리를 심볼릭 링크 할 수는 있지만 파일 시스템에 심볼릭 링크로 표시되며, 바인드하면 OS에 투명합니다. 파일처럼 나타납니다.
FreeSoftwareServers

1
(1) 실제로 일부 Linux 버전 에서는 파일을 바인딩 마운트 할 수 있습니다 . (2) 바인드 마운트는 하드 링크와 매우 유사 해 보이지만 "바인드는 하드 링크와 동일합니다 (디렉토리를 하드 링크 할 수없는 경우 제외)"는 잘못되었습니다.
G-Man

@ G-남자는 BIND 언급 그냥 참고로, 동의 및 제거
FreeSoftwareServers을

실제로 @Free는 소프트 링크가 파일 이름을 가리 킵니다 (하드 링크 1). 회로도는 이것을 분명히해야합니다.
JB.

0

하드 링크는 첫 번째 파일 ( "파일 이름"은 기술적으로 하드 링크 임)까지 모든 하드 링크가 삭제 될 때까지 파일을 디스크에 보관합니다. 소프트 링크는 해당 파일이 교체 될 때까지 "중지"상태로 둘 수 있습니다.


0

이것은 매우 오래된 질문이지만 하드 링크를 사용해야하는 유스 케이스가 있습니다.

저는 음악가이므로 Mac에 연결된 여러 하드 드라이브에 다양한 종류의 오디오 파일이 많이 있습니다. 테라 바이트 가치. 나는 주로 symlink 디렉토리로 매우 잘 정리되어있어 콘텐츠 게시자, 스타일 / 사운드 및 당시의 생각에 따라 다른 기준으로 찾을 수 있습니다. 불행히도 내가 사용하는 한 프로그램 인 Ableton Live는 파일 브라우저에서 별칭 또는 심볼릭 링크를 완전히 볼 수 없습니다. 내가 찾은 유일한 해결책은 내가 볼 수있는 디렉토리의 하드 링크를 만드는 것입니다.

따라서 다른 사람에게는 발생하지 않은 하드 링크를 사용해야 할 경우가 있습니다.


Ableton Live에 대한 버그 보고서를 제출할 것입니다. 어쩌면 그들은 이것을 고칠 수 있습니다.
aventurin

예. 수년간 포럼 포럼에서이 문제에 대해 이미 많은 불만이 있습니다. 왜 그런지 알 수는 없지만 문제를 해결하려는 시도는없는 것 같습니다.
Jonathan van Clute
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.