Đọc phần cuối của tệp để khôi phục dữ liệu


12

Một tệp .swp rất cũ đã hoàn nguyên tệp mà tôi đang chỉnh sửa, vì vậy giờ đây nó ngắn hơn đáng kể. Tôi đã không làm bất cứ điều gì trong thư mục đó kể từ đó, vì vậy các byte ngay sau phần cuối của tệp vẫn có dữ liệu của tôi. Tôi có thể sử dụng chức năng nào để đọc N byte từ một địa chỉ bộ nhớ nhất định? ddreaddừng lại ở ranh giới tập tin, trừ khi tôi bỏ lỡ một tùy chọn ở đâu đó.

Kích thước tệp hiện tại là 3,2 KB. Tôi không nhớ chính xác tệp lớn như thế nào trước khi bị cắt, nhưng có lẽ không quá 10 KB. Làm cách nào tôi có thể đọc 10 KB từ đầu tệp, bỏ qua ranh giới tệp? Sẽ không sao nếu dữ liệu không được bảo quản hoàn hảo, miễn là tôi không phải bắt đầu lại từ đầu.

Câu trả lời:


18

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 filefraghoặc hdparm --fibmapsau đó 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 snippetphả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 12là độ dài tối thiểu stringssẽ tìm kiếm. 12nê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.


Lưu ý rằng mỗi tệp được lưu trữ trong nhiều khối và chúng thường không được lưu trữ liên tiếp. Vì vậy, stringssẽ 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.
Gilles 'SO- ngừng trở nên xấu xa'

3
Hoàn toàn ngược lại, bạn sẽ phải cực kỳ xui xẻo khi tìm thấy tệp 10KB bị phân mảnh. Nếu bạn chỉ tìm thấy một phần, nhiều khả năng phần kia đã bị ghi đè trong trường hợp này. Nhưng trừ khi bạn có nhiều hoạt động ghi trong hệ thống tệp đó, hoặc đó là ổ SSD bị loại bỏ ngay lập tức, nếu bạn đã lưu tệp đó nhiều lần trong khi chỉnh sửa, bạn có thể tìm thấy nhiều bản sao của tệp đó.
frostschutz

3
Tôi muốn giới thiệu strings -n16hoặc một số độ dài tối thiểu hợp lý, để làm cho nó đi nhanh hơn.
Peter Cordes

Điểm tốt, thêm nó vào câu trả lời.
frostschutz

4
Cảm ơn nhiều. Chỉ có rác vừa qua phần cuối của tệp, nhưng với stringstôi tôi đã có thể tìm thấy toàn bộ tệp ở nơi khác trong phân vùng. Đó là gần hai tháng làm việc tôi không phải làm, và một lời nhắc tuyệt vời là luôn sử dụng kiểm soát phiên bản cho bất kỳ điều gì quan trọng.
Matthew Bedford
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.