파일의 원래 위치를 확인하는 방법은 무엇입니까?

아니요, 거기는 아닙니다. 무슨 일이 일어나는지 추적하기 위해 또는 유사한 것을 설정할 수 있지만 auditd 이는 명령 전에 설정해야 합니다.

한 가지 가능한 해결책은 셸 기록을 보고 파일이 이동된 위치/방법을 확인하고 거기에서 원래 위치를 확인하는 것입니다. 그러나 이는 대체로 신뢰할 수 없습니다.

이 명령을 사용한 후에 위치를 확인할 기회가 있습니까?

예, 운이 좋다면 가능합니다(아마도 수작업이 많을 것입니다).

테스트 디스크할 수 있는 도구이다파일 삭제 취소.

링크된 페이지에는 삭제된 파일을 복구하는 방법이 나와 있지만, 디렉터리에서 단순히 제거(일명 삭제?)되는 것이 아니라 파일이 디렉터리 밖으로 이동되어도 프로세스가 작동하는 것 같습니다. 파일이 동일한 파티션 내의 디렉터리로 이동되었거나 다른 파일 시스템(ext4에서 NTFS로)을 사용하는 다른 파티션의 디렉터리로 이동되었는지 여부에 관계없이 이동된 파일을 성공적으로 복구하려고 시도했습니다.

이 도구를 사용하면 파일 시스템을 탐색하고 삭제/이동된 파일을 빨간색으로 표시할 수 있습니다. 따라서 이동된 파일을 찾으면 해당 파일이 어디서 이동되었는지 알 수 있습니다. 의심되는 몇 개의 위치로 검색 범위를 좁힐 수 없거나 testdisk가 자동으로 이 작업을 수행하도록 하는 방법을 찾지 않는 한(댓글에서 언급한 것처럼 삭제된 파일이 모두 문서라고 가정) 그렇지 않으면 수작업이 많다.

또 다른 해결 방법은 문서가 이전 위치에 있을 때 해당 문서를 읽거나 수정하는 데 사용한 소프트웨어 도구의 캐시를 확인하는 것입니다. 일부 응용 프로그램은 "최근 파일" 메뉴를 구현하기 위해 이러한 문서에 대한 링크를 유지할 수 있습니다.

나는 Ulrich의 의견에 동의합니다. 이것은 종종 기본적으로 불가능합니다. 하지만

• 이는 사용 중인 Linux 버전과 파일이 있는 파일 시스템 유형에 따라 달라질 수 있습니다. 나는 이것들에 대해 잘 알지 못하지만 다음과 같습니다.저널 파일 시스템좋다외부 3그리고외부 4 변경 사항에 대한 감사 추적과 같은 것이 유지될 수 있습니다. 이들 중 하나를 리버스 엔지니어링하여 파일 시스템 변경 사항을 롤백하는 데 필요한 것이 무엇인지 확인하고 파일의 출처를 확인할 수 있습니다. 아니면 아닐 수도 있습니다. 그게 가능한지는 모르겠습니다.

  참고: 가능하다면 새로운 변경 사항이 역추적하려는 이동 로그를 덮어쓰지 않도록 가능한 한 빨리 파일 시스템 사용을 중지하는 것이 좋습니다.

• "명백한" 대답은 이동하기 전에 충분한 최근 백업이 있는 경우 이를 확인하여 파일이 어디에 있는지 확인할 수 있다는 것입니다.