Thông thường khi các biên tập viên lưu tệp, họ xóa hoặc cắt thành 0, do đó giải phóng không gian được phân bổ, sau đó viết, phân bổ không gian mới. Điều này dẫn đến hệ thống tập tin đặt dữ liệu ở một vị trí vật lý hoàn toàn khác. Vì vậy, ý tưởng của bạn có thể không hoạt động.
Bạn có thể lấy vị trí thực của tệp bằng cách sử dụng filefrag
hoặc hdparm --fibmap
sau đó sử dụng dd
để đọc vị trí thực đó trực tiếp. Tôi đã mô tả quá trình này trong một bối cảnh khác ở đây: /unix//a/85880/30851
Trong trường hợp của bạn, nhiều khả năng bạn cần cách tiếp cận chung để tìm dữ liệu văn bản ... đại loại như:
strings -n 12 -t d /dev/partition | grep -F 'text snippet'
strings
sẽ tìm kiếm dữ liệu ASCII liên tiếp (cũng hỗ trợ một số mã hóa khác, không chắc chắn về UTF-8. Nếu đó là mã hoặc tiếng Anh, bạn sẽ không cần nó) và nó cũng sẽ in phần bù nơi tìm thấy.
text snippet
phải là một mẫu văn bản chính xác, duy nhất mà bạn nhớ nằm trong phần của tệp bạn đang tìm kiếm [trong một dòng]. (Nếu bạn không biết chính xác, thay vào đó bạn có thể grep với các biểu thức thông thường.)
-n 12
là độ dài tối thiểu strings
sẽ tìm kiếm. 12
nên là chiều dài của bạn text snippet
. Tham số này là tùy chọn, nếu được cung cấp, nó có thể giúp strings | grep
đi nhanh hơn một chút.
Sẽ mất nhiều thời gian để đọc toàn bộ phân vùng nhưng nếu thành công, bạn sẽ có một phần bù bạn có thể cung cấp dd
để lấy khu vực chung và sau đó xóa những thứ không thuộc về.
Tôi chưa làm gì trong thư mục đó kể từ đó
Nếu thư mục của bạn không phải là một điểm gắn kết ... hầu hết các hệ thống tệp không thực sự dự trữ không gian "trên mỗi thư mục", vì vậy ... bất kỳ và tất cả ghi trong toàn bộ hệ thống tệp có thể ghi đè lên bit bạn đang tìm kiếm. Trong tình huống phục hồi dữ liệu, bạn thường chuyển toàn bộ sang chế độ chỉ đọc.
strings
sẽ chỉ xác định vị trí một số phần của tệp trừ khi bạn cực kỳ may mắn.