아주 오래된 .swp 파일이 제가 편집하던 파일을 복원했기 때문에 지금은 훨씬 더 짧아졌습니다. 그 이후로 해당 디렉토리에서 아무 작업도 수행하지 않았으므로 파일 끝 바로 뒤의 바이트에는 여전히 내 데이터가 포함되어야 합니다. 주어진 메모리 주소에서 N 바이트를 읽으려면 어떤 기능을 사용할 수 있습니까? 어딘가에서 옵션을 놓친 것이 아니라면 파일 경계에서 중지됩니다 dd.read
현재 파일 크기는 3.2KB입니다. 잘리기 전 파일의 크기는 기억나지 않지만 아마도 10KB를 넘지 않았을 것입니다. 파일 경계를 무시하고 파일 시작 부분부터 10KB를 읽는 방법은 무엇입니까? 데이터가 완벽하게 저장되지 않아도 처음부터 다시 시작할 필요가 없는 한 문제가 되지 않습니다.
답변1
일반적으로 편집자는 파일을 저장할 때 삭제하거나 0으로 잘라 할당된 공간을 비운 다음 작성하여 새 공간을 할당합니다. 이로 인해 파일 시스템이 데이터를 완전히 다른 물리적 위치에 배치하게 됩니다. 그래서 당신의 아이디어가 작동하지 않을 수도 있습니다.
filefrag또는 를 사용하여 파일의 물리적 위치를 가져온 다음 를 hdparm --fibmap사용하여 dd해당 물리적 위치를 직접 읽을 수 있습니다. 여기서는 이 프로세스를 다른 맥락에서 설명합니다.https://unix.stackexchange.com/a/85880/30851
귀하의 경우에는 텍스트 데이터를 찾는 일반적인 방법이 필요할 가능성이 높습니다. 예를 들면 다음과 같습니다.
strings -n 12 -t d /dev/partition | grep -F 'text snippet'
strings인접한 ASCII 데이터를 찾고(일부 다른 인코딩도 지원되지만 UTF-8에 대해서는 확실하지 않습니다. 코드이거나 영어인 경우 필요하지 않음) 발견된 오프셋도 인쇄합니다.
text snippet찾고 있는 파일의 일부에 있었던 것으로 기억되는 정확하고 고유한 텍스트 예(한 줄)여야 합니다. (확실하지 않은 경우 정규식 grep을 대신 사용할 수 있습니다.)
-n 12strings찾을 최소 길이입니다. 12그것은 당신의 길이 여야합니다 text snippet. 이 매개변수는 선택사항이며 strings | grep제공되면 작업 속도를 높이는 데 도움이 될 수 있습니다.
전체 파티션을 읽는 데 시간이 오래 걸리지만 성공하면 dd일반 영역을 가져오고 속하지 않는 것을 삭제하기 위해 공급할 수 있는 오프셋을 얻게 됩니다.
그 이후로 나는 그 디렉토리에서 아무것도 하지 않았습니다
디렉토리가 마운트 지점이 아닌 경우... 대부분의 파일 시스템은 실제로 "디렉토리당" 공간을 예약하지 않으므로... 파일 시스템 전체의 모든 쓰기 작업이 사용자가 찾고 있는 비트를 덮어쓸 수 있습니다. 데이터 복구 상황에서는 일반적으로 전체를 읽기 전용 모드로 전환합니다.