Slashdot Log In
Undelete In Linux
Posted by
Hemos
on Mon Sep 30, 2002 08:33 AM
from the using-the-tools dept.
from the using-the-tools dept.
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."
This discussion has been archived.
No new comments can be posted.
Undelete In Linux
|
Log In/Create an Account
| Top
| 697 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
See also... (Score:3, Informative)
PDHoss
Recycle Bins - don't you just hate them? (Score:4, Insightful)
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.
Re:Recycle Bins - don't you just hate them? (Score:5, Insightful)
If we want joe-user to use linux, we need silly stuff like this.
For you and I (and those in the know), we know damn well that you can delete a JPEG without it affecting anything. And if we're in doubt about a file, we know to move it somewhere temporarily. If something breaks, move it back. It's not all that often that you'll be deleting system files (and even then, its usually configuration files).
Anyhow, I guess the reality is that a tool like this only needs to be useful to someone. If it is useful to a couple of people, then its worthy of its existence. It's not like it is a default application. Don't use it if you don't want it. That's the beauty of the Open Source world...you can do what you want.
No, I don't. (Score:5, Insightful)
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
~~~
Re:Recycle Bins - don't you just hate them? (Score:5, Insightful)
>Because you have a poor machine with less than 4Gb of disk and you need all the space you can get
But still, no matter how long you've been a linux user it's still possible to accidently type "rm core *" rather than "rm core*" and not catch it until half a second after you hit enter and realize that you have irrecoverably destroyed your project(you didn't really want to punish it for segfaulting).
Re:Recycle Bins - don't you just hate them? (Score:5, Insightful)
From: Other Smug Person
Subject: Recycle Bin
As you may be aware, you feel it necessary to disable a safeguard for your system. We're all aware that you're infallable, and subject to all the perks and benefits that come with that title. However, for the rest of us who realize that mistakes *do* happen...
In Windows, delete sends things to the recycle bin. Shift+Delete sends it away forever and ever.
If you're so worried about your disk, change the ammount of space the recycle bin can use, you shaved monkey!
It's partly the attitude of people like you that kills Linux's chances on the desktop. Some people need to use computers, but *don't* work in IT, okay?
Sincerely,
Other Smug Person
Recycle Bin vs Trash Can (Score:5, Funny)
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."
why would you need that? (Score:3, Interesting)
Closer and closer. (Score:3, Informative)
But, this issue was discussed in a recent Ask Slashdot. I posted this comment [slashdot.org], regarging Novell's Salvage utility. A true file system level undelete utility such as this would be FANTASTIC. Is it possible to adapt libtrash to accomplish this?
No! It works good! (Score:5, Informative)
For a while I tried a bash utility for it...boy was that a bad idea - it wouldn't let me delete files with spaces in the names, and occasionally it would totally wig out when given certian input. So I switched to libtrash.
In answer to your comment, I want you to think about that. What you're suggesting, basically, is that the system works exclusively on local filesystems, which means that it is specifically programmed NOT to interact with the file system itself, but rather with the drivers for local devices. Seems rather far-fetched, don't you think? It works fine on anything you've got mounted.
Here's how it works: it remaps the glibc function unlink() to move files to a new directory - that being different for each user and dependand upon environment variables (mines called ~/.trash). Certain directories can be marked as "you can't delete from here." ~/.trash, for example, is one of these directories. There is also an included script to keep the ~/.trash directory below a certian size (I put this script in my cron.hourly).
There are currently two downsides:
1) The rule that the cleaning utility uses isn't very good right now. It picks the biggest over the oldest files to delete (at least, that's what it used to do - not really a big change so maybe someone's fixed it by now).
2) Using it as root can be disasterous during boot-up. Starting it at EXACTLY the right time after boot-up is difficult, and the only way I've heard of doing it is to replace the root's profile file after booting, which is a definite risk, because if the power cuts out and you still have that profile in place, the machine probably won't boot (mine wouldn't).
NOOOO!!!! (Score:4, Funny)
fuck it, hey, boss, if this patch becomes mainstream, can we move to solaris?
linux on the desktop (Score:4, Funny)
[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!
I know you're kidding, but.... (Score:4, Insightful)
[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
Re:I know you're kidding, but.... (Score:5, Informative)
I've installed mplayer on two SuSE 8.0 linux machines, and it's amazing. You can see DVD's, AVI's and even look at at microsoft media streams.
e.g. 'mplayer mms://streaming.omroepbrabant.nl/live1'
And how easy do you want it? You can easily make an icon on the desktop that starts mplayer on the dvd currently in the drive.
So, visit www.mplayerhq.hu and rejoice.
Re:I know you're kidding, but.... (Score:4, Insightful)
Um, KDE is really nice and my windowing system/manager of choice under Linux. But it's really not so "easy to use" "all the time" to the degree that Windows and Mac OS are.
[X] Standard software install system - LSB, Red Hat, Mandrake, Suse
By listing four things here, you've gone right ahead and said that the software install system is _not_ standard. There is a very different user experience for each distribution's install, enough to make the average user think he is installing a different OS for each one. I know my mom thinks Red Hat is an OS.
[X] Easy to use Windows filesharing - KDE, Samba
I can't say Samba is easy to use Windows filesharing. Easy to use Windows filesharing is clicking on a button that says share files and seeing that folder show up in Network Neighborhood. It's not SWAT.
Re:I know you're kidding, but.... (Score:4, Funny)
You mean GNOME, right?
Where's your sense of danger??? (Score:5, Funny)
...a GOOD thing. (Score:5, Insightful)
That being said, though, I think it's a great idea. It would be a tremendous fail-safe to those just beginning to learn the survival commands (more specifically, rm).
Plus, to all you old folks out there flipping me the eBird right now...I'll bet 70% of you (yet another made up statistic) have accidentally lost something by using rm without realizing which directory you were in. Happens to all of us. Wouldn't "sifting through the trash" be so much easier than looking throught yesterday's tape backup?
Well, maybe the tape is penance for screwing up the rm.
Re:How often do you really need undelete? (Score:4, Insightful)
The trick is that once an entry has been marked, it, and the sectors on the disk the file uses can be used by a different file. So the longer you wait, the less likely you'll be able to recover the file.
There's no undelete for Linux or UNIX because none of the filesystems support that feature, AFAIK. Also note that Microsoft's NTFS doesn't support that feature either. It's probably just too hard to integrate with everything else (like journaling) they've put in the FS. Personally, I'd like to see undelete put back into the FS layer (that's where it belongs, not the trashcan hack that everyone peddles). What would be really neat would be versioning (like a CVS filesystem) so I could revert to an earlier version of my file. This wouldn't necessiarly take more space since the FS could overwrite older data as it needed to (the older versions/delete files would appear to be free space).
Re:...a GOOD thing. (Score:5, Informative)
Put this in your ~/.bashrc and type 'source ~/.bashrc'.
I'm sure somebody can improve upon this by adding more checks, but basic functionality is there.
function rm () {
if [ $# -gt 0 ]; then
if [ ! -e ~/Trash ]; then
mkdir ~/Trash
fi
mv $@ ~/Trash
fi
}
TODO:
- set file permissions for trash can
- check that the files can be removed before moving them
- make sure you have a trashcan for each parition and move files to the trash on the same harddrive when removing them
- finish the TODO
Re:...a GOOD thing. (Score:4, Funny)
- Allow actual deletes. How do you empty the Trash can? mv -r *
some linux undelete urls (Score:4, Informative)
http://www.praeclarus.demon.co.uk/tech/e2-undel
http://chandra.ph1.uni-koeln.de/linux/HOWTO/min
http://lde.sourceforge.n
http://recover.sourceforge.net/
h
http://www.securi
So everyone is perfect? (Score:5, Insightful)
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.
Re:So everyone is perfect? (Score:4, Insightful)
rm means 'remove'. Not 'move to trash'. Think of it as the 'empty trashcan' command. Would you like a trashcan that moves things to yet another trashcan when you empty it?
If you're uncertain about wether or not to remove something dont use rm. You're entirely free to rm
And if you, despite knowing that rm means 'remove', make a mistake, just restore from your backups.
Re:So everyone is perfect? (Score:5, Funny)
Well, that is--more or less--the way that actual trashcans operate
bacchusrx.
README? (Score:3, Insightful)
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?
Not a solution (Score:5, Insightful)
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.
False sense of security (Score:5, Insightful)
better solution (Score:3, Informative)
alias rm="del"
echo "* 4 * 1 *
del:
#!/bin/sh
mv $* ~/trash
Its called backup (Score:3, Insightful)
Linux needs this at the filesystem level ... NOW (Score:4, Insightful)
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.
rm revised! (Score:5, Funny)
USAGE:
rm
-f fuck off with your trash bin, I'm deleting this file.
a better solution... (Score:3, Interesting)
On a similar note, it would be really nice if the filesystem kept a backup of the previous file metadata (specifically, owner, group, and permissions) so that you could "undo" an erroneous chmod or chown.
The total amount of data that would need to be added to the inode to support this kind of recovery is not all that large: The user, group and permission backups would require only 4 bytes each (total 12 bytes) and the saved filename could make due with as few as 32 bytes (most filenames are much shorter than that, and the saved filename is just a hint to the user). It would be nice to be able to reconstruct the entire file with only the data blocks and the inode, so the inode and data blocks would need to have linkage pointers to associate them together. All told, the inode would need about 64 extra bytes of information and the data blocks would need an extra 8 or 12 bytes of overhead.
And, yes, I've been thinking about this for a while: it's near the top of my 'to-do' list of neat open-source projects.
I'm Torn (Score:5, Informative)
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
safedelete (Score:4, Informative)
And I don't get these people saying they are too smart to need an undelete capability. Must be nice!
The TCT (Score:4, Informative)
From the FAQ [fish.com]:
"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 [fish.com]...
I don't think this is the right solution... (Score:4, Interesting)
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.
Potential gotcha (Score:3, Informative)
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`
RM protection in 5 characters :\-i (Score:3, Interesting)
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.
Why not do it for real? (Score:4, Informative)
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.
Re:What a drag (Score:3, Insightful)
Moron.
Re:Here's a Handy Hint (Score:3, Insightful)
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.
Re:Here's a Handy Hint (Score:3, Insightful)
Is it that hard?
And this my friends is the attitude keeping Linux from wider acceptance......