컴퓨팅(computing)에서, 하드 링크(hard link)는 이름을 파일과 결합하는 (디렉토리-기반 파일 시스템에서) 디렉토리 엔트리입니다. 따라서, 각 파일은 적어도 하나의 하드 링크를 가져야 합니다. 파일에 대해 추가 하드 링크를 생성하는 것은 추가 경로를 통해 (예를 들어, 다른 이름을 통해 또는 다른 디렉토리에서) 해당 파일의 내용에 접근-가능하도록 만듭니다. 이것은 별칭 효과의 원인이 됩니다: 프로세스는 그것의 경로 중 임의의 하나로 파일을 열고 그것의 내용을 변경할 수 있습니다. 대조적으로, 파일에 대한 소프트 링크 또는 "바로 가기(shortcut)"는 데이터 자체에 대한 직접 링크가 아니라, 하드 링크 또는 또 다른 소프트 링크에 대한 참조입니다.
모든 각 디렉토리는 그 자체로 특별한 파일이며, 오직 그것은 파일 이름의 목록을 포함합니다. 따라서, 디렉토리에 대한 다중 하드 링크가 가능하며, 트리와 같은 가지를-뻗는 구조가 아닌, 순환 디렉토리 구조를 생성할 수 있습니다. 이러한 이유로, 일부 파일 시스템은 디렉토리에 대한 하드 링크의 생성을 금지합니다.
Linux, Android, macOS, 및 윈도우 NT 제품군과 같은 POSIX-호환 운영 시스템은 파일 시스템에 따라 같은 파일에 대한 다중 하드 링크를 지원합니다. 예를 들어, NTFS는 하드 링크를 지원하지만, FAT와 ReFS는 그렇지 않습니다.
Operation
"LINK A.TXT"와 "LINK B.TXT"라는 두 개의 하드 링크가 같은 물리적 데이터를 가리킨다고 놓습니다. 텍스트 편집기는 "LINK A.TXT"를 열고 수정하고 저장합니다. 편집기 (또는 임의의 다른 프로그램)가 "LINK B.TXT"를 열 때, "LINK A.TXT"에 만들어진 변경 사항을 볼 수 있는데, 왜냐하면 두 파일 이름은 같은 데이터를 가리키고 있기 때문입니다.
일부 편집자, 예를 들어, emacs는 어쨌든 하드 링크 개념을 깨뜨립니다. 편집을 위해 파일, 예를 들어 "LINK B.TXT"를 열 때, emacs는 "LINK B.TXT"를 "LINK B.TXT~"로 이름을 바꾸고, "LINK B.TXT~"를 편집기에 로드하고, 수정된 내용을 새로 생성된 "LINK B.TXT"에 저장합니다. 이제, "LINK A.TXT"와 "LINK B.TXT"는 더 이상 같은 데이터를 공유하지 않습니다. (이 행위는 emacs 변수 backup-by-copying을 사용하여 변경될 수 있습니다.)
물리적 데이터에 대한 하드 링크는 원하는 수만큼 생성될 수 있습니다. 데이터에 접근하기 위해, 사용자는 오직 임의의 기존 링크의 이름을 지정하면 됩니다; 운영 시스템은 실제 데이터의 위치를 확인할 것입니다. 심지어 사용자가 하드 링크 중 하나를 삭제하더라도, 그 데이터는 남아 있는 임의의 다른 링크를 통해 여전히 접근될 수 있습니다. 사용자가 모든 링크를 삭제하면, 파일이 열려 있는 프로세스가 파일 열기를 가지지 않으면, 운영 시스템은 파일이 한 번 차지했던 디스크 공간을 비웁니다.
Reference counting
하드 링크를 지원하는 대부분의 파일 시스템은 참조 카운팅을 사용합니다. 시스템은 데이터를 가리키기 위해 생성되어 온 총 하드 링크의 개수를 나타내는 각 논리적 데이터 섹션과 함께 정수 값을 저장합니다. 새 링크가 생성될 때, 이 값이 1씩 증가됩니다. 링크가 제거될 때, 그 값은 1씩 감소됩니다. 카운터가 0이 될 때, 운영 시스템은 논리적 데이터 섹션을 해제합니다. (OS는 예를 들어 성능상의 이유로 미해결 파일 핸들이 열려 있을 때 또는 삭제-취소 명령을 활성화하기 위해 즉시 그렇게 하지 않을 수 있습니다.
이것은 영 값이 여유 공간을 나타내고 비-영 값은 사용된 공간을 나타내기 때문에 파일 시스템에 대해 주어진 저장소의 영역의 사용을 추적하기 위한 간단한 방법입니다. 이 값의 유지는 아무 데도 가리키는 않는 댕글링 하드 링크가 없음을 보장합니다. 데이터 섹션과 결합된 inode는 단일 하드 링크 (디렉토리 참조)가 그것을 가리키거나 임의의 프로세스가 결합된 파일을 열린 상태로 유지하는 한 보존됩니다.
POSIX-호환 운영 시스템에서, 파일 또는 디렉토리에 대한 참조 개수는 struct stat의 st_nlink 필드에서 stat() 또는 fstat() 시스템 호출에 의해 반환됩니다.
Limitations
파일 시스템에서 루프를 방지하고, ".." 파일 (부모 디렉토리)의 해석을 일관되게 유지하기 위해, 운영 시스템은 디렉토리에 대한 하드 링크를 허용하지 않습니다. UNIX System V는 그것들을 허용했지만, 오직 수퍼유저가 그러한 링크를 만들기 위한 권한을 가졌습니다. Mac OS X v10.5 (Leopard)와 그 후속 버전은 오직 Time Machine 백업 메커니즘에 대해 디렉토리에 대한 하드 링크를 사용합니다.
하드 링크는 같은 볼륨, 즉 같은 파일 시스템 내에서만 파일에 대해 생성될 수 있습니다. (다른 볼륨은 다른 파일 시스템을 가질 수 있습니다. 대상 볼륨의 파일 시스템이 하드 링크와 호환된다는 보장은 없습니다.)
단일 파일에 대한 최대 하드 링크 수는 참조 카운터의 크기로 제한됩니다. 유닉스-계열 시스템에서, 그 카운터는 4,294,967,295 (32비트 시스템) 또는 18,446,744,073,709,551,615 (64비트 시스템)입니다. 일부 파일 시스템에서, 하드 링크 수는 그것들 디스크 형식에 따라 더 엄격하게 제한됩니다. 예를 들어, 리눅스 3.11에서, ext4 파일 시스템은 파일에 대한 하드 링크 수를 65,000개로 제한합니다. Windows 제한은 NTFS 볼륨의 파일에 대한 1024개의 하드 링크 제한을 강제합니다.
Linux Weekly News에서, Neil Brown은 하드 링크가 아카이버와 디스크 사용 도구를 포함하여 디렉토리 트리를 처리하는 프로그램의 설계를 복잡하게 만들기 때문에 유지 관리가 많이 필요하다고 비판했습니다. 이들 프로그램은 계층 구조에서 여러 번 연결된 파일의 중복을 제거하도록 주의해야 합니다. Brown은 유닉스의 후속 제품, Bell Labs의 Plan 9은 하드 링크 개념을 포함하고 있지 않다고 말합니다.
Platform support
Windows NT 3.1 이상은 NTFS 파일 시스템에서 하드 링크를 지원합니다. Windows 2000은 하드 링크를 생성하기 위해 CreateHardLink() 함수를 도입했지만, 디렉토리가 아닌 파일에만 적용됩니다. DeleteFile() 함수는 그것들을 제거할 수 있습니다.
Windows에서 하드 링크를 생성하기 위해, 최종 사용자는 다음을 사용할 수 있습니다:
- fsutil 유틸리티 (Windows 2000에서 도입됨)
- 윈도우 명령 프롬프트의 mklink 내부 명령 (Windows Vista와 Windows Server 2008에서 도입됨)
- PowerShell의 New-Item cmdlet
하드 링크에 대해 파일을 조사하기 위해, 최종 사용자는 다음을 사용할 수 있습니다:
- fsutil utility
- Powershell의 Get-Item와 Get-ChildItem cmdlets. 이들 cmdlets는 대상을 갖는 각 파일을 나타냅니다; PowerShell은 그것들의 각각에 읽기-전용 LinkType 속성을 추가합니다. 결합된 파일에 여러 하드 링크가 있으면 이 속성은 "HardLink" 문자열을 포함합니다.
윈도우 구성 요소 저장소는 하드 링크를 하드 디스크 드라이브에 저장된 구성 요소의 다양한 버전을 추적하기 위해 사용합니다.
유닉스-계열 시스템에서, link() 시스템 호출은 기존 파일에 대한 추가 하드 링크를 생성할 수 있습니다. 하드 링크를 생성하기 위해, 최종 사용자는 다음을 사용할 수 있습니다:
하드 링크에 대한 파일을 조사하기 위해, 최종 사용자는 다음을 사용할 수 있습니다:
Cygwin과 유닉스-기반 응용 프로그램에 대한 하위시스템과 같이 Microsoft Windows에서 실행되는 유닉스-계열 에뮬레이션 또는 호환성 소프트웨어는 POSIX 인터페이스의 사용을 허용합니다.
OpenVMS는 ODS-5 파일 시스템에서 하드 링크를 지원합니다. 유닉스와 달리, VMS는 디렉터리에 대한 하드 링크를 만들 수 있습니다.