Linux 및 Unix에서 lost + found 폴더의 목적은 무엇입니까?

644

Linux 및 Unix 운영 체제의 루트에는 /lost+found/

무엇입니까? 어떤 상황에서 상호 작용합니까? 어떻게 상호 작용할 수 있습니까?

filesystems directory-structure lost-found

— 웨슬리
소스

ext2 (및 ext3 및 ext4) 만을 사용 lost+found합니다. 숨기려면 다른 파일 시스템을 사용하거나 다른 곳에 마운트하고 모든 것을 하위 디렉토리에 보관하고 하위 디렉토리를 데이터를 사용하는 "실제"위치로 심볼릭 링크하십시오.

— Adam Katz

@Gilles 누군가 그것을 추가하기에 충분히 친절했습니다 : en.wikipedia.org/wiki/Fsck#Use

— David Kennedy

그 주 lost+found리눅스 확장 파일 시스템 (ext2-4)에 따라 다릅니다. UniBSD, 예를 들어 FreeBSD는 일반적으로 파일 시스템 (UFS, ZFS)에이 디렉토리가 없습니다.

— FUZxxl

죄송하지만 lost+foundBSD 시스템에서는 거의 영원히 사용되었습니다. 사실, 나는 방금 확인했고 4.3BSD에 분명히 있었고, 훨씬 더 일찍 기억하는 것 같습니다. 그리고 확실히 오늘날 FreeBSD에 있습니다.

— Bob Eager

@BobEager 감사합니다. 나도 그렇게 생각했지만 기꺼이 잘못 기억했을 것입니다…

— Pryftan

답변:

577

fsckfilesystem check and repair 명령 을 실행 하면 파일 시스템의 어느 곳에서도 참조되지 않은 데이터 조각을 찾을 수 있습니다. 특히 fsck완전한 파일처럼 보이지만 시스템에 이름 이없는 데이터 (해당 파일 이름이없는 inode) 가있을 수 있습니다. 이 데이터는 여전히 공간을 사용하고 있지만 일반적인 방법으로는 액세스 할 수 없습니다.

fsck파일 시스템을 복구 하라고 하면 거의 삭제 된 파일을 다시 파일로 바꿉니다. 문제는 파일 이름과 위치가 한 번이지만 해당 정보를 더 이상 사용할 수 없다는 것입니다. 따라서 ( 잃어버린 속성을 찾은 후 fsck)이라는 특정 디렉토리에 파일을 저장합니다 .lost+found

나타나는 파일 lost+found은 일반적으로 이미 연결이 해제되었거나 (이름이 지워진) 파일이지만 시스템이 갑자기 중지 된 경우 (커널 패닉 또는 정전) 일부 프로세스에 의해 여전히 열려 있으므로 (데이터가 아직 지워지지 않았습니다) 파일입니다. 이것이 전부라면 어쨌든 이러한 파일은 삭제 될 예정이므로 걱정하지 않아도됩니다.

파일 lost+found시스템이 소프트웨어 또는 하드웨어 버그로 인해 일관되지 않은 상태이기 때문에 파일이 나타날 수도 있습니다 . 이 경우 손실되었지만 파일 복구를 통해 복구 된 파일을 찾을 수 있습니다. 파일은 유용한 데이터를 포함하거나 포함하지 않을 수 있으며, 데이터가 불완전하거나 오래된 것일 수 있습니다. 그것은 모두 파일 시스템의 손상 정도에 달려 있습니다.

많은 파일 시스템에서 lost+found디렉토리는 fsck파일을 저장할 공간을 미리 할당하기 때문에 약간 특별 합니다. (공간은 파일 데이터를위한 공간이 아니며, fsck남겨야하는 디렉토리 항목을 위한 공간입니다 fsck.) 실수로를 삭제 한 경우에는를 사용 lost+found하여 다시 만들지 말고 mkdir사용 mklost+found가능한 경우 사용하십시오.

— 질
소스

또한 실수로 삭제 한 fsck는 다음에 파일 시스템이 깨끗할 때 (다음 부팅이 될 수 있음)이를 다시 만들 수 있습니다.

— derobert

이 폴더는 수시로 확인하고 정리해야합니까?

— TheLQ

@TheLQ 파일 시스템이 광범위한 손상을 입었을 때만 fsck필요했으며 파일 찾기 및 링크를 언급했습니다 lost+found. 다양한 파일 시스템을 사용한 20 년 동안 나는 이것을 한 번만 보았다. 그리고 그것은 저널링 이전의 표준이었습니다.

— Alexios

나는 당신이 당신의 HDD를 포맷하면 나타납니다 (NTFS에서 ext4로 전환하고 나타납니다)

— puk

@puk lost+found디렉토리는 시스템 설치의 일부로 수행되는지 여부에 관계없이 다른 많은 파일 시스템과 마찬가지로 ext4 파일 시스템을 작성할 때마다 작성됩니다. “HDD 포맷”은 그중 하나입니다. 어떤 fsck일은 아마도 거기에 파일을 추가하는 것입니다.

— Gilles

lost+found디렉토리 (+ 실측치 분실되지 않음)가 사용하는 구조 인 fsck파일 시스템 (아닌 하드웨어 장치 있지만에 FS)에 손상이있는 경우. 디렉토리 손상으로 인해 일반적으로 손실되는 파일은 해당 파일 시스템의 lost+found디렉토리에서 inode 번호 로 링크됩니다 . 이들 중 일부는 디렉토리 나 파일이 손실되거나 장치가 손실 될 수 있습니다. 각 파일 시스템에는 자체 lost+found디렉토리 가 있어야 하지만 파일 시스템이 하나 뿐인 시스템을보고있을 수도 있습니다. 일반적으로 디렉토리가 비어 있기를 바랍니다. 그러나 손상이있는 경우 여러 조건에서 파일을 fsck여기에 저장 한 후 복구 할 수 있다는 점에 감사 하십시오.

— 아 케지
소스

그러나 올바른 요점 :이 CAN은 어쨌든 상당히 귀찮은 일이되었습니다. 예를 들어, 관리자가 아닌 사용자 계정 find에서 하나 이상의 ext[2|3|4]파티션 에 대한 작업을 수행 하려고 할 때 항상 불필요한 "허가 거부" 오류가 발생합니다. 확실히, 이런 종류의 오류를 피할 수있는 방법이 있지만 표준 find . -name '*whatever*'이 트릭을 수행하지 않기 때문에 약간 어색 합니다.

— syntaxerror

@syntaxerror : find 의 성가심에 대해 다음과 같이 들었습니다 :`./lost+found ': Permission denied . 때때로 나에게도 버그가있다.

— Johan E

@syntaxerror 내가이 질문에 도착한 이유는 정확하게 찾기 작업을하고 있었고 찾기가 계속 Permission denied경고를 생성했기 때문 입니다. 이 질문에 대한 답이 주어지면 lost+found파일 시스템의 일부 라는 것을 알고 있으므로 생성 된 경고를 무시해도 안전합니다 (그러나 경고가 발생하지 않기를 바랍니다).

— Trevor Boyd Smith

@JohanE 당신은 저에게 말하고 있습니다. 그러나, 왜 실제 이유 나는 이 대답이 우리를 제안하려고했기 때문에 내 댓글을 게시했다 "감사" 를 위해 lost+found. 우리가 "Begone!" 을 던질 수있는 사람들과 경쟁 할 수없는 것에 대해 감사 할 때 엄청나게 몇 번이나이 말을하기에는 너무 재미 있었습니다 . 이 성가신 lo + fo 일을 철자하십시오.

— syntaxerror

"Linux 파일 시스템 계층"에서 섹션 / lost + found " :

FSSTND 개요에서 앞에서 설명한 것처럼 Linux는 항상 적절한 종료를 거쳐야합니다. 때때로 시스템이 중단되거나 정전으로 인해 시스템이 다운 될 수 있습니다. 다음 부팅시 fsck를 사용하여 긴 파일 시스템 검사가 수행됩니다. Fsck는 시스템을 통해 발견 된 손상된 파일을 복구하려고 시도합니다. 이 복구 작업의 결과는이 디렉토리에 배치됩니다. 복구 된 파일은 완전하지 않거나 많은 의미가 있지만 항상 가치있는 무언가가 복구 될 가능성이 있습니다. 각 파티션에는 고유 한 lost + found 디렉토리가 있습니다. 파일이 있으면 원래 위치로 다시 이동하십시오. 'file'에 대한 깨진 심볼릭 링크와 같은 것이 발견되면 해당 RPM에서 파일을 다시 설치해야합니다. 파일 시스템이 심하게 손상되어 파일이 인식 할 수 없을 정도로 잘려 나갔기 때문입니다. 아래는 / lost + found 디렉토리의 예입니다. 보시다시피 여기에 포함 된 대부분의 파일은 실제 팩트 소켓에 있습니다. 다른 파일의 경우 시스템 파일과 개인 파일이 손상된 것으로 밝혀졌습니다. 이 파일은 복구 할 수 없습니다.

— 부팔
소스