Undelete In Linux
Manuel Arriaga writes "[To the editors: I am not a professional programmer, nor will I ever be one. My income does not depend on my computing/programming skills, and hopefully it never will. So promoting free software I wrote does not help me in any financial way, no matter how indirect. libtrash is free software (GPL2), and I distribute it for free from my website. I have nothing to gain from the increased exposure, except for knowing that I am helping others. And I know slashdot isn't freshmeat... With that out of the way:]
I have seen this topic discussed in the LKML multiple times by now, and many more people asking in the newsgroups why "I can't recover my deleted file on GNU/Linux".
Here is my answer to that question. libtrash gives Linux a real "trash can". And it has been doing so (with varying degrees of stability) for more than one year now.
If you consider it appropriate, make this information public on slashdot."
http://ask.slashdot.org/article.pl?sid=02/09/29/02 7256 for a similar discussion.
PDHoss
======================================
Writers get in shape by pumping irony.
I can't believe how many Windows users get caught out when they dual boot my machine into Windows (have to have it for the office because others use my workstation) and find I have disabled the Recycle bin. Haha, more fool them.
Disclaimer: take with a pinch of salt. If you have sodium issues, take with a pinch of Lo-Salt instead.
Conversion Rate Optimisation French / English consultant
now we have almost everything we need:
[x] Trashcan support
[ ] Easy to use Windowing system
[ ] Standard software install system
[ ] Easy to use Windows filesharing
[ ] Easy support for video files and DVD
[ ] Desktop company support
Way to go LINUX!
Come on, recycle bins are no fun at all. Where's the fun in having the files you "delete" stored in a folder until you REALLY want to delete them. It's much more fun to delete files knowing that there's a chance you may need them in the future and have no way of retrieving them (unless you're responsible and back your files up, but then again, what's fun about being responsible?).
"Herbivores eat well cause their food never, ever runs."
I don't understand why there are so many people saying this is bad or implying that people who use Linux don't need it because they are so good. I must have missed the evolutionary step that made all Linux users so perfect that they never make mistakes. That is all the Recycle Bin is.
Sure, some people use it as temporary folder, but so what? There will always be people who use things other then the way they are intended. If it works for them, so what? If it is so painful for you to contemplate, don't look at it.
[x] Trashcan support
[X] Easy to use Windowing system - KDE
[X] Standard software install system - LSB, Red Hat, Mandrake, Suse
[X] Easy to use Windows filesharing - KDE, Samba
[ ] Easy support for video files and DVD - No answer
[X] Desktop company support - Red Hat, The Kompany
Way back when Apple sued Microsoft for ripping off the look of their interface, Apple lost. The ONLY thing they got the judge to concede was the Trash Can was theirs. Thus, MS changed to a recycle bin -- a sideswipe at the Apple-California neo-environmental stereotype.
The editorial cartoons of the time were great. One showed a picture of Jobs carrying a trashcan full of legal documents with someone commenting "At least the judge let you keep something to carry all that home in."
Learning HOW to think is more important than learning WHAT to think.
Why is there no README or any other info on your site about this thing? I want to know how it works and how it is different from alias rm='mv ~/.trash', or the KDE trashcan, before I download it. Man I hate sites like this that expect you do download the package, then untar it, just to read a README file. How hard is it to throw it on your website with a link?
While a trash can is nice to have, this doesn't fundementally address the issue of retrivability of accidently deleted information. That is, there is still going to be a step where information is going to be classed as unretrivable even when it COULD be retrieved. (i.e. when the trash is emptied)
Clearly users appear to want to be able to correct mistakes that they've made -- perhaps even those that were not immediately apparent as being mistakes at the time -- for as long as possible. A trash is a step in that direction, but simply does not go far enough.
My proposal is this: 1st it should be recognized that when you delete a file, you're really only marking the space where that file was as being available to be overwritten by more data. The original data is there, but what it consisted of, and where it was, are lost.
So, let's keep that information in a log so that we can in a very real sense undelete anything that has not yet been overwritten. This log is not especially large, and with modern drive sizes is not a serious concern.
Then, let's order the overwriting process to favor the maximum preservation of data. So for example this might result in new writes being done to the areas of the oldest deleted files first. Important files might be considered to be worth preserving longer, with importance dervived from various factors such as number of accesses, etc. prior to deletion. There's definately work for some user testing here to determine the optimal method. That's okay.
If fragmentation is a worry, (bear in mind most people have never heard of it) then defragging software could take into consideration the undelete log and continue to preserve as much of the deleted data as possible when it shifts information around on the disk.
In any event, the objective is to forestall the day when you have to tell a user who wants to undelete a file for as long as possible. Not longer, which the trash solution does, but AS LONG AS POSSIBLE.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
So, what happens if you send something like ld.so, or your kernel into the recycling bin? Experimenting by randomly moving stuff you don't understand is never a good idea. Just sending it to some sort of recycling bin just gives folks a false sense of security and could lead them to completely hosing their entire install.
mkdir ~/trash /bin/rm -rf /home/*/trash" >> /etc/crontab
/me nods
alias rm="del"
echo "* 4 * 1 *
del:
#!/bin/sh
mv $* ~/trash
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
So you must never wear a seat belt either because you've never been in a fatal car accident.
Moron.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
Don't delete anything, till it has been backed up. You do back up your data, right?
I've been a rabid Linux user from the early days. Today Linux handles DNS, Email, and Web services on my networks...it does NOT handle file access for JUST THIS REASON (lack of undelete).
.XLS file). Excel says it's corrupt (it's a Word document now).
I'm not worried about *me*. When I delete something I fine with it being completely gone. What about completely clueless network users though? Being the MIS/IT MGR for where I work having access to "salvage" on the Novell Netware file servers is a wonderful tool for users mistakes.
Classic example: last week one user created a Excel spreadsheet to be completed by another user. The second user opened the spreadsheet from Word, modified it, and saved it (as a
Getting the inserted table [spreadsheet] from Word back into Excel was next to impossible. Crappy Microsoft programming as usual -- and clueless users to boot. Easiet solution was to salvage the original spreadsheet and instruct user what NOT to do and re-enter the damn data PROPERLY this time.
Linux would have left me high and dry. Well, not really, but having to go back to tape backups to simply salvage one file is a pain in the butt.
I guess Linux will be nothing more than a niche product/market if "gurus" keep their attitudes posted here. Wake up and pay attention to corporate users and admins wants/needs. Telling me I'm clueless and wrong won't gain more market share (well, for Linux at least) -- I've recently bought another Netware license to cover just this issue for another remote office.
Once upon a time I wanted to delete a couple stray mp3s I had in my home directory, so I issued the following command:
.mp3
rm *.mp3
Or so I thought. I had actually accidently told my linux install to do the following in my ~/
rm *
If you cannot tell, there is a " " between "*" and "." As you can imagine this has a very undesired effect, even though I saw it quickly after hitting enter and mashed the ^C as fast as I could.
Undelete would have been useful then. Yes, its a dumb mistake.. but things happen!
Scott.
I think that you are on to the right solution.
Perhaps the thing to do would be to use two file tables. The first table would be used normally as it is today. It would represent existing files and provide the correct information regarding space usage etc.
The second table would only be used by the file system and the recovery utilty. The second file table would maintain the information of the files that had been marked for deletion and the file system would consult this table prior to saves so as not to overwrite the files that were marked for deletion.
When the disk becomes full, the file system should consult the second file table and overwrite the oldest file that had been marked for deletion.
Also, the recovery utility could consult the second table, listing the files that were marked for deletion but, still reside on the disk. Files selected for recovery could then be added back to the first, primary file table making them again available for the user.
I'm not sure how Novell does it but, the above method would yield the same behavior as the Novell system.
I know in my heart that there's no need for this on Unix, because you shouldn't run as root AND use rm -rf and THE decide that you shouldn't have done that. There are safeguards in place and, after all, since you're a Linux superuser, you're either good enough that you don't make that kind of mistake or the system isn't important enough for it to really matter.
/bin`. Funny story, though:
/big. That was the first mistake. I have no idea why I felt the need to mount it that close to the root. Although the similarity between "big" and "bin" is obvious in retrospect, it is, after all, retrospect.
/big` and immediately pressed return (I found that return is also a mysterious part of that autocompletion).
/bin. Among them, all of the shells, chmod/chown, grep, kill, ls (try working without that), mv.... the list goes on and on.
Having said that, even though I know how dumb it was, I once accidentally issued `rm -rf
For some reason or another, I happened into an additional hard disk that I put into my Linux box at work (not a production box). I don't remember how big it was, but it was big enough relative to my primary disk that, when I needed a mount point, I chose
Actually, that wasn't my first mistake. My first mistake was running as root.
I mounted the disk and played around with it. I suspect that it was my first time playing around with an additional hard disk, so I copied files over and examined "df -k" and so forth, and eventually I guess I decided to unmount it and do it all over again... I probably would have done endless, mindless file copies for the rest of the day, I was so thrilled with it. Hey, I was young.
This is where it gets embarassing. Perhaps everybody has some mysterious glitch which adds confusion where there should be none. Yes, I honestly do know the difference between a symlink and a mount... I swear it. But in the very brief period of time that it takes to type a command, I sometimes confuse the two in my mind and try to unmount using the "rm" command. More specifically, "rm -rf".
I also noticed on that day that we humans have kind of a built-in autocompletion. If you type the first few letters of your last name, you have a tendency to follow through with the rest of it. And that tendency increases dramatically the closer you get to the last letter. The way I noticed this was when I attempted to issue `rm -rf
Just so you know, there are a great many important things in
This story also reminds me of the time I evaluated WS_FTP Server when it first came out. I needed an FTP server so I could go home and work on some files on an NT server. I wanted access to the whole box, so I set up my FTP account's home directory as c:\ -- I had no idea that when I deleted that account it would attempt to delete the user's home directory, even if it was c:\.
I've never heard a disk thrash like that before or since. And you've never seen anybody turn a box off as quickly as I did when I realized what was going on. Alas, it was too late. Reinstallation and backup restore (yes, I had a backup) commenced immediately. By the way, I've never fully accepted responsibility for that -- I still feel like it should have said "You're about to delete c:\ and all of it's subdirectories. Are you sure?" Because I really didn't think it would do that.
Anyway, my point is that "there, but for the grace of a godlike substance, go you". It's really easy to say we're too good for this, and there's a damn good case that a linux trashcan is not necessary, but for those who want it I think it's a cool piece of code.
That is all.
RP
After losing eight hours of editing work during a botched backup attempt, I heard about a utility called safedelete. I can't find much on it, but here it is from Ibiblio. Interestingly, the person that told me about this utility (which sets up a trash directory with timed expiration and a system of aliases for rm and related commands) was an old Unix hand, and only secondarily a Linux user. The program works fine in Debian, I can report.
And I don't get these people saying they are too smart to need an undelete capability. Must be nice!
*** "Freiheit ist immer die Freiheit des Andersdenkenden". -- Rosa Luxemburg ***
Is it that hard?
And this my friends is the attitude keeping Linux from wider acceptance......
Technically, you can use a pint mug to drink champagne. But most people prefer to use a champagne glass or a flute.
;-)
Personally, I prefer to simply hit "delete" to move files to a preset temporary directory (which can also remember where those files originally were, and restore them with a couple of clicks) than to have to manually drag them to a directory I created.
If this kind of "commodity" seems pointless to you, then you probably program by writing machine code with a text editor.
RMN
~~~
>> tell the world why linux needs an undelete
Because the world does not consist of perfect people. Most people will f*ck up from time to time and hose something that they didn't want. While I won't be installing this on any of my systems I'm sure that some of the more consumer-oriented distros might want to add this type of functionality to their products.
That being said, I could see how something like this could be beneficial to many people, so having it as an option is a Good Thing. No one is forced to use it, but it's there for those who do.
I have the solution! and it can be a HUGE moneymaker.
i prepose the e-landfill. an online service that you can configure your trashcan to use a daemon process (garbagemand) that automatically ships the contents of the trashcan via a secure protocol (rubbishtruck/garbagetruck.. as known as RT/GT) to the e-landfill.. there the deleted file can pile up forever or at least until it is full then we just open up another landfill!
Great idea!
Do not look at laser with remaining good eye.
From the FAQ:
"Take this object, but beware! It carries a terrible curse!"
The advantage is has over some recovery options is that it's entirely post-mortem. If you just deleted the boss's laundry-list, you could go download it, build it, and stand a pretty decent chance of recovering your file.
The disadvantage is that, perhaps like a real autopsy, it's not for the faint of heart...
I think underlete should be handled at the application level, ie. in konqueror and nautilus, etc. Maybe alias rm to something else for the command line.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
This appears to work by placing itself ahead of the normal libc when it comes to dynamic library loading. Very neat idea, but it won't work on libraries which don't delete files by making calls to the shared library. The most common instance of this will probably be statically linked binaries. On FreeBSD, almost all of /bin (including rm) is statically linked, and it wouldn't surprise me if this was true on a Linux distro or two.
So be wary of just installing this and playing with rm - you might give yourself a nasty surprise :) You can check whether rm is statically linked by running ldd `which rm`
Actually, I've found it's the other way around. If average users know that every mistake is fatal, they become afraid of making ANY mistakes, and that's when you discover a HD completely filled up with garbage that they didn't dare dispose of.
~REZ~ #43301. Who'd fake being me anyway?
:>\-i yes it looks like line noise or an emoticon, but it's really a shell script. This protects against rm *.
/etc, /bin), and type :>\-i
so cd to all of your really important directories (/,
what it does is create an empty file named -i
when the shell expands * the first file it lists is -i, which rm interprets as an option for interactive mode, so you have to confirm each deletion.
I am thoe original author of this shell script, consider it GPLd.
This isn't an issue of "lighting fast". The proposed solution, at least without serious modification, would massively fragment the hard drive. The only reason you don't *care* about fragmentation is because you enjoy the pleasant fruits of the fragmentation-resistant ext2, so you don't realize how bad fragmentation can get. The proposed system would fragment the filesystem so badly that a well-used FAT32 system would look contiguous as hell.
You could make a usable system that's somewhat similar...it could shift files around and use, say, a third of the free space for old files.
May we never see th
It shouldn't be all that hard to do this in-kernel, so it doesn't have library-preload dependencies or side effects and catches even stuff that comes into the kernel from unexpected directions. All you need is a dirt-simple filter driver that you push on top of the filesystem to change delete/unlink calls so they move stuff into the trashcan, plus some ioctls to view/empty it.
Oh, wait, Linux doesn't have filter drivers. For a moment there I forgot we were talking about a "technically superior" OS.
Slashdot - News for Herds. Stuff that Splatters.