답변:
어디에도 없어졌다. 보다 구체적으로 말하면 파일이 연결 해제됩니다. 데이터는 여전히 디스크에 있지만 링크는 제거됩니다. 예전에는 데이터를 검색 할 수 있었지만 오늘날에는 메타 데이터가 지워지고 복구 할 수있는 것이 없습니다.
휴지통은 없습니다 rm. 휴지통이 필요하면 더 높은 수준의 인터페이스를 사용해야합니다. trash-cliUbuntu 에는 명령 줄 유틸리티가 있지만 Nautilus 또는 Dolphin과 같은 GUI 파일 관리자는 대부분 표준 휴지통을 제공하는 데 사용됩니다. 휴지통은 표준 자체입니다. 돌고래에서 휴지통에 버린 파일은 노틸러스 휴지통에 표시됩니다.
파일은 일반적으로 ~/.local/share/Trash/files/휴지통 과 같은 곳으로 이동합니다 . rmUNIX / Linux 의 명령은 파일을 del삭제하고 휴지통으로 이동 하지 않는 DOS / Windows 의 명령과 비슷합니다 . 또 다른 사실은 하드 디스크 드라이브에서 USB 디스크와 같은 파일 시스템을 통해 파일을 이동하는 것은 실제로 1) 파일 데이터의 사본과 2) 원본 파일의 연결 해제입니다. 휴지통에 이러한 추가 사본을 채우고 싶지 않을 것입니다.
libtrashrm의 행동을 바꾸는 것과 같은 것을 사용하는 것에 조심할 것 입니다. 많은 스크립트가 rm파일을 정리하는 데 사용 하며 휴지통에 표시되는 것을 원하지 않습니다. 내가 좋아하는 전용 명령을 사용하는 것이 좋습니다 trash로부터 trash-cli패키지로 제공된다. @pedro 필자는 홈 디렉토리에 * 파일을 한 번 추가했음을 추가해야합니다. 나는 그것을 만들지 말아야 할 때 실수로 인용했다 * 그래서 나는 rm과 함께 제거하기로 결정했다. 내가 한 일을 깨달았을 때 나는 명령을 빨리 죽 였지만 이미 내 홈 디렉토리에서 많은 파일을 삭제했습니다.
cp하고 mv,에 cp -i와 mv -i루트로 실행할 때. 기본 동작이 변경되어 기존 파일을 덮어 쓰기 전에 해당 명령이 항상 묻습니다. 일부 시스템 관리자는 이러한 별칭을 구체적으로 제거하여 기본 동작을 따르는 다른 시스템에서 치명적일 수있는 동작을 예상하지 않도록 권장했습니다.
ext3 / ext4의 경우 extundelete 또는 ext3grep 와 같은 도구를 사용하여 파일을 복구 하거나 심지어 저수준 구조를 수동으로 망칠 수도 있습니다 (심장 한 것이 아님). 많은 파일 시스템의 경우 특정 패턴으로 아직 덮어 쓰지 않은 블록을 검색 할 수 있습니다 (예 : magicrescue 는 무엇보다도 JPEG 헤더를 검색 할 수 있음). 이들은 휴리스틱을 사용하여 남겨진 메타 데이터에서 파일을 복구하므로 전체 복구가 보장되지는 않습니다. 최신 기회입니다. 일부 파일의 흔적이 저널에 남아 있어야하며 블록이 아직 덮어 쓰지 않았습니다).
따라서 모든 의도와 목적으로 제거 된 파일 rm은 사라졌습니다. 이 도구가 제공하는 것과 같은 괴사를 시도 할 수 는 있지만 의존하지는 마십시오. 다른 모든 것이 실패 할 때 시도하는 도구입니다. 최신 백업을보다 효율적으로 파헤칠 수 있습니다 (백업을하고 있었습니까?
효과를 취소에 관하여 rm:
대부분의 파일 시스템은 데이터에 대한 참조 만 제거하고 블록이 비어 있음을 나타내면 장치에서 직접 읽은 데이터를 찾을 수 있습니다. 운이 좋으면 파일을 포함하는 블록이 다른 것으로 주장되지 않았습니다.
이것은 당신이 찾고자하는 독특한 무언가가 있다고 가정 root하고, 시스템에 있고 파일 시스템이 관리하지 않으면 둘 이상의 파일 시스템 블록 (아마도 4k)에 걸쳐있는 것을 함께 연결하는 것으로 추측됩니다. 파일을 연속 블록에 넣습니다.
파일 시스템이있는 장치에서 문자열을 실행 grep하고 큰 컨텍스트 ( -C) 가있는 파일에서 무언가를 사용하여 몇 가지 일반 텍스트 파일의 내용을 성공적으로 복구했습니다 . (그리고 그 사건 직후, 회사는 백업 구현에 약간의 리소스를 사용하기로 결정했습니다)
magicrescue이미지 나 사운드를 독특한 패턴으로 찾으려고하는 도구가 있습니다 .
rm명령을 사용하여 파일을 삭제할 때마다 파일 데이터는 절대 삭제되지 않습니다. 다시 말해, 데이터를 포함하는 파일 시스템의 블록은 여전히 존재합니다.
rm명령 을 실행할 때 시스템은 해당 파일에 속하는 inode를 사용되지 않은 것으로 표시하고 해당 파일의 데이터 블록도 사용되지 않은 것으로 표시합니다 (지워지지는 않음). 그러나 ext3파일이 삭제 될 때 inode의 대부분의 필드는 0입니다.
이 사용하지 않는 정상적인 표시는 속도를 위해 수행됩니다. 그렇지 않으면 삭제하는 데 시간이 더 걸립니다. 그렇기 때문에 큰 파일을 삭제하는 것이 더 빠릅니다 (데이터 블록을 덮어 쓰지 않으면 데이터를 복구 할 수 있음).
추가 정보 : Inode 구조 , 파일 삭제 작동 방식
chattr +s( "shred") 속성이 표시되어 있지 않는 한 . 파일 시스템이 삭제시이 파일을 0으로 덮어 쓰도록 지시합니다. 일부 파일 시스템 만 해당 속성을 지원합니다.
유닉스 스타일 파일 시스템 (Linux 포함)에서 파일은 실제로 특정 위치에 있지 않습니다. 대신, 시스템은 하드 링크를 사용하여 많은 양의 데이터에 해당하는 부분을 가리 킵니다. 따라서 파일을 만들 때 파일을 "저장 한"위치에있는 첫 번째 하드 링크도 만듭니다. 더 많은 하드 링크를 만들면 시스템이 알고있는 한 파일이 실제로 여러 위치에 동시에 존재합니다.
파일을 "삭제"하면 일반적으로 실제로 지정한 위치에 존재하는 하드 링크 만 삭제합니다. 파일 삭제를위한 시스템 호출이 호출되는 이유 unlink()입니다. 시스템은 파일에 대한 하드 링크가 없을 때까지 실제로 파일을 삭제하지 않습니다. 그러나 마지막 하드 링크가 파괴되면 데이터도 파괴됩니다.
삭제 한 파일은 어디로 이동합니까? 여전히 하드 링크가있는 경우 파일은 삭제하지 않은 하드 링크 위치에 있습니다. 하드 링크가 남아 있지 않으면 파일이 사라집니다.