41–48 of 48 posts
Make sure your output file is on a different filesystem! Otherwise, it might be saved in the newly-freed blocks of the file you're trying to recover.
Better yet, mount the hard drive read-only (on a different computer if necessary).
Earlier quoted context omitted.
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-...
Earlier quoted context omitted.
Because you told it to remove the file instead of moving the file? I don't see why we need a safe-rm on the command line. File managers already implement a trash function as per the freedesktop.org spec: http://www.ramendik.ru/docs/trashspec.html
> I don't see why we need a safe-rm on the command line. I think this is hilarious. :-) Throughout Unix/Linux/BSD history, there is a steady series of essays, lamentations, wails, and gnashings-of-teeth regarding the recovery, attempted recovery, or irretrievable loss of really important data that got somehow mistakenly rm'd by some admin. ...and, every single time , someone says, "Shouldn't this be made safer?", and…
Alternatively, just slow down a little bit before using rm, especially when operating as root. Understand that it's (intended to be) permanent. Use echo first when using rm with a splat in order to ensure you're actually deleting what you expect to delete.
The question, "Shouldn't this be made safer?" is irrelevant. At some level, you have to have an rm command. If users decide to use it regularly, then it's up to them to "Just be more careful!" The smarter thing would be to create a workflow that doesn't rely on using rm at all. Why whine and complain (not you, I mean users in general) about an operation that can be easily changed?
> 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"…
> 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.
My backups don't run on a minute-to-minute basis (dunno about yours), so it's totally plausible that I can spend all day working on a particular file and then mistakenly nuke it somehow, and it won't be retrievable by the most backup standards.
Earlier quoted context omitted.
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-...
I was looking forward to catting for llamas.
I've been using this method since i first learned about raw disk access (dev files) and grep. I think it should be mentioned that this will work properly only if the file was not fragmented - Which will usually be the case in EXT3 unless you are using almost all of the space in the drive, but may happen frequently if you are using a FAT file system (which is used a lot in USB disks). Also, If you just deleted a binar…
Earlier quoted context omitted.
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"…
Storage is cheap.... Why remove intermediate files at all? If you don't want to permanently remove files, then why use rm? Just create a "del" command that moves deleted files to a trash folder. You can then make part of your backup routine be to empty the trash after performing the backup (since that file would now be available in the backups).
Actually, that sounds like exactly the cognitive dissonance people had when they first started using Gmail. Perhaps filesystems need an "Archive" folder as well? Not even a Trash folder—because people want to empty a Trash folder—but rather just an enforced (and shell-supported) directory where things go when you don't have any reason to keep them, and therefore have no place to put them?