지정된 순서대로 다음 명령을 실행했습니다.
$ln a b
$ls -i a b
523669 a 523669 b
$rm -f a
$ls -i b
523669 b
나는 이 테스트를 통해 명령이 rm실제로 파일 이름( a이 테스트에서는)만 삭제하고 파일은 삭제하지 않는다는 결론을 내렸습니다. 왜냐하면 inode가 여전히 존재하고 다른 파일 이름( b)을 통해 검색할 수 있기 때문입니다.
내 질문은 파일이 파일 이름에만 하드 링크된 경우 rm해당 파일에서 실행될 때 실제 파일(즉, inode)이 완전히 삭제됩니까? 그렇지 않은 경우 파일 이름 없이 inode만으로 파일 inode를 검색할 수 있습니까?
답변1
inode를 통해 파일을 열려고 하면 모든 디렉터리 탐색이 우회됩니다. 파일의 권한과 파일을 가리키는 디렉터리를 결정하려면 디렉터리 순회가 필요합니다. 디렉터리 탐색이 없으면 커널은 호출 프로세스가 파일에 액세스할 수 있는지 여부를 확인할 수 없습니다.
하나 있다파일 설명자에서 파일 링크가 생성될 수 있도록 Linux 커널을 패치하는 것이 좋습니다.. 그것은이를 안전하게 구현하는 것이 매우 어렵기 때문에 거부되었습니다..
Linux에서는(그리고 아마도 같은 이유로 다른 UNIX 변형에서도) 삭제된 파일에 대한 링크를 만들 수 없으므로 파일에 더 이상 이름이 없으면 이름을 다시 추가할 수 없습니다. 1 삭제된 파일을 열어서 열 수 있습니다 /proc/$pid/fd/.
파일에 더 이상 링크가 없고 더 이상 열려 있지 않으면 해당 파일은 더 이상 존재하지 않으며 이전에 해당 데이터가 사용했던 공간을 언제든지 회수할 수 있습니다.
1 ext2/ext3/ext4를 사용하여 파일 시스템에 따라 파일 시스템에서 직접 바이트를 조정하면 됩니다 . debugfs이를 위해서는 파일 시스템이 마운트된 장치에 대한 액세스가 필요합니다(즉, 일반적으로 루트만 시도할 수 있습니다). 그러나 debugfs는 inode를 통해 파일에 액세스할 수 있지만 파일이 삭제되면 도움이 되지 않습니다. 응용 프로그램이 파일을 닫으면 파일이 실제로 삭제되며 마운트된 파일 시스템에서 읽기-쓰기 모드로 debugfs를 실행하는 것은 레시피 재앙.
답변2
"ln" 및 "rm" 명령은 1970년대 초 이후 모든 UNIX 파일 시스템에서 정확히 동일한 방식으로 작동했습니다. Mac OSX, BSD, Linux는 모두 이 독창적인 디자인을 계승했습니다.
UNIX 파일 자체에는 이름이 없으며 단지인덱스 노드숫자 또는 정수. 그러나 이름을 관련 inum과 연결하는 특수 "카탈로그" 파일의 항목을 통해서만 액세스할 수 있습니다. inum을 직접 지정할 수는 없습니다.
디렉토리는그 자체파일이므로 액세스도 해야 합니다.그것(다른) 디렉터리 등을 통해 슬래시(/)로 구분된 일련의 디렉터리 이름("경로 이름"이라고 함)을 통해. 경로는 이름이 "/"로 시작하지 않는 한 프로세스의 "현재 작업 디렉터리"에서 시작됩니다. 이 경우 경로는 파일 시스템 루트에서 시작됩니다. 예를 들어, 경로 이름에 "/" 문자가 포함되어 있지 않으면 현재 디렉터리의 항목이어야 합니다.
디렉토리가 아닌 파일은 "하드 링크"라고 불리는 경로 이름을 얼마든지 가질 수 있으며,모두해당 경로 이름이 제거되었습니다.그리고마지막 프로세스에서 파일을 닫았습니다. 그런 다음 파일은 실제로 삭제되고 해당 공간은 재사용 가능으로 표시됩니다. 즉, 단일 링크 파일을 creat() 또는 open()한 다음 unlink()하면 해당 파일이 더 이상 파일 시스템 네임스페이스에 표시되지 않지만 파일은 닫을 때까지 계속 존재하게 됩니다. 이는 다른 프로그램에서 읽을 수 없는 임시 스크래치 파일에 유용합니다.
디렉토리에는 inode 번호가 있지만 대부분의 파일 시스템에서는 해당 번호가 다른 디렉토리 내에만 나타날 수 있도록 허용하지 않습니다. (한 가지 특이한 예외는 Mac OSX HFS+ 파일 시스템입니다. 이를 통해 Time Machine 백업이 작동할 수 있습니다.) 디렉토리(또는 기타 파일)에 대한 "소프트 링크"를 계속 생성할 수 있습니다. 소프트 링크는 inum 대신 다른 경로 이름을 포함한다는 점을 제외하면 디렉토리 항목과 유사합니다.
모든 UNIX 파일에는 소유자, 그룹 및 액세스 권한이 있습니다. 파일을 열려면 필요하지만 충분하지는 않습니다. 또한 파일을 참조하는 데 사용되는 경로 이름의 모든 디렉터리에 대해 최소한 실행 권한이 있어야 합니다. 이것이 바로 UNIX 파일을 inode 번호로 여는 표준 방법이 없는 이유입니다. 이는 널리 사용되는 중요 보안 메커니즘을 우회하게 됩니다.
그러나 그것은 왜 표준적인 방법이 있을 수 없는지 설명하지 않습니다.뿌리(권한이 있는) 사용자는 어쨌든 권한 확인을 우회하므로 inode 번호로 파일을 엽니다. 이는 백업과 같은 특정 시스템 관리 기능에 유용합니다. 내가 아는 한, 그러한 메커니즘은 존재하지만 모두 파일 시스템에 따라 다릅니다. 모든 UNIX 파일 시스템에 대한 보편적인 접근 방식은 없습니다.
답변3
리눅스에서는,debugfs, 대화형 ext2/ext3/ext4 파일 시스템 디버거는 lninode 번호를 가져와 filespec해당 파일에 대한 새 하드 링크를 생성하는 명령을 제공합니다. 그러나 실제로 이를 위해서는연결 해제된 파일은 프로세스에 의해 열린 상태로 유지됩니다., 에서 열린 파일 설명자를 유지합니다 /proc/[pid]/fd/[n]. 삭제된 파일에 대해 이 작업을 수행하려고 하면 파일 시스템이 손상될 가능성이 높습니다.
이는 ext3(및 확장 ext4)가 충돌 후 연결 해제로부터 안전하게 복구할 수 있도록 보장하기 때문입니다.inode의 블록 포인터를 0으로 지웁니다.ext2는 블록을 블록 비트맵에서 사용되지 않은 것으로 표시하고 inode를 "삭제됨"으로 표시하며 블록 포인터를 유지합니다. 그럼에도 불구하고 하드 링크를 생성하려면 파일 시스템을 읽기-쓰기로 마운트해야 하므로 삭제된 파일용으로 예약된 블록이 재할당되었을 수 있습니다.
커널 버전 2.6.39 이전에는ln -L|--logicalGNU coreutils에 도입된 옵션v8.0열린 파일 설명자를 통해 연결되지 않은 파일을 복구하는 데 사용할 수 있습니다./proc/[pid]/fd/[n] 만약에연결되지 않은 파일과 새 하드 링크는 모두 다음 위치에 있습니다.임시 파일 시스템파일 시스템. 이 기능은 이후부터장애가 있는, 때문에, 때문에자일스파일 설명자에서 직접 하드 링크를 생성하도록 허용하는 것과 관련된 보안 고려 사항이 있다는 점을 지적하십시오.