Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Recovering deleted files using grep

spin.atomicobject.com

Post reply on HN
Print view View original

21–30 of 48 posts

Re: Recovering deleted files using grep

#21

Post by 16s »

moobot wrote: post #19
naturalized wrote: post #14

Or, if you want to really delete a file, use #shred filename command #man shred SHRED(1) User Commands SHRED(1) NAME shred - overwrite a file to hide its contents, and optionally delete it I especially like the -n option!

Except that shred is not guaranteed to work on many (most?) modern filesystems. From `man shred`: CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to b…

It works fine on default EXT3. The only thing journaled is meta-data. You snipped that part out. More from man shred

In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata.

In both the data=ordered (default) and data=writeback modes, shred works as usual.

Re: Recovering deleted files using grep

#22

Post by ramidarigaz »

someone_here wrote: post #13
ramidarigaz wrote: post #11

Earlier quoted context omitted.

Hmm... I'm getting an error on that one. cat: /dev/mem: Operation not permitted Edit: even as root

If I recall correctly, that's a bug that is preset on a particular kernel from 6-9 months ago.

Huh. Good to know.

Re: Recovering deleted files using grep

#23

Post by miles »

someone_here wrote: post #13
ramidarigaz wrote: post #11

Earlier quoted context omitted.

Hmm... I'm getting an error on that one. cat: /dev/mem: Operation not permitted Edit: even as root

If I recall correctly, that's a bug that is preset on a particular kernel from 6-9 months ago.

It's not a bug:

x86: introduce /dev/mem restrictions with a config option http://lwn.net/Articles/267427/ "This patch introduces a restriction on /dev/mem: Only non-memory can be read or written unless the newly introduced config option is set."

Command-line access to /dev/mem in Ubuntu http://superuser.com/questions/39583/command-line-access-to-...

Re: Recovering deleted files using grep

#26

Post by telemachos »

koevet wrote: post #24

Actually, I think that the real great hack here is to alias the rm command to a trashbin script (as suggested at the end of the article)

The danger of aliasing the command itself (the bare 'rm') is that you come to count on the safety of the alias. Then you work one day on a friend's or coworker's machine and...BOOM.

What I do instead is make a nearby (and simple) alias. For example:

    rmi='rm -i'

Re: Recovering deleted files using grep

#27

Post by derefr »

cryptoz wrote: post #12

> To help prevent this problem from happening in the first place, many people elect to alias the rm command to a script which will move files to a temporary location, like a trash bin, instead of actually deleting them. Whatever happened to backups? To help prevent this problem... KEEP A BACKUP.

The kinds of files I most often regret rm-ing are the temporary files I have created myself as a step in a process, then deleted after I had moved onto the next step, not realizing an error had crept into the processor and that I would have to run it again on the source files (which are now, conveniently, gone.) Backups don't solve this problem, because the files themselves are never more than an hour old. A "trash" folder, however, fixes this perfectly: the semantic is that the file no longer has any place it "belongs," and may be purged if you successfully complete the project, but may be needed again if the project must be "rewound" to that step.

However, you're right that making rm(1) express move semantics isn't the right solution. Maybe if the filesystem had a "BEGIN TRANSACTION" command that you could ROLLBACK...

Re: Recovering deleted files using grep

#28

Post by csummers »

Been there, done that. I rm -rf'd a bunch of important files once, and at the time grep was giving me "memory exhausted" errors. I was able to use strings to grab all of the text of the disk, and then wade through the results with vim.

I guess this is a pretty common problem. The blog post I wrote about it in 2005 continues to be the most searched-for entry point on my site: http://csummers.com/2005/12/20/undelete-text-files-on-linux-...

Re: Recovering deleted files using grep

#30

Post by kentnl »

albertzeyer wrote: post #17

Via `reiserfsck --rebuild-tree`, you can also do that for ReiserFS partitions. Have worked very reliable for me. Only problem is that it doesn't always recover the filename and/or the directory structure (depending on how long it is ago that you have deleted it).

Just don't do this if you've at some stage backed up another reiserfs filesystem inside your reiserfs filesystem with 'dd'.

the rebuild tree trick mistakenly sees entries in the dd'd copy as being files in the parent file system, and then sprays them all over your drive.

Post reply on HN