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."

Comments

See also...

[PDHoss]

http://ask.slashdot.org/article.pl?sid=02/09/29/02 7256 for a similar discussion.

PDHoss

Recycle Bins - don't you just hate them?

[fruey]

Reasons you don't need a recycle bin:

• Because rm doesn't take -f by default
• Because delete means delete, not put somewhere until I decide I really don't need it
• Because you're a Linux user and have a clue
• Because you're sick of people who restore files from the recycle bin because they think it's some kind of temporary folder
• Because you don't want anything to do with "recycling", you have /dev/null and you put everything there
• Because you have a poor machine with less than 4Gb of disk and you need all the space you can get

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?

[yatest5]

Yes, you're right. And all the people who contributed to this discussion (http://ask.slashdot.org/article.pl?sid=02/09/29/0 2 7256 ) are wrong.

Nice attitude.

Re:Recycle Bins - don't you just hate them?

[Coplan]

A friend of mine once told me that he would start using linux when they had a trash can type of thing. His reasoning was that he liked to make sure that his files weren't needed. He'd delete something, then wait about a week or so of regular computer usage before removing it from the "recyle bin". For him, this type of tool is very useful.

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.

Re:Recycle Bins - don't you just hate them?

[Apreche]

I think a recycling bin in more necessary in linux than in windows. In windows you graphically see exactly which files are being deleted, because everything is graphical.
In linux you might do something like rm *a*b*c*.*
That command can delete anywhere from 0 to all of your files depending on how they are named. And if you accidentally type *a*f*c*.* you might delete the wrong thing. Doesn't happen in windows, unless you are using cygwin.

Re:Recycle Bins - don't you just hate them?

[Zathrus]

It's an option in Windows too you know. I can't think of an OS where it wasn't an option, although I'm sure someone will dredge an esoteric example out of their hat and laugh.

Re:Recycle Bins - don't you just hate them?

[NMerriam]

It's an option in Windows too you know.

Sort of -- you can't tell a windows system to delete files directly AND turn off delete confirmations at the same time. I find it more annoying for the system to ask me every time I delete a file, so I set the recycle bin for 1% of the drive and turn off confirmations. When you set the size to 0%, it immediately turns on confirmations.

(another annoying thing is that it is "precentage" of the drive rather than actual size -- even 1% of my hard disk is a couple of gigabytes, which is a total waste)

Re:Recycle Bins - don't you just hate them?

[R.Caley]

if you accidentally type *a*f*c*.* you might delete the wrong thing.

Altogether Now:

Don't Do That Then.

Someone has to keep the old jokes alive you know.

Re:Recycle Bins - don't you just hate them?

[Transient0]

It is nice to be able to have the cheap sense of superiority that comes with not needing something that someone else needs. Of your reasons, only one is valid that I see:

>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?

[PainKilleR-CE]

At the very least, turn down the disk usage for the recycle bin. Personally, I just set it to 'use the same settings for all drives', then set 'do not move files to the recycle bin', and leave the prompt enabled just in case I accidentally hit delete, and then remove the recycle bin from my desktop (using a registry file I downloaded from OReilly in one of their Win* annoyances articles, which has worked in every version of Windows I've used from 98 to XP).

Re:Recycle Bins - don't you just hate them?

[Maddog_Delphi97]

Have you tried holding down the SHIFT key at the same time you press Delete when you delete files in file explorier? I think it does what you're talking about... and you don't have to mess with the percentage settings in the trash bin.

Re:Recycle Bins - don't you just hate them?

[tomhudson]

Or delete them from a command prompt.

They go bye-bye real quick

But really, when I delete files, I WANT them gone. Period. People are using trash cans and recycling bins as an excuse not to do proper backups!

Re:Recycle Bins - don't you just hate them?

[aaarrrgggh]

People are using trash cans and recycling bins as an excuse not to do proper backups!

For a single-user machine where no "production" work happens, you just might be correct. That all goes away when the machine acts as a file server! What a proper undelete function (like NetWare's Salvage) does is not replace backups, but it does provide version control. Tape backups can give you a daily snapshot of a file, but just what appears at the end of the day.

User accidently over-writes a file they spent all day working on at 5pm? At least a lost day's productivity, but it could also mean a missed deadline! Snapshots, midday backups, etc. help with the lost productivity, but when there is a deadline crunch, the user having the ability to restore a file they JUST deleted without administrator support is HUGE!.

The elegance of Salvage is its transparency. A "recycle bin" does some things, but how well does it handle temporary files?

For a file server, functionality like Salvage really is essential!

Re:Recycle Bins - don't you just hate them?

[tal197]

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).

$ rm core *
zsh: sure you want to delete all the files in /bin [yn]?

Maybe you're using the wrong shell ;-)

Re:Recycle Bins - don't you just hate them?

[joss]

It's not as simple as that. I believe that false sense of security created by recycle mechanisms are counter productive. It's like building extra roads to avoid conjestion. People just drive more until conjestion is just as bad as it always was. The more foolproof you try to make something, the more foolish people become.

It's perfectly straightforard to replace rm with something that moves files to a recycle directory. People don't generally do this because it doesn't really help. At the end of the day, either you want to delete it or you don't. It's not about superiority, it's about human nature.
When you firmly believe that deleting something will really delete it, you adjust. Now, some people have got used to having a recycle bin. For them it may be prefereable to alias rm 'mv !:* ~/trash' or whatever. It depends what you're used to. I sincerely doubt this means they will lose less data accidentally. A regular automated backup policy is usually a better option.

Re:Recycle Bins - don't you just hate them?

[Reziac]

Not only that, but in my observation, it's when a person is MOST SURE that they want to delete everything per some filespec, is when they are also most likely to forget about the other files that just happen to match the filespec slated for deletion. Oooops...

Re:Recycle Bins - don't you just hate them?

[wilhelm]

Aliases like that are a good way to screw yourself. If you depend on that -i alias, what happens when you move to a system (or su to a user) which doesn't have that same alias? Pain, most likely.

For some reason, Redhat systems do just the opposite of what you describe - root gets -i (on rm, cp, and mv), and everybody else doesn't. One of the first things I do on those systems is remove those aliases from root's bashrc, just to forestall any trouble.

Re:Recycle Bins - don't you just hate them?

[TheTomcat]

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

I once typed `rm -r logs/old /` instead of `rm -r logs/old/`

... as root...

... on a production machine ...

... that didn't yet have the backup-unit installed (by our colo -- their problem)...

that was a sucky weekend. (-:

S

Re:Recycle Bins - don't you just hate them?

[naasking]

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).

Actually, different scenario for me: I was copying to and from multiple disks and I typed 'rm -rf *' in what I thought was my home directory on the destination drive. In fact it was my original drive and I didn't realize it for a good 5-10 minutes. Since the destination was incompletely copied, I lost a great deal of data. That day, I learned to look at the whole path (not just the last bit) before I type in something that serious again.

Re:Recycle Bins - don't you just hate them?

[thomas.galvin]

I've said it before, I'll say it again: ctrl-s saved, ctrl-d deletes. They should not be that close together.

Re:Recycle Bins - don't you just hate them?

[platypus]

Show your friend how much nicer it were if he could find out if something needs a certain file by knowing when had been accessed in the past, instead of moving it and waiting for random breakage.

Then teach your friend what

ls -lu

means.

Re:Recycle Bins - don't you just hate them?

[God! Awful]

To clean up some disk space, I once typed "rm -rf core*" in my root source directory (actually it was a script that did it). Sadly, this also deleted such files as core.c from the Linux source tree. My script now explicitly excludes the Linux source, but the next time I need to recompile my kernel is going to be a bitch.

-a

Re:Recycle Bins - don't you just hate them?

[Suppafly]

But really, when I delete files, I WANT them gone. Period.

When I really really want to delete files, I right click on them and do the option for pgp to delete them and wipe them several times with random data. But maybe I'm just paranoid?

Re:Recycle Bins - don't you just hate them?

[Anopheles]

>People are using trash cans and recycling bins as an excuse not to do proper backups!

I've seen worse!

I have seen users put stuff into their Recycle Bin just because it's a convenient "folder" on their desktop (And yes, the "My Documents" folder was there as well, but was completely ignored.)

The inherent flaw in this solution was demonstrated when one of our helpdesk guys needed more disk space to install some patches, and emptied the Recycle bin - and erased months of work. Now, the obvious common-sense moral of this story should be, "If you play with fire, eventually you will get burned."

However, common sense does not rule here. We don't educate our administrators, presumably because they're infallible. Instead a new policy was drafted saying we have to backup the Recycle Bins on all administrative boxes and the "Trash" folders in all the Mailboxes daily.

Beauty, eh?

Re:Recycle Bins - don't you just hate them?

[Codifex Maximus]

Yeah, I had a waste basket on my TRS-80 Model 1 but the bag wasn't a Hefty so it leaked all the time. Played hell with the expansion unit...

Re:Recycle Bins - don't you just hate them?

[mcg1969]

Once on an old Ultrix machine I wanted to delete some dot-files, including a subdirectory that started with a dot. So, as root, I typed

rm -rf .*

The problem with that was that '.*' included '..' ... so eventually it ascended into the parent directory, and began deleting every file and directory there. That was particularly unfortunate because the parent directory was the root directory!

Before I realized what it was doing it had wiped out /bin and /etc. And this was our department's file server, so yes I had a sucky weekend too... I couldn't even give the machine a proper shutdown because I'd managed to wipe out that command!

Re:Recycle Bins - don't you just hate them?

[unapersson]

You've already got this under Linux if you use Nautilus as your file manager. It has a trash can.

Re:Recycle Bins - don't you just hate them?

[ArsonSmith]

Thats like the crontab -e (to edit your crontab) and crontab -r (to remove your crontab)

those two are too close together as well. I havn't yet done it but I know someone who has.

Re:Recycle Bins - don't you just hate them?

[kalidasa]

In linux you might do something like rm *a*b*c*.* That command can delete anywhere from 0 to all of your files depending on how they are named.

Isn't natural selection wonderful?

Re:Recycle Bins - don't you just hate them?

[Mark Bainter]

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

That's why you alias rm to rm -i for root, and get in the habit of using this wonderful thing called tab completion.

% ls
core1 core2 file1 file2 file3 file4 file5

% rm -f *<tab>

becomes:
% rm -f core core1 core2 file1 file2 file3 file4 file5

Re:Recycle Bins - don't you just hate them?

[geekoid]

"And if we're in doubt about a file, we know to move it somewhere temporarily. "
you mean someplace like /recycle/can/

Re:Recycle Bins - don't you just hate them?

[Eil]

IMHO, this is a good example of why I think many administrative things that must be done by root shouldn't be performed from a command line unless absolutely necessary. Whenever I'm working on something that involves deleting, moving, or editing files, I try to use a file manager (FileRunner) as much as possible. Not only are you less prone to mistakes, but it's faster and easier to visualize exactly what you're doing when you can actually select the files that you want to manipulate.

Yes, it's entirely possible to select the wrong file or hit the wrong button and delete something you didn't mean to. However, you are FAR less likely to trash the whole system when it's 2AM, you're working at your command line, your vision is blurry, and your space bar seems a lot bigger and easier to hit than it normally is. Like I mentioned before, with a file manager you can see EXACTLY what you're about to do which gives you an extra chance to catch any potentially boneheaded errors.

Re:Recycle Bins - don't you just hate them?

[snake_dad]

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*"

Think that's funny? We have a lot of windows only programmers, who decided to call their project Contact Registration "core". Really. All database files on unixware. core.db, core.bi, and so forth. Unixware names its coredumps core.xxxx, where x is number. Now imagine a cleanup script containing find / -name core.* -exec rm -f {} \;

Re:Recycle Bins - don't you just hate them?

[jgerman]

User accidently over-writes a file they spent all day working on at 5pm? At least a lost day's productivity, but it could also mean a missed deadline! Snapshots, midday backups, etc. help with the lost productivity, but when there is a deadline crunch, the user having the ability to restore a file they JUST deleted without administrator support is HUGE

I do see your point and agree in general that a trash can is not a bad thing, but in this specific example I have to disagree. If a user is in need of version control, they should be using a version control package. I use RCS for every little thing I write, just to make sure that I'm covered. Everything get's rcs'ed up until the point I check it into my CVS codebase. That's safety, and that's for home stuff that I can actually afford to lose. In a business environment it should be mandatory.

Re:Recycle Bins - don't you just hate them?

[jgerman]

Two words: "version control". Easy to set up, easy to use, and will save your ass.

I won't complaing about a piece of software (un-in=stallable of course) to do the Trash Can thing though, to each his own. Linux is made to be customized, do we really need a holy war on what tools someone uses, err do we really need ANOTHER holy war on what tools someone uses?

Re:Recycle Bins - don't you just hate them?

[Hercynium]

Isn't this the type of feature that could/should be implemented at the file system level, rather than the shell level? Granted, I don't know how it's done on the mac, but I do know that if you put some files in the trash and then try to open them in any application, they won't open. Any executables in there won't run either. I think the same goes for aliases as well.

Anyhow, now that osx is on a unix kernel I see no reason it can't be implemented, along with revision tracking and perhaps some other nice attributes like package/application association and whatnot. Not to troll, but I have heard rumours that that type of thing will be built into the next version of windows...

I'm beginning to ramble, but I feel like this is a good idea (I've thought of it before, but only recently have I learned enough about the linux kernel to attempt it...)

What we need is a distro with a new filesystem... for now just base it on the standard ext*fs and add the ablilty to include in each file's attributes the package it belongs to, along with the version, et al, and perhaps even the name of the process that created the file in the first place. The extra data wouldn't interfere with any existing software, and package managers/installers could be extended to work with it. (why not? we have apt-rpm now)

A whole bevy of tools could then be created for sysadmins who need to resolve some shared-lib incompatibility or who want to uninstall an app but the rpm database had long been munged, or better yet need to modify the files installed by a package but may want to choose whether to delete (or keep) it after uninstalling!

Yeah, I know all this is already done by existing tools... I've just always felt them lacking in one way or another. :)

Re:Recycle Bins - don't you just hate them?

[quinto2000]

consider that not all files really need version control. It is a huge load on the system to use RCS for every single file...it only makes sense for files like academic papers, a movie you're working on, etc.

Re:Recycle Bins - don't you just hate them?

[RAMMS EIN]

``Anyhow, I guess the reality is that a tool like this only needs to be useful to someone.''
I beg to differ. Think about it. What does this software lead to? BLOAT.

Features that most people don't need (actually nobody _should_ need undelete) should not be installed by default. Of course, ``most people'' depends on the distribution - a distro geared towards power users could do without undelete, whereas a distro for newbies might be better off having it included, but should probably leave out fingerd.

Re:Recycle Bins - don't you just hate them?

[ColaMan]

Of course, the best way to handle it would be to have a key combination for rename

In windows, pressing F2 when a file is highlighted will rename that file.
Well, it'll go into the 'edit' mode on the filename, you actually have to rename it yourself.
Enjoy ;-)

Re:Recycle Bins - don't you just hate them?

[sfe_software]

If you single click twice slowly, it lets you rename too. I prefer this over waiting for the right click menu to find all the NEW|> options and render.

God I hate that "feature". Especially if your mouse sucks (if you move even one pixel between clicks in a double-click, you're renaming).

I use F2 to rename. I very rarely rename files while inside an "Open" dialog, yet, I'm constantly accidentally slow-double-clicking. Of course you can't turn this feature off (that I am aware of).

Another one I can't stand, in Win2k at least, the "New Folder" icon is right next to the "Up Directory" icon in the Open/Save dialog. How many times I've had to delete "New Folder"...

Not to mention Win2k's Open/Save dialog never remembers your View settings. I love "Details", and I hate the sideways-scrolling variable-width list view. But, since it never remembers I find it useless to bother changing it every time.

But enough about that... to contribute to the topic, I think an Undelete would be good if it worked like the old Norton (IIRC) undelete:

- Deleting a file marks it (on the filesystem) as deleted, just as always
- The filesystem doesn't re-use that space until it has to
- A utility lets you find such "deleted" files, view their original location etc, and "restore" them

With this method, disk space is never really used, in that the more space you have available the more stuff you can "undelete". Perhaps this utility would also let you truly remove files (or even scramble the bits to truly wipe it).

That would be the ultimate, as it would protect joe-average and at the same time work no differently for the rest of us. Unless we needed it.

linux on the desktop

[redhotchil]

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!

Re:linux on the desktop

[Junta]

Video: xine (and totem, by extension) and mplayer help a great deal. Even on my non-x86 laptop I can play nearly anything with xine... MPlayer is a tricky proposition, on some systems it works beautifully, and on others it is a resource hog more than anything else...

I think that having totem set up by default on linux desktops would go far to dispel the 'no good media player on linux' myth...

Re:linux on the desktop

[Junta]

You by chance using a Savage chipset? I have had to disable key features of xine on Savage to keep it from falling on its ass on Startup. Every other system but Savage Video cards I have had no troubles with...

Where's your sense of danger???

[netphilter]

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?).

Re:Where's your sense of danger???

[MicroBerto]

I used to live with a sense of danger. I had a bash alias so that every time i typed in 'rm', it would do 'rm -f'

You can imagine why I'm back into interactive mode :) (and yes it does involve accidentally deleting shitloads of porn)!

Re:Where's your sense of danger???

[archen]

This reminds me of a manegement CGI script I wrote for a friend. The conversation went something like this.

friend: [clicking around on everything]
me: ...And as you see there you can delete things too.
friend: [clicks delete] "Uh oh, what did that do?"
me: you just deleted that entry
friend: oh geeze. really?
me: yes, that's why that big button says "DELETE"

later I had to add some javascript for a confirm because he felt it was "too dangerous". At times I wonder if Windows doesn't make people act more stupid by treating them like idiots.

So everyone is perfect?

[GreyyGuy]

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.

Re:So everyone is perfect?

[Znork]

Because a lot of us _mean_ rm when we type rm. Otherwise we would have used mv. Or used Nautilus or some other filemanager that by default puts stuff in the trashcan.

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 /bin/rm if you dont want to use it. Or even mv /bin/rm /tmp if you're uncertain about wether or not to remove it permanently.

And if you, despite knowing that rm means 'remove', make a mistake, just restore from your backups.

Re:So everyone is perfect?

[bacchusrx]

Would you like a trashcan that moves things to yet another trashcan when you empty it?

Well, that is--more or less--the way that actual trashcans operate ;)

bacchusrx.

Re:So everyone is perfect?

[Dark Paladin]

Now, personally, I think a halfway point is better here.

For some people, "rm" means "rm" - for my wife, "rm" means "delete this", which is different, since she might want to get that back.

So I'd simply include an undelete function by default - but let "experts" such as yourself set a flag to truly remove the file. No muss, no fuss. Everybody happy.

Re:So everyone is perfect?

[Znork]

This isnt an RTFM attitude, this is a 'use the GUI filemanager' attitude. The filemanager is there to be friendly and to help newbies. The filemanager will put things in the trashcan. There is nothing stopping anyone from adding a friendly (and most distributions have it) alias for rm either, for the shell newbies.

But unlink(2) and rm need to do what they're meant to do or there's no end to the things you break. Applications and scripts that create loads of temporary files can fill up a filesystem in minutes or even seconds if unlink and rm suddenly arent 'really really really _delete_ this' anymore.

There are solutions to this. Use them.

Re:So everyone is perfect?

[Daniel]

The problem that springs to mind immediately is that this can affect *every program*. (and if you preload it in .xsession or .bashrc or something, it will)

That doesn't just count the user files you go and delete; it also counts the work file your graphics manipulation program generates, the intermediate cruft from compiles, the weirdly named checkpoints your desktop software writes out...in other words, tons of stuff that has no business being saved forever (or until the user remembers to empty the trash, which is -- to a first approximation -- the same thing)

If nothing else, you're quite likely to watch your available disk space go up in smoke, especially if more than one person uses your computer.

Anyway, I generally don't care; I won't be using this anyway (see above), but what other people do with their computers is their own business.

Daniel

Re:So everyone is perfect?

[mr_z_beeblebrox]

And how long before virus writers realize this and start explicitly infecting the /tmp folder?

Most undelete folders with cots products have their own default settings which are very weak that is why they are targeted. If they can target /tmp that is the admins fault, executable code does not belong in /tmp at least not with the intention of it being run.

Re:So everyone is perfect?

[kfg]

I'll even go so far as to defend the people who use it as a temp folder, * because that's what it is!* Just a temp folder with an "autorestore to its original site" script that happens to be named trash/recycle. It could be named George or Herbert, it doesn't matter.

The people who use it as a temp folder aren't the idiot users, they're the users who are smart enough to have seen through the facade of the interface and realize what *tool* the trash/recycle bin really is.

If it will make any if you who are bothered by this advanced insight on the part of some users any happier we can always just install *two* trashcans on every machine and name one of them "This is really another trashcan but we've named it George because some people get all bent out of shape by people using the one named trash the way it was designed to work, go figure."

There is no such thing as sympathetic magic, things are what they *do,* names have no power and are arbitrary. Join the age of reason brother.

KFG

Re:So everyone is perfect?

[Kintanon]

Well, I won't complain about them using it as a tmp folder, as long as they don't complain when the first thing I do when I sit down to see why their desktop background changeed colors is empty their 750mb recycle bin.

Kintanon

Re:So everyone is perfect?

[Suppafly]

No kidding, I'm a residental network technician at my university and I empty peoples trash all the time, as well uninstalling aol and uninstalling kazaa and running adaware. Then again, we make them sign a waiver before touching anything too..

Re:So everyone is perfect?

[Suppafly]

So what about when someone gets a virus which infects the undelete folder.

So what about it? The only thing you can do with the files in the trash are undelete them back to their original spot and truly delete them. I don't see this as being an overly exploitable system.

Re:So everyone is perfect?

[geekoid]

so what you are saying is "yes, I am perfect because I make no mistakes. When I do something, it is always what I intended to do, and no, I would never make a mistake is a script."
Jeez, if you were any more perfect, they would nail you to a tree.

You aside, most people arn't perfect.
It is farly easy toi do, and all user who previously used windows or a mac will expect it.

If you want people to use Linux, then Goddamn, give them the simple stuff. the fact that you won't need it is secondary, because you can turn it off. Hell, you can bypass the trash can in windows.

Re:So everyone is perfect?

[geekoid]

God forbid some use something it wasn't intened for. I mean, what next, someone using a piece of hard for something it wasn't designed for? madness I say, Madness! ;)

Re:So everyone is perfect?

[Znork]

No, what I'm saying is "I dont use rm if I dont really want to delete things". I dont smash my disk with a sledgehammer either to delete files. Nor do I use shift-delete under Windows or use move-to-trash followed immediately by empty trash. rm is a sledgehammer and it's not what you should use unless you actually do want to really make sure the files are gone.

And when I write scripts I dont use rm. I use ls or mv until I'm very sure it does exactly what I want. And then I replace the ls or mv with an rm.

A Windows or Mac user expects 'delete' in the file manager to move to trash. And guess what; it does exactly that in Linux too. They shouldnt have to open a shell to delete a file, and in that case there is no problem.

Re:So everyone is perfect?

[IGnatius T Foobar]

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.

Well, it goes something like this:

• Install an operating system without trashcan support
• ??
• Profit!

I know you're kidding, but....

[FreeLinux]

[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

Re:I know you're kidding, but....

[Xpilot]

[X] Easy support for video files and DVD - Xine works for me like a charm :)

Re:I know you're kidding, but....

[oever]

[X] Easy support for video files and DVD - mplayer

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....

[Josuah]

[X] Easy to use Windowing system - KDE

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....

[Fastball]

[X] Easy to use Windowing system - KDE

You mean GNOME, right?

Re:I know you're kidding, but....

[Captain Large Face]

[x] Easy support for video files and DVD

You could do a LOT worse than mplayer..

Re:I know you're kidding, but....

[(H)elix1]

[ ] Easy support for video files and DVD - No answer

Take a look at http://videolan.org/'s client. Easiest DVD player I've worked with...

From the site,

The VideoLAN Server can stream video read from a hard disk, a DVD player, a satellite card or an MPEG 2 compression card, and unicast or multicast it on a network. The VideoLAN Client can read the stream from the network and display it. It can also be used to display video read locally on the computer : DVDs, VCDs, MPEG and DivX files and from a satellite card. It is multi-plaform : Linux, Windows, Mac OS X, BeOS, BSD, Solaris, QNX, iPaq... The VideoLAN Client and Server now have a full IPv6 support.

VideoLAN is free software, and is released under the GNU General Public License.

Re:I know you're kidding, but....

[garcia]

I don't consider "Easy support" being mplayer.

Libraries, different configuration options (configure --with-gui), and configuration files...

I use it daily, I love it, but I don't think most "everyday users" would think it was easy.

Re:I know you're kidding, but....

[iapetus]

By listing four things here, you've gone right ahead and said that the software install system is _not_ standard.

Then what OS would you recommend that *does* have a standard software installation mechanism? Windows certainly doesn't count - I've used three entirely different installer applications just today...

Re:I know you're kidding, but....

[Nailer]

"[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.

I think what the poster meant was that Red Hat, Mandrake and Suse all conform to the Linux Standards Base. Which defines the standard packaging (software install and maintenance) system for Linux. Of course, you can pick your own front end.

"[X] Easy to use Windows filesharing - KDE, Samba"

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

Damn stright, I agree. But KDE does have this ability - look for ksambakonquiplugin (shit name I know) on apps.kde.com. Its too bad the distros don't ship with it turned on by default.

Re:I know you're kidding, but....

[ndogg]

This is not meant to be a troll, I am seriously asking a question.

What's not so easy to use under KDE? Whenever I let people use my machine who've only used Windows, they have no problems doing so, unless I happen to have the BeOS window decorations on, but that's understandable. Now, mind you, the only things in my GUI that I concern myself with configuring are the look-n-feel elements, otherwise, I mostly just leave it to the installed defaults. Beyond that, I only concern myself with configuring things like Apache, sshd, samba, or some other such arcane Unix utility.

Re:I know you're kidding, but....

[vidarh]

No, I don't find it ironic, considering that all four of them use RPM. Now referring to Debian, that is ironic, considering that most distros use a different install system that it does.

Re:I know you're kidding, but....

[kmellis]

"You are right. Also remember that simplicity is inversely proportional to usefulness and flexibility."

For example, like driving a modern automobile?

Re:I know you're kidding, but....

[jd142]

Ogle.

1) Downloaded the rpms.

2) Did rpm -ivh *.rpm.

3) Was watching the Fifth Element in under 5 minutes from the time I started downloading. Fast forwarded through the FBI junk even.

The only way it could have been easier was with a single download that was executable and just by double clicking it would install everything. That wouldn't be too hard to add though.

Re:I know you're kidding, but....

[Latent IT]

That is, if it fails for any reason (file missing, user cancel, etc.), then it will completely roll-back and not leave bits of a partially installed application.

He's not kidding. Unless the program being installed was written by a malicious bunch of idiots, Windows Installer will do exactly that. It's quite capable doing so. It's also fairly easy to put together a package to be installed.

In fact, the only reason things get left behind at all is because things are created once the program is run for the first time that don't get put into the windows installer database. So, if you uninstall say, Starcraft, your saved games are left behind.

Don't laugh at something you clearly don't understand, or even use properly. You sound like a smug jackass when you make laugh at something, and then like a retard to boot when you're wrong.

Re:I know you're kidding, but....

[peterpi]

Then what OS would you recommend that *does* have a standard software installation mechanism?

All together now...

FreeBSD!

Re:I know you're kidding, but....

[SirGeek]

You are right. Also remember that simplicity is inversely proportional to usefulness and flexibility.

Simplicity in programming or use ?

To me, for training a *NIX neophite from windoze, it would be LOTS simpler to say click on the directory and say share, pick users, etc. than to say "Open an editor and edit /etc/samba/smb.conf and add the share in there, then restart samba...

MUCH more difficult, and if we want to be an OS for many other than techies, this is going to need to be some sort of add into the Window Manager applications (I mean, is it that "tough").

We have a bad perseptions as programmers (yes, I've been a professional software developer/designer for over 14 years) to think we know it all. We don't. We know programming but, ususally we don't know dick about what the actual end users would find useful.

Re:I know you're kidding, but....

[TheGreek]

He's right. It does this. Let me know when rpm starts doing this.

And no, pumping a listing of the package's manifest through 'xargs rm' doesn't count. Real People don't know how to do that.

Re:I know you're kidding, but....

[zmooc]

[ ] Easy support for video files and DVD - No answer

mplayer. Binary distribution and integration into desktop environments needs to catch up a bit, but we're about there.

Re:I know you're kidding, but....

[Suppafly]

One good thing about Windows Installer is that the install is an atomic procedure. That is, if it fails for any reason (file missing, user cancel, etc.), then it will completely roll-back and not leave bits of a partially installed application.


That is assuming that it doesn't decide to break your other msi installed apps leaving them unrunnable with your registry messed up.

Re:I know you're kidding, but....

[Suppafly]

[X] Standard software install system - LSB, Red Hat, Mandrake, Suse

Does anyone else find it ironic to see the word "standard" on the same line as four different options?

No, not considering that its one answer with 3 options. It should have been written like this
>[X] Standard software install system - LSB: Red Hat, Mandrake, Suse

Re:I know you're kidding, but....

[RealAlaskan]

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.

Since you mention Mac, you probably don't think ``easy to use'' means ``just like MSWindows''. What does ``easy to use'' mean to you?

My four-year-old has no more problems with KDE than she does with MSWin. Both kids manage to screw up MSWindows periodically. They haven't managed to get Linux (currently RH7.3) screwed up enough to need help for quite a while. For me, Linux is easier to use as a kid's toy than is MSWindows. If it only ran Reader Rabbit!

My wife couldn't tell which OS the kids were running until I taught her to look for the big K versus Start. She knows that our box is always running Linux, and hasn't had any problem browsing the web and reading email. I don't have to worry about her opening the viruses our goofy friends send her, either (knock on wood). If I trained her to su to root, and type ``apt-get update;apt-get -u upgrade'', she could do the system administration, too. It's not that easy on Windows.

A friend just got a WinXP computer (on purpose, yet!). He's having terrible problems getting it into a usable state. If his mind didn't go blank at the mere thought of understanding his machine, I'd set him up with Debian, since I suspect that KDE would be easier for him to do his thing with. He liked Knoppix, but the thought that it's non-MS worried him.

Linux presents a lot of little difficulties, but so does MSWin. The difference is that if you know what you are doing, you can fix the problems with Linux. Presetup Linux isn't ready for the desktop yet, but neither is presetup Windows.

Re:I know you're kidding, but....

[0x0d0a]

Umm...I've had decidedly nasty experiences with failed installs of IE that definitely did *not* fully roll back.

I'm not saying the technology isn't there, but even MS doesn't use it, at least some of the time.

Re:I know you're kidding, but....

[BlueGecko]

hen what OS would you recommend that *does* have a standard software installation mechanism?

Mac OS X has only one install mechanism, though arguably two procedures. In many cases, the entire application and all support files are in a bundle, so there is no real install; just, if you want, you can drag the application to whatever folder you want to run it from, but I do want to emphasize that that's not necessary if you'd rather leave it in its download folder. Almost all applications except those that need to install system files, those from Apple, and those from Microsoft fall into this category. The only official mechanism to install programs is the Installer application, which always presents not only the same UI, but the same procedure (i.e., same sequence of events) for installing applications. This is used by any application that needs to install system files, plus a few rogue apps whose creators, for one reason or another, decided they needed to force the user to use Installer. So I could make a good case that OS X has one install mechanism and two procedures.

(Having said all that, Microsoft's Internet Explorer and Palm's PalmDesktop applications, for reasons I cannot fathom, use their own weird installers, but as far as I know, they are the only two applications that use whatever it is they're using.)

Re:I know you're kidding, but....

[TRACK-YOUR-POSITION]

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.

For the purpose of this complaint, your mom is basically right. Microsoft doesn't make a package management system that works on multiple corporations distributions of the OS, so why should Red Hat. Just pretend Red Hat is an OS and your complaint goes away. Just because both kernels are signed "Torvalds" doesn't mean their the same OS. Heck, Red Hat even changes the kernel anyway.

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.

Maybe your describing Mac OS X Windows file sharing, because it's not that easy on any Microsoft OS. Sure, that's all that you're supposed to have to do. But have the time it doesn't work. "Okay, enter this name and password to get my files." "uh--it's just asking me for a password, no name." That's if you can somehow magically get the computers to see each other.

You can come back and say "you must have done it wrong, TRACK-YOUR-POSITION", but if there was anything for me to screw up, that just proves it's not as easy as you claim it is.

Re:I know you're kidding, but....

[Codifex Maximus]

>[X] Easy support for video files and DVD - Xine works for me like a charm :)

Never tried Xine but MPlayer does a fine job of playing just about any movie file I throw at it with nary a complaint. I got it set as the default application for playing most movies in KDE.

As for standard installers in Windows... there ain't no such thing. Installshield is the closest thing to a standard in Windows (but that is also quite available in Linux.) I've installed not a few Linux apps using a jar file that had Installshield for the installer - some script installers too. Anyway, there are many different installers in Windows - many operate similarly enough that the user doesn't notice. The main exception is Microsoft - they always have to be different - the odd folks out.

Re:I know you're kidding, but....

[electroniceric]

"[X] Easy to use Windows filesharing - KDE, Samba"

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

Damn stright, I agree. But KDE does have this ability - look for ksambakonquiplugin (shit name I know) on apps.kde.com. Its too bad the distros don't ship with it turned on by default.

True, this is a nifty little extension to Konqueror, and should be shipped w/KDE. There's still a big hole it in it, though - adding shares requires (AFAICT) root access to modify smb.conf, and then restart smbd and nmbd. There ought to be a way for users to share their own files without the intervention of root.

Re:I know you're kidding, but....

[J. Random Software]

Microsoft does have a standard installer framework (if you've ever seen a MSI file, this is how it works). Many products still don't use it because it wasn't bundled until WinXP and many users haven't downloaded it as an add-on. It can stub out components and then really install them on first use, which is fairly cool over a reliable network (but an awful nuisance if you installed off a CD the BOFH then locks up).

Re:I know you're kidding, but....

[Da Schmiz]

peterpi writes:

Then what OS would you recommend that *does* have a standard software installation mechanism?

All together now... FreeBSD!

or Gentoo.

Re:I know you're kidding, but....

[drinkypoo]

mplayer is a serious bitch to build, as are many of its requirements. Installing from a binary package is no answer, it defeats some of the purposes of an open source solution.

Also, my K6/2-433 laptop with ATI Rage Pro LT graphics can play DVDs very cleanly at 800x600 fullscreen in windows 98, but choked horribly under linux once I got something going. It may have been possible to speed things up - I don't know - But it has to be easy on a wider variety of hardware, not just the vastly overpowered and most-supported stuff.

Re:I know you're kidding, but....

[dfaure]

> Easy to use Windows filesharing is clicking on a button that
> says share files and seeing that folder show up in Network
> Neighborhood.
Like one can do in Konqueror-3.1 (and in Mandrake-9.0's Konqueror) ?

Yes, that box can get a checkmark now.

David.

Re:I know you're kidding, but....

[Codifex Maximus]

MSI is a standard now? Who said?

BOFH: Ok, let's see...what was your username again?
USER: joeuser.
BOFH: Ok, let's have a look see if you have any files. clikety click.
BOFH: Nope. I don't see any files in your home directory.
USER: What?!
BOFH: clickety click click. I don't see a user by that name either.
BOFH: As for the CD, it's on plain display in the secure room. Visible thru a large 3"x3" viewport.

Recycle Bin vs Trash Can

[chill]

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."

README?

[brunes69]

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?

Re:README?

[brunes69]

Apparantly you didn't read the comment at all... i was commenting on how incredibly lazy it is to not post a README on the web (takes all of 3 seconds) because people like me do not want to download the whole file, untar it, and view the files just to see what it does. A simple description of what it i and how works would suffice.

Linux Undelete Project

[wlugo]

when I was in college some people and I did a Linux Undelete on the kernel using the ext2 filesystem. The whole procedure is described on http://amadeus.ece.uprm.edu/~undelete. The problem was we didn't found enough people to supported on greater kernels. I think it could be easily ported to ext3.

metacommentary!

[fraxas]

Please ignore the idiots above -- the l1nux-l337 are always a pain in the butt about usability issues. As a response to the ask-slashdot rfe from last week, this works really well.

As a point of note, those of you complaining about the disclaimer in the article should realize that, if the disclaimer hadn't been there, you would be complaining about how "/. isn't an advertising service, you Window$ Idiot!!111!11!!!11!!"

Sheesh.

Not a solution

[cpt kangarooski]

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.

Re:Not a solution

[Suppafly]

What your talking about is almost exactly how dos handled file deletion.. a file wasn't listed by dir anymore, but unless you did a lot of file IO or ran defrag, you could easily undelete the file using the undelete command.

Re:Not a solution

[Loki_1929]

"Even with your solution, the file will be deleted eventually (when its blocks get reused)."

There's no solution that offers absolute recoverability 'til the end of time, but we're talking about implementing a system which will allow for maximum data integrity post-deletion without a major performance hit. Moving deleted data to the end of the drive upon deletion seems like a good way to start, especially with larger hard drives available today. The next step would be keep a catalog of sorts, listing a priority index for each deleted file so the file system knows which files to overwrite first when deleted data space needs to be reclaimed for new files. Another user pointed out that such priorities could be established by using an algorithm that looks at access frequency amoung other factors. Assuming you have a 40GB hard drive (small for a new computer), and assuming you use roughly half of that drive at peak usage, this leaves you 20GB of deleted files available for recovery on demand. This could go back months, or even years for some people without seriously hitting your disk performance, as the data currently being used should be at the "front end" of the drive. Obviously, this is a simplistic view of the system that would need to be implemented, and serious issues would still need to be addressed to make it viable; security and performance being two of them, but the fundamentals must be in place before details may be realized.

Re:Not a solution

[Spy Hunter]

No, letting the user keep undeleting files as long as possible is bad. Why? Because when you know you can do something, you start to rely on it. So the user will start to be a little less careful emptying the trashcan, since he knows that he can undo it right away if he wants. Except that one time he accidentally empties the trash right before he installs a program, and then he tries to undelete and whoops! His data is gone forever. Unreliable undeletes are bad news; there are good reasons to make emptying the trash a permanent operation. There probably still is a place for undelete utilities, but it shouldn't be something that is built into the OS and is easy to access, it should be something used only out of desperation.

Re:Not a solution

[cpt kangarooski]

I've been thinking about this. However, I don't think that very many users would come to rely on it in a harmful way as you suggest. Particularly if it is made very plain that it is not a guaranteed thing.

However, I'd definately suggest user testing to see how people react, rather than have us all take unsupported wild-assed guesses. Scientific method, and all that, you know.

Hmm... Interresting? What about filer?

[LWolenczak]

I was thinking about filer last night, and this morning, we get libtrash. People have always had issues with deleting files. I personally keep a ~/bla/ directory. I move unneeded things there. If I don't need the files after a few months, I trash the directory, and recreate it. The concept is still better then an undelete, but I remember deleting some very important files on my first linux system... like vmlinuz and the /boot directory because I did not know better.

What we need now is

[dfgdfgdfg]

What we need now is the Gnome (or KDE) panel set LD_PRELOAD so that all application can use libtrash.

Re:What we need now is

[kcbrown]

What we need now is the Gnome (or KDE) panel set LD_PRELOAD so that all application can use libtrash.

This can be done for Gnome in your $HOME/.gnomerc file, which is just a shell script (I have mine source my .profile so that I can make environment changes in one place).

Works in Debian, at least.

False sense of security

[Myshkin]

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.

Re:False sense of security

[windex]

Actually, if using LILO, you move the kernel to the recycle bin and the recycle bin is on the same partition, nothing should happen, all you've done is change the location of the inode in the directory structure, without changing the physical location of the data.

This is dangerous. :) Someone might eventually decide deleting it is a good idea.

If you rm -rf /, and it whacks the kernel, chances are the machine will still boot afterwards and give a no root fs kernel panic, that's because the kernel is still intact on disk and LILO just uses the physical location to load the kernel. If you use a bootloader like GRUB that understands filesystems that's not going to work.

better solution

[carpe_noctem]

mkdir ~/trash
alias rm="del"
echo "* 4 * 1 * /bin/rm -rf /home/*/trash" >> /etc/crontab

del:
#!/bin/sh
mv $* ~/trash /me nods

Re:better solution

[carpe_noctem]

doh that "/me nods" isn't part of the script. stupid /. formatting

Re:better solution

[Rogerborg]

Look great, but you step 1 could be improved: mount dossiere.nsa.gov:/home/$USER@$HOST ~/trash

Re:better solution

[gdchinacat]

I haven't tested this, but it looks as though the given cronjob will delete ~/trash, afterwhich the first rm command will move the file to the _file_ ~/trash, not the _directory_ trash. all subsequent ones will overwrite the previous file. modify like this if you want it to work:

echo "* 4 * 1 * /bin/rm -rf /home/*/trash/*" >> /etc/crontab

Re:Here's a Handy Hint

[Anonymous Coward]

Obviously someone wasn't around for the great RM stampede of 98...

Re:What a drag

[cpt kangarooski]

So you must never wear a seat belt either because you've never been in a fatal car accident.

Moron.

Its called backup

[jhines]

Don't delete anything, till it has been backed up. You do back up your data, right?

Re:Its called backup

[Kintanon]

Just want I need to do, spend 45 minutes getting the last backup tape (hopefully I didn't make any changes to the file that got toasted in the last few hours) then finding and restoring the file, instead of 45 seconds to pull it back out of the trashbucket and stick it back where it belongs.
Sounds REAL practical.

Kintanon

Undelete on linux isn't something new...

[tgd]

Back in like '94 a friend of mine in school wrote an Ext2 undelete program, which of course I no longer can find online... He doesn't have it listed on his webpage any more.

Re:One solution

[Mr_Silver]

Yep, I need 20Mb of Perl installation spread over 1194 files to do that. How elegant.

Oh god, that sound is the average IQ of this place dropping by another 10 points.

If Perl is already installed and being used, then the fact it's 1194 files is immaterial.

You could always use sh you know. Or bash, or PHP or even C. Or you as equally clueless which those as you are with your comments?

Complacency

[fishbowl]

Having your users accustomed to "undelete"
just makes it that much more harsh when they
learn that something delete from a remote filesystem is irretrievable. "Undelete" creates bad habits.

Re:Complacency

[Reziac]

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.

Re:Complacency

[Reziac]

Undelete doesn't save EVERYTHING, as a gunshy user will. (And if you support enough newbies, you WILL encounter this.)

Undelete only recovers what you ooops-omighod-I-didn't-mean-to-delete-that.

IOW, it's a difference in selectivity.

But I have one

[jdavidb]

I flipped over to another virtual desktop and found that GNOME has already provided me with a trashcan. (More like Mac than Windows.) I never use it, though.

If this is a trashcan for command-line rf, I can see how some people might want to use it. Not me, though.

Linux needs this at the filesystem level ... NOW

[krray]

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).

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 .XLS file). Excel says it's corrupt (it's a Word document now).

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.

Re:Here's a Handy Hint

[yelligsc]

Once upon a time I wanted to delete a couple stray mp3s I had in my home directory, so I issued the following command:

rm *.mp3

Or so I thought. I had actually accidently told my linux install to do the following in my ~/

rm * .mp3

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:What a pompus post...

[Capt_Troy]

Wow, you are so special and smart.

So what's wrong with providing a solution to those who want a trashcan? Maybe you are so much more experienced than most users (what 20 years of computer use? AMAZING!!!) but what's wrong with giving people an option?

You only "bastardize" it if you make it mandatory.

Re:What a drag

[interstellar_donkey]

I use pico. I think it's rad.

Possible solution.

[FreeLinux]

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.

Re:Possible solution.

[cpt kangarooski]

Well, who really cares if their computer is lightning fast if they have just lost hours and hours of work and will have to recreate it? There is a point where computers are fast enough, and we begin to consider issues of reliability. Which is what this is -- reliability from the perspective of a user. (since users generally don't know and don't care if magical pixies make their computer work so long as it DOES work)

We'll include efficiency as a factor in designing or implementing the sort of undelete system I have proposed. If handling this so degrades performance that a user will NOTICE (and we can have a combination of user testing to find a baseline and the individual computer using its spare cycles to determine where it's at) then we'll reduce the safety net a bit, or at least give the user the option to make the trade-off between stability and usability.

But I suspect that in the vast majority of cases we could do this and it would be no problem whatsoever. No one would notice the lowered performance since they weren't using it anyway.

As for the Unix philosophy, it's dog crap. Every user makes a mistake. You can be a brain surgeon and a rocket scientist but I guarantee that sooner or later you'll mistype an rm command.

Even expert users benefit from increased usability. If this were not the case, the so-called experts would be dicking around with switches on the front panels of their machines, entering raw binary. Even keyboards are there for enhanced usability. What so many people so sadly fail to notice is that the absolute number one goal should be usability. Without usability, nothing else matters.

Re:Possible solution.

[Loki_1929]

You run into several problems here. First of all, at the current state of computers, the bottleneck in most machines is the hard disk. What we're doing here is adding additional work for the hard disk, thereby slowing down the computer further. Secondly, by continuing to avoid overwriting data and allowing the drive to fill, you further decrease disk performance. Hard drives generally begin to work more slowly when they become more than half filled, with a more severe and noticeable performance hit at around 80% depending on the drive.

A more viable solution might be to take into account the above suggestions with the added idea of moving the data to the end of the drive during 'deletion' while still marking the space as available; albeit a new class of available which preserves data integrity based upon importance. This saves you from insane fragmentation and lower disk performance, and allows you to continue to maintain data integrity long after deletion. Two tables is again, twice the work, but a modified table which takes deleted information viability into account would certainly be useful. Issues such as security and performance are still in question, however, as well as how to implement such a table along-side existing file systems in such a way as to not break functionality or lose data. Backwards compatability and data security are probably the biggest issues, although preserving file permissions solves half of the security problem. Secure deletion must also be a choice for users eliminating sensitive data who don't want it recovered or viewed ever again.

Re:Possible solution.

[Suidae]

What we're doing here is adding additional work for the hard disk, thereby slowing down the computer further

As a user I don't push the drives hard enough to notice a difference. I'm not running a high traffic web server, I'm editing documents.

by continuing to avoid overwriting data and allowing the drive to fill, you further decrease disk performance. Hard drives generally begin to work more slowly when they become more than half filled, with a more severe and noticeable performance hit at around 80%

The drive doesn't give a damn what those bits are, it has no concept of full or empty, it just reads and writes where its told. Your filesystem may have issues when you hit 50-80% capacity, but that doesn't have anything to do with the drive.

One would want to be sure that the filesystem operated at acceptable speed with a large percentage of its capacity in use. Given the low number of file accesses (relative to a server system) of a typical desktop system, it shouldn't be a problem. The filesystem could even do low-priority background defrags, making sure it had its files arranged in the optimal order for the patters of use typical of desktop users.

Re:Possible solution.

[Loki_1929]

"As a user I don't push the drives hard enough to notice a difference. I'm not running a high traffic web server, I'm editing documents."

And that's fine, but don't assume that your particular usage is indicative of the vast majority of the masses. I do happen to use my hard drives, often pushing them to the point where the cpu is sitting at 20% waiting for the drive to feed it some data.

"The drive doesn't give a damn what those bits are, it has no concept of full or empty, it just reads and writes where its told. Your filesystem may have issues when you hit 50-80% capacity, but that doesn't have anything to do with the drive."

Well, if you'd like to get technical (as well as snitty), the drive has no "concept" of anything, as that would pre-suppose cognizance. In any event, if you look through any of a number of benchmarks (I personally like HDTach) which may either use a filesystem or not use one to do their work, you'll see that where you're reading/writing on the drive does have an effect on the performance. The filesystem generally cares only in that the fragmentation level tends to be higher at high disk usage, and it becomes increasingly difficult to defragment a drive as the free space dwindles.

I'm not sure what you'd like to call a "typical desktop system", but I can tell you that if you take two systems with identical specs except that one has a 2GB 5400RPM drive with 10MB free, and use it along side another with a 36GB Cheetah X15 with 35GB free space, you'll see a remarkable improvement in many fields, especially games, photo/video/sound editing software, and anything else that requires writes/reads from the hard disk and/or swap file. If you don't think that the performance difference matters most of the time, then I think you ought to send a resume to Redmond, WA, as I'm sure you're just the kind of person they're looking for there.

Re:Possible solution.

[Suidae]

I do happen to use my hard drives

Its not likely that you are a typical desktop user either. I'd venture a guess that you don't often delete things you didn't mean to either.

As is often the case with 'power users' the settings we prefer are not the same as what typical users perfer.

Personification aside, a system which maintains user deleted files (not necessarily all deleted files) does not have to take a large performance hit. Several obvious optimizations could be performed to minimize the impact deleted files would have, such as moving them to the slowest areas of the drive.

The system would obviously not perform as well as if it did not maintain deleted files (near capacity or not), if speed is your only measurement of performance. If thats all you are concerned with, simply adjust the settings to increase speed, or turn off the feature.

Re:Possible solution.

[Loki_1929]

"such as moving them to the slowest areas of the drive."

This is exactly what I was talking about doing. As far as speed, I think it's one thing to take into consideration amoung many other factors. While this would be a nice feature, it does no one any good if it kills drive performance, but I agree that the impact can be minimal so long as work is done on optimization. Of course, the optimal solution would be something hardware/firmware based on the drive itself which is able to work according to a standard so long as it's implimented by the file system as well. I also agree that this, like most features, should be made simple to enable/disable. I would probably use this feature, as I will once in a long while delete something I would rather not. Although it's never a system file, nor something I don't have backed up, it'd still be much more conventient to be able to recover it directly from the drive with a few keystrokes. Perhaps a file listing of each file, or even a simple GUI interface to browse deleted-but-recoverable files would be best, as to make the task of data recovery even easier.

Speed optimizations aside, one still must consider security and other things. At least part of the security issue could be addressed by preservation of file permissions, as well as the inclusion of some sort of shredder utility to completely destroy sensitive data (preferably with an option to do so to DoD standards - think it's something like 10 passes). A very simple encryption algorithm could further increase security with deleted data without a serious or noticeable performance hit. Obviously, the more work done, the more of a performance hit is taken, but so long as this is all fully configurable and is reasonably optimized, we shouldn't see any major problems. Instead of integrating this into a single file system, I would suggest an open standard which allows an add-on/upgrade to most widely used file systems. This both encourages the use of open standards, and allows for widescale adoption even at an early stage.

Re:What a drag

[British]

One of the more charming aspects of *nix is that it's designed by and for people who have a clue. The more you make it easy to use by the common user, the more it becomes bastardized.


Darn, the common person isn't allowed in the Linux treehouse!

Re:Run as root, and alias rm to mv

[cybermace5]

Yeah, that would about do it. In fact, that's a pretty simple and easy to set up idea.

Goes to show how easy it is to get anything you need out of Linux, just by thinking about it for a minute or two and never again afterward.

I'm Torn

[ReadParse]

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.

Having said that, even though I know how dumb it was, I once accidentally issued `rm -rf /bin`. Funny story, though:

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 /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.

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 /big` and immediately pressed return (I found that return is also a mysterious part of that autocompletion).

Just so you know, there are a great many important things in /bin. Among them, all of the shells, chmod/chown, grep, kill, ls (try working without that), mv.... the list goes on and on.

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

Re:I'm Torn

[ReadParse]

I swear I've never before replied twice to myself. But while I'm on the subject of stupid linux things I've done, have you ever wondered what happens when you accidentally put one too many asterisks at the beginning of a crontab line?

* * * * * * /do/stuff

instead of

* * * * * /do/stuff

Yes, it runs every executable in whatever the pwd is at the time, usually the home directory of the user for whom the cron job is running, providing the command that you meant to run as an argument to each of them. I was never so relieved that there were no executables under /root.

RP

Re:I'm Torn

[ReadParse]

Thanks, but 'echo' is also in /bin. For that matter, so it '*' :)

John

Re:I'm Torn

[alyandon]

Slightly less catastrophic, I'm editing the crontab on a Solaris box as root (production system).

I mean to type

crontab -e

unfortunately I have a typo and it comes out:

crontab -r

The aformentioned human autocompletion feature compels my right hand to pounce on the return key even though I'm blatantly staring at my mistake.

grrrrr.... it took 4 hours to get that one simple file restored from tape backup and that meant 4 missed cycles of accounting processes that run hourly. Fortunately, the processes aren't time sensitive -- they just run longer if they haven't been run in a while.

Needless to say, the joke around the office for the next few days was something along the lines of "But I thought 'e' meant ERASE and 'r' meant REVISE!". [/bad *nix joke]

Re:Here's a Handy Hint

[garcia]

really? That's you. That's not the majority of people out there. Some people really want this. Especially the people that feel that Linux should become part of the desktop market.

I don't see how people could believe that your post was "Insightful". It's not Insightful it's trash (no pun intended).

This is something that would make Linux *more* attractive to Joe-Blow. Come on.

Dammit!

[ReadParse]

Hate it when a funny story is screwed up by a blatant typo:

"you shouldn't run as root AND use rm -rf and THEN decide that you shouldn't have done that."

Sorry.

partly real

[Transient0]

17+2i

Real-life Analogy

[LPetrazickis]

Often, when I clean out my papers, binders, and whatnot, I end up throwing out stuff that I do need. Being able to root through the trash and retrieve it five minutes later when I come to my senses is very convenient.

Yeah, yeah. I am not leet.:)

Novell had this...

[deander2]

Novell Netware's FS worked almost exactly like this. It was a wonderful feature. I don't understand why more implementations have taken this into consideration...

Grot!

[Nick Driver]

So If Apple has legal rights to "Trash Can" and MS has "Recycle Bin" I think we should call it the "Grot Shop", as our repository for rubbish... in honor of Reginald Perrin.

I always did like the way the Brits commonly use the term "rubbish" for trash. It's got a classier sound to it.

safedelete

[oneeyedman]

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!

Er, no.

[Nailer]

Your app doesn't intercept the unlink system call. it intercepts GNU `rm'. Most applications don't use GNU rm to delete files.

Re:Er, no.

[Nailer]

We're not talking about applications, we're talking about users deleting files.

...which they do with applications, whether bash, OpenOfffice, Konqueror, or whatever else. The advantage over desktop environment specific trashcans is that libtrash works transparently to most applications and this can be easily supported by them all. You just have to make a tashcan icon and point it at the right directory.

Re:Er, no.

[Nailer]

If an application other than rm or a file manager is calling unlink() then it probably has a good reason for doing it, and you don't want the files in a Trashcan anyway

Well, I might delete the old SXW of my document after I save the MS Word version to submit to an editor in OpenOffice.

The exceptions, like Mozilla, can easily be taken care of too.

Re:What a drag

[interstellar_donkey]

Ok

You really can stop replying to this thread.

Really.

You might even try to do the really insane idea of instead of replying to this and telling me I'm wrong/I'm an idiot, you could start a new message and tell the world why linux needs an undelete.

Really.

Telling people why you're right is a heck of a lot more effective then telling me that I'm wrong.

Another list

[Arker]

[x] Trashcan support
[X] Easy to use Windowing system - WindowMaker - quietly delivering the usability other noisier projects only aspire to for years.
[X] Standard software install system - *cough* it says *standard* - Tarballs
[X] Easy to use Windows filesharing - KDE, Samba
[X] Easy support for video files and DVD - see http://mplayerhq.hu/
[X] Desktop company support - Legions of answers here, a competitive marketplace is good for the consumer.

Re:Here's a Handy Hint

[jxs2151]

Don't Delete Shit You Want to Keep!

Is it that hard?

And this my friends is the attitude keeping Linux from wider acceptance......

No, I don't.

[Rui del-Negro]

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
~~~

Re:No, I don't.

[ncc74656]

If this kind of "commodity" seems pointless to you, then you probably program by writing machine code with a text editor. ;-)

Real men use cat > /usr/bin/foo << "EOF" to enter their programs. :-)

Re:No, I don't.

[Bishop923]

Bullshit, REAL men remove the platter from their HDD and manipulate the sectors manually.

Bah to you simpletons with your "keyboards". :-)

Re:No, I don't.

[Lemmy Caution]

Real men have their overweight paid IT monkeys and clerical flunkies do all that crap while they go have sex with starlets and supermodels on their Surface-to-Air-Missle equipped luxury hover-yachts.

Damn, don't you learn anything from the movies?

Re:What a drag

[crimoid]

>> 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.

Re:Not a solution- a landfill!

[Lumpy]

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!

Re:Run as root, and alias rm to mv

[sisukapalli1]

This is what happenned to me when I tried aliasing rm ...

First, I aliased rm to "myrm" where myrm would put the files/directories inside ~/tmp/trash

If I wanted to really delete a large file I'd use \rm largefile.out (in bash, \ is for the real rm), and soon, instead of rm, I started using \rm. Meanwhile, my labmates used the alias and filled the entire disk with ~/tmp/trash files (nested directories, large files -- several versions, and so on).

S

Change User Profile

[$nyper]

Actually I have been doing this for several years as an admininistrator and developer on a UNIX box. This software appears similar to what I have done for my users and myself which is rewrite the "rm" command in the users profile. All users including myself have had the rm command supplimented to mean "mv [file] /home/$USER/garbage."

I then have a cron job that runs to evaluate the age of the files in the garbage directory. It will automatically clean the garbage directories of all files that are older than 14 days. The cron job currently runs once a day.

By the way I even caught I a guy that one of the companies I worked for hired to do an attack and penetration test because of this little fact. He set a job to run after he logged out to clean and clear out the general and host specific log files. He did not account for the fact that I change the rm command's meaning. I found his file lingering in the garbage directory of a temp account. HEHE... gotta love UNIX. :) Oh, by the way this has been a stable release for about 8 years now or since I first learned it could be done. I have had 100% success with no failures. :)

Re:One solution

[chegosaurus]

The point I was making, for the benefit of those who couldn't quite grasp it, was that loading into memory a great big executable, with however many shared libraries and other dependent files perl requires, is overkill. A one line shell function in everyone's .profile will do the exact same job.

So many people, especially here on /. want to show off their leet coding skillz and solve every problem with Perl, when it so often isn't the right solution.

Get that? Or are you equally clueless at understanding follow-up posts as you are the originals?

Re:What a drag

[kubrick]

I have been using computers for over 20 years. I have never, ever, ever 'accidently' deleted an important file.

Unfortunately, not everyone shares your fine mental and physical coordination. Who should we be designing for -- the exceptional people such as yourself, or the lumpenuser who, on making a mistake, would like some way to easily recover it? How many more are there of them than there are of fine specimens such as yourself? Couldn't you just grit your teeth while you disable this unnecessary feature, secure in the knowledge that your momentary sacrifice has enlightened the lives of millions less fortunate than yourself?

Re:What a drag

[jcoy42]

So you must never wear a seat belt either because you've never been in a fatal car accident.

It's more like not wearing a seatbelt while playing GTA3.

It's not like you actually *die* if you lose your files. It just sucks because you have to start over.

What we need is more than a trashcan

[Ektanoor]

Personally I don't have a big need for a trashcan. And most *NIX vets barely need it. Only the masses may have need for such stuff, specially when so many Windows users are coming up. However I would damnly congratulate the nerd who would put in default such a feature on the next distro. Every experienced hacker knows perfectly that trashcan solutions are frequently THE reason for loosing performance. For individual removals this may look no so critical but when things come up into whole folders and thousands of files, we get some trouble.

Anyway a save removal system should be potentially in place over every file system. Moreover, this safety mechanism should be inherent to the filesystem itself. With the chance to choose what I want to safeprotect or not. Under such approach we could meet a middleterm between performance and safety. Besides such approach would allow to cover a problem where most backup systems can't have a voice - safeguarding highly critical data in a more realtime basis. Yes, such safeguarding mechanisms will not be good for the real realtime situations. But they would be quite good for protecting and recovering by-hour or by-minutes cases. Sometimes this is much more important, rather than picking up last-day's archive and forcing the user to type his last hours of work at the end of worktime and having the boss yelling "I want it now!!!".

If such mechanisms would be implemented they could find a very important niche among sysadmins working with certain types of information - document files, legacy databases, big amounts of data and so on. However such mechanism should regard some safety concerns of confidentiality and control. I fear that in lamers hands it would be much preferable to see the old damn Recycle Bin in their hands.

Re:What a pompus post...

[liquidsin]

So, um, what if you like to get under the hood and accidentally delete a file? Why is it so horrible to give users a choice to have a trash can if they want it? I realize that at only 23 I don't have the wisdom of your 20 years of computing, but I've been on linux since a friend turned me onto it at 15 and I know there are times I would have liked to be able to undelete. And why does it matter to me if you're uncomfortable with my having a utility you don't like? And why do you perceive this as Windows-like? If you want to do everything from a command line and be uber-l337, be my guest, but don't tell me what I should and shouldn't do on my computer. Communist.

The TCT

[schlach]

I can't believe no one's mentioned The Coroner's Toolkit. Written by Dan Farmer and Wietse Venema, those crazy kids that wrote SATAN, back in the day. It has all kinds of fun tools for poking around backstage on a *nix box, ostensibly forensics-related work after a machine compromise, but if you accidentally delete something important, you could pretend that someone else broke in and did it. =)

From the FAQ:

What the hell is it? The Coroner's Toolkit (TCT) is a collection of tools designed to assist in a forensic examination of a computer. It is primarily designed for Unix systems, but it can [do] some small amount of data collection & analysis from non-Unix disks/media.

Features: Notable TCT components are the grave-robber tool that captures information, the ils and mactime tools that display access patterns of files dead or alive, the unrm and lazarus tools that recover deleted files, and the findkey tool that recovers cryptographic keys from a running process or from files.

"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...

Re:The TCT

[Ektanoor]

When I was writing my comment on this post I thought about this tool and alikes. And considered that this is not a solution. Forensic data recovery is an important part of security analysis, however, this is not exactly what we need to protect data. This branch of forensics deals mostly with intentionally deleted data, temporary data and historical data. It could be used for data recovery also, but, it is and should not be its main intent. All the tasks, that forensic data recovery deals with, are already complex enough for its developers. This is a field filesystem developers should consider. Due to the embroglios of the infrastructure each filesystem has, the ideology of data protection should be a question on the creation of every filesystem.

One should note that it should not be obligatory for every filesystem to carry a data protection/recovery mechanism. Sincerly I prefer XFS and ReiserFS 3 to lack such mechanism, rather than seeing the pains of having a slow performance for the price of a dubious "feature". It is understandable to see the developers of these systems to refuse the creation of a data protection system. Yet, it is a pitty that developers didn't seem to even have tried to implement it. Only ext2 guys seem to have tried to explore the correct region of data protection. The ideology inherent to the undelete mechanism on ext2 is much better than a simple "trashcan"-alike tool. At least, it goes inherent to the architecture and has a safety choice option for each file. Unfortunately, it is not perfect and it seems that developers forgot the good idea it was. This is still a wide unexplored forest.

In other point, I should note that TCT is not a perfect idea because of the fact that stays over the surface of most filesystems. The unrm util can hold only ext2 filesystem. However many people today use XFS or ReiserFS due to performance.

Re:One solution

[Mr_Silver]

The point I was making, for the benefit of those who couldn't quite grasp it, was that loading into memory a great big executable, with however many shared libraries and other dependent files perl requires, is overkill. A one line shell function in everyone's .profile will do the exact same job.

Except that you didn't say any of that.

So many people, especially here on /. want to show off their leet coding skillz and solve every problem with Perl, when it so often isn't the right solution.

You should try reading Slashdot a little more than once a month.

Actually most people want to show off their 1337 coding skills by reinventing the wheel when something is out there that does the job just fine.

Get that? Or are you equally clueless at understanding follow-up posts as you are the originals?

I understood it just fine, hence my comment about using something else. Which you quite obviously missed.

Good luck with the reading and clear writing course. Looks like you need it.

I don't think this is the right solution...

[Ender Ryan]

I don't think this is the proper solution. There are a lot of programs that create temp files and unlink them, so something like this is going to really clutter up a filesystem really quick.

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.

Re:I don't think this is the right solution...

[Suidae]

The obvious answer is to do what Microsoft did. Provide from the file system two ways to delete files. One sends files to the trash, one really deletes them. Files deleted by the user go to the trash, unless the user really deletes them (ie, hold down shift and delete in Exploder), files deleted by the system are really deleted.

As long as recycle bins/trash cans have been around this seems like it should be a solved problem.

Re:Linux needs this at the filesystem level ... NO

[Planesdragon]

Getting the inserted table [spreadsheet] from Word back into Excel was next to impossible.

Hardly.

Step 1: Select table in Word
Step 2: Copy table to clipboard
Step 3: Open new Excel Spreadsheet
Step 4: Paste table back into Excel
Sept 5: Give original user license to beat the clueless person who messed up his/her spreadsheet.

Potential gotcha

[lpontiac]

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`

The only us I see...

[CAIMLAS]

The only use I see for something like this is one abstraction layer from major GUI toolkits like GTK and QT. I say this because the only times I have problems such as accidentally deleting a file are when I'm using a GUI, and decide to use menu options (such as in GQview). If I'm looking at some photos that were emailed to me, and I want to move them, what if I accidentally click the 'delete' option, which is right next to it? Those files are lost.

I -can- see the use for it, but I don't really see any reason why it should be one level below console (which is what I'm assuming this library does). Granted, there are times that I would have found it useful, even a life saver, but that was due to my carelessness. People really shouldn't be allowed to be careless with computers.

Its been done...

[mengel]

You guys should really look at the old Purdue file entombing code, which these days lives here.

It is a really efficient way to do this. It was initially done, I think, in 1984 or 1985...

I think the code that's there is for BSD 4.3, but if you've already done the library work...

The overview reads:

This is the Purdue/ksb entombing system. Files removed by programs
linked with "libtomb" are cached for a while (long enough to get on a
backup tape would be best case) in case their untimely loss is noticed.

The 3 programs are "unrm" (the user agent to get files back), "entomb"
the system agent to cache a file, and "preend" (the system agent to
clean the older files from the tombs.

Included as nifty side products are "rmfile" which helps novice users
delete files with funny names (like "-") and "untmp" which should be
used to clean /tmp from a ".logout" type file from casual users.

Currently Andrew J. Korty is working on a project to port the code to current FreeBSD.

Re:Its been done...

[per unit analyzer]

As an (un)interesting side note, undelete was done two different ways at Purdue until the mid '90s. The entomb system was written by the Computing Center folks IIRC. Over at the Engineering Computer Network (ECN), we had /zap. Any file you removed with rm was copied to the/zap/login (where login was the user's login) directory before complete removal. Every night a cron job would clean everything out of /zap that was more than 24 hours old. Unfortunately /zap wasn't as advanced as entomb and fat-fingered cp and mv mistakes were not recoverable. The folks at ECN (ghg, davy, jrs, et al) had only modified rm but they did not create a comprehensive library to link against. I believe ECN switched from /zap to entomb when they moved from SunOS to Solaris. One thing I can't recall was whether entomb could help you recover from using > instead of >>... (That was one I dealt with a lot as a site consultant...) Does anyone remember?

--zawada

Re:Wake-up call

[quakeroatz]

No, just another thing you guys like to take credit for thinking up, even though you didn't. You know, like hockey.

Ahhh! I see you're just looking for a ol' Canada vs. US flamewar.

A few notes:
- I've never heard a Canadian say we invented Hockey, we didn't. But we do whip your ass handily at it! I can also gaurantee that your local NHL hockey team is infested with Canucks.
- Basketball yes we invented that and reigned during the early years of pro ball (yes, a long, long time ago). But! the Raptors are looking excellent this year, and we aren't missing our 4 top guys this time (cough).

Wow

[waldoj]

So, what happens if for some reason the feds (or some other unscrupulous organization) siezes your hard drive and digs up everything you've deleted for the past 6 1/2 years?

Then be sure to let me know about it, because that's one bad-ass unerase utility right there.

-Waldo Jaquith

Fatal?

[waldoj]

So you must never wear a seat belt either because you've never been in a fatal car accident.

Nobody that's been in a fatal car accident wears a seatbelt, either.

-Waldo Jaquith

Basically I agree and believe you deserve the mods

[kfg]

But, I'll point out that deleting the wrong JPEG can certainly break apps that haven't had their error handling written properly. The difference is you and I know how to recover and replace that JPEG even if it has truely been nuked from our systems. Not everyone does. I'd say that's the "comfort difference" between us and "Joe-user."

I'd also point out that moving a file to a tmp folder is *using a trashcan/recycle bin,* you just don't think of it that way. . . and neither does Joe-user, which I guess is half the point. When I first booted up Linux and realized, " Ah, no trashcan," it took nearly a whole second to think, " Well, if I want one all I have to do is make a directory named 'My Trashcan like Place' ( or George, or whatever)and alias rm to mv foo George." But then I wasn't your typical newbie.

Ok, to make it a full blown trashcan some sort of simple database to track where each file came from to effect automatic restores is also needed for Joe-user ( renaming it foo./bar/fred/barney works for me on those rare occasions when I think this is necessary), but the basic idea is simple and to me was obvious and trivial to effect. I guess to Joe-user it isn't.

But as you say, if it isn't the default behaviour, and needn't even be installed on *your* machine, who gives a damn? Are we going to start sending out " You moved that file to a tmp folder instead of deleting it" police?

Any controversy over this is just plain silly.

KFG

Re:undelete or a trash can?

[Etcetera]

In real life we toss things in the trash and the sanitation dept picks it up. If we threw out something we needed most of us just ACCEPT that its gone. We don't go digging through the local landfill.

Yes, that's why it's called the Trash Can or Wastebasket (or Recycle Bin if you think MS invented the Desktop interface). The point is that this is a place files go *before* they're picked up by the sanitation department and lost forever. Are you saying you've never tossed a paper into a basket by your desk only to take a second look at it 10 minutes later?

Also, it's worth pointing out that the original Desktop interface (Mac's System 6 and earlier), the contents of the Trash only survived until you launched the next app or rebooted (except for Multifinder). Once you put a file in there, it was on its death nell. Different from System 7+ and MS Windows where files stay in the Trash/Recycle Bin indefinitely until you manually Empty (the) Trash.

Re:What a drag

[cpt kangarooski]

This is not always true. Imagine having a piece of medical hardware that's computer controlled. Or imagine skimping on simulating the design of a building due to lost files, where the building eventually collapses.

Of course, we don't even NEED such extreme examples. If I'm working on a project and I lose my work then that's already bad enough to justify such features! Don't people claim that one of the virtues of Unix is its uptime? Well, if crashing is not a big deal because it only takes a few minutes to reboot, why all the big deal?

Peoples' work isn't a video game. It is often serious enough to them to require GREAT care on the part of developers to keep them happy.

Why?

[Suppafly]

I'm sure everyone else is going to be asking the same thing, but why do you need a cmd line trash. The 'normal' user who doesn't understand that when you delete something it goes away forever isn't going to be using the cmd line, they are going to be using x-windows, most likely in the gnome or kde flavor. Its pretty easy to make a folder named "trash" for them to drag stuff into if they don't want to delete it.

So fucking what?

[Hektor_Troy]

If I decide to go drag racing in my brand new Cobra 2003 and total it, is it the fault of the manufacturer or the fault of me?

What if I don't have a drivers license?

Why the fuck should YOU care, if I fubar any of my own stuff? As long as I don't hurt anyone - who the fuck cares?

Re:What a pompus post...

[Capt_Troy]

So in othe words...

If Microsoft develops a concept (or Apple in this case I guess) that might be useful to Linux users, we shouldn't develop something similar because instead we should just buy Windows? That is just plain stupid.

Linux is nothing like Windows and it will never be. But there is nothing wrong with adding functionality that people will find useful, although, I can't see why one wouldn't just make an alias to do this instead as another poster mentioned...

Wake up *yourself*

[0x0d0a]

Slashdot has had major software announcements for a long time. The idea is to provide an interesting medly of content that keeps nerds happy. When PHP forum bugfix notifications start coming up on Slashdot, then you can complain

There's been a lot of discussion about having a form of undelete in Linux on Slashdot. This is quite relevant.

Simpler solution

[anonymous_wombat]

Here is a much simpler solution, which I put into the public domain:

cd /; chmod -R 444 *

Seriously, why does anyone need a trash bin? Disk capacity is so ridiculously large that there is no need to ever delete anything. If you need to reorganize, make directories like oldjob, oldstuff, etc and just move the stuff into there and forget about it. It works just like a trash bin, except that you don't need to worry that the stupid machine will empty it.

So?

[0x0d0a]

The Mac OS had a Trash Can from its introduct in '84. I believe that the Apple IIgs shipped with an OS with a Trash Can, and it wouldn't surprise me if the Lisa did the same.

RM protection in 5 characters :\-i

[drwho]

:>\-i yes it looks like line noise or an emoticon, but it's really a shell script. This protects against rm *.

so cd to all of your really important directories (/, /etc, /bin), and type :>\-i

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.

atimes make a Linux box stogy

[0x0d0a]

I always mount with noatime. Nothing I hate worse than constant background writing on my hard drive.

Re:atimes make a Linux box stogy

[CoolVibe]

*Yawn*, real men always mount everything async. Your files won't be the same until you do. Performance will be better though...

:)

Re:atimes make a Linux box stogy

[0x0d0a]

Normally, Linux mounts its filesystems with atimes on. Each file has a timestamp recording the last time the file was accessed.

If you drop in noatime into /etc/fstab, this behavior is disabled.

Some people *really* like this behavior -- it lets you keep track of which files aren't used much.

I really *don't* like this behavior. Some utilities, like tail, keep polling a file and updating its atime, so the Linux box keeps writing to the disk every couple of seconds (obviously, tuneable via the VM settings, but I *like* flushing my buffers each few seconds). In a quiet room, this is really annoying. Also, I rarely care about atimes, because I frequently do find -type f |xargs grep operations that cover large chunks of my disk and set the atimes on everything to the current time -- I'm more interested in "last modified" times.

It doesn't actually slow down the box that much (well, I haven't actually benchmarked it, but I suspect that it isn't that bad, even if you did something like find -type f |xargs file, which is about the worst thing I can think of. But it produces extra traffic to the disk that doesn't do me any good.

Mplayer is nice

[0x0d0a]

mplayer is a bitch to install, but awfully simple to use once it's in. And in terms of performance and flexibility, it can't be beat.

You set it up

[0x0d0a]

And what percentage of "normal users" install their own software instead of getting someone else to do it for them on Windows?

Fragmentation.

[0x0d0a]

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.

Re:Fragmentation.

[Suidae]

The proposed solution, at least without serious modification, would massively fragment the hard drive

Not true. The files marked as deleted are still real files and available for the file system to move around to minimize fragmentation. They just aren't displayed to users, and can potentially be overwritten when more space is required.

Re:Fragmentation.

[FreeLinux]

I disagree. First, I'd rather see this implemented in ext3 than ext2 for the obvious journaling benefits. Also, I deffinitely do not feel that a performance hit would be noticable. The Novell file system is still BLAZING fast dispite the fact that it is managing hundreds of thousands of deleted files.

The thing is though, that if you have the file system relying on table two but, the user or the applications are only presented with the contents of table one then, the existing benefits of the file system are not impacted. The fragmentation issues would not change as the file system would still control fragmentation, as it does today. That's specifically why I would recommend two file tables rather than simply setting a couple of extra flags in the existing single file table. But, even then it could be done, I just think that a single file table solution would require more computation with every disk access versus the two table method which would use the second table only during writes, deletes, undeletes etc.

Furthermore, security would also be handled since the rights would still be maintained in the lower level table two. The only real difference would be that files marked for deletion would disappear from table one and have an additional flag set in table two. I don't feel that deleting an entry form table one and then setting a single bit in table two would impact performance very much.

Additionally, the question of security with regards to complete deletion would be no worse than today. Using ext2 or ext3 it is not possible to guarantee complete deletion and overwiting of the physical disk. But with the system that I suggest, this would remain the same that it is in ext2/3. As far as the ability to make deleted files undeletable, this can be done with a Purge utility that goes through table two and removes entries with the deletion flag set. This is again the same behavior exhibited in Novell's Salvage solution.

With this method, the only tools that might get broken would be a few that manipulate the file system at very low levels. But, this is the case with almost any different file system. Disk tools that work with ext2 do not work with Rieser unless they are modified to accomodate Rieser. fsck.ext2 isn't any use with Rieser, for that you use fsck.rieser. But, the solution would be completely transparent to all other applications including the likes of rm, mv, unlink() and everything else since these applications and functions would only see table one and all of the table two stuff would be handled by the filesystem itself. I propose ext4.

Re:Fragmentation.

[0x0d0a]

The "twin file tables system", as far as I can tell, used a minimal-overwite algorithm -- overwrite absolutely no more files than is necessary.

That's expensive. That *will* fragment files badly.

Now, say you propose defragging on the fly. If you have a fragmented series of files, you have to defrag on the fly while doing writes. Plus, your disk is essentially always 100% full, *and* to make this a sane system, all of your operations have to be atomic. This is a worst-case scenerio for defragmentation. If you've ever tried defragging a full FAT32 filesystem, you know what I'm talking about.

So what *used* to be slapping a chunk of data down onto a disk now becomes a number of moves of data to defragment files, plus your initial write. These defragmentation moves need to be atomic, so you need to be writing some other metadata on the disk. Not only that, we're doing *far* more seeking. Seeking is mind-blowingly expensive compared to writing that chunk of data from before, and the fact that we have to flush the buffers frequently to keep things atomic means that we can't combine as many writes, which means worse seeking.

Without a real world implementation with numbers, it's hard to show you how bad this would be, but every filesystem I've ever used would be far, far, far faster than this.

Re:Fragmentation.

[0x0d0a]

ARRRRRGGGGHHHH!

I'd rather see this implemented in ext3 than ext2 for the obvious journalling benefits

Okay. First, implementing this in ext3 would be almost meaningless. The entire point of journalling is that you always write *forward* on the disk, and update pointers to the newest data. Your writes are nearly always contiguous in ext3. This system, where you have to overwrite positions containing deleted files, would have to dance from location to location on the disk to write a file. Very expensive. You could make an atomic writes filesystem, but it probably wouldn't be smart to make it journalling.

Also, I definitely do not feel that a performance hit would be noticeable. The Novell file system is still BLAZING fast despite the fact taht it is managing hundreds of thousands of deleted files

The number of deleted files isn't the issue -- it's how much free space you have available. I can assure you that the Novell guys aren't taking your approach -- only overwriting something when they absolutely have to do so.

The filesystem would still control fragmentation, just as it does today.

What impact does this have on performance? If you're thinking that ext2 does background defragmentation, it doesn't.

The fragmentation issues stem entirely from the lack of free space -- the file system always has an extremely small amount of free space. That free space is likely scattered around the disk.

I'm not sure of all the ways that ext2 differs from vanilla UFS, but I strongly suspect that ext2 does not have a distinct allocated block list. In any event, a one-table or two-table question really isn't an issue.

Finally, let me reiterate: FREE SPACE. Between about 80% or 90% full, ext2/3 filesystem performance starts to take a nasty hit from fragmentation. If your filesystem is 99% full, you're going to be getting quite fragmented. If you are using the proposed system, you always have just a few killobytes of free space (the space left over in what used to be the oldest deleted file).

Re:Fragmentation.

[Suidae]

If you take the approach of maintaning files as long as possible, performance not withstanding, yes, you end up operating at 100% capacity. To make it practical you'd want to give the filesystems some space to work effectively.

I've never written a defrag, but it seems that given a journaling file system and plenty of time to calculate optimal block movements it shouldn't be particularly difficult or dangerous.

Naturally any scheme like this would become less effective (ie, shorter history) the closer the drive was to filled.

Re:One solution

[chegosaurus]

> You should try reading Slashdot a little more than once a month.

I would, but things like this always end up driving me away.

To summarise: the original poster says he'd write something in Perl that would move things to a trash directory rather than removing them.

I point out, admittedly in a childishly sarcastic (but hey, remember where we are) way. that that's using a sledgehammer to crack a walnut.

You point out, in a condescending, superior (but hey, remember where we are) way, exactly the same thing.

I repeat what I just said.

You repeat what you just said.

Someone else chips in having completely misunderstood what we've both said.

The internet is *even more* full of pointless crap than when we started.

So, for what it's worth to move instead of removing, for my ksh user's I'd have an alias to a function calling mv, and in csh and derivatives, just an alias. We agree?

The difference is...

[budalite]

Most of these people (above/below) are not asking for a "trash can". (Tho' kudos to the guy for making it -- another choice.) These people are asking for archive capabilities. (Even *indows archives older, less-used files. Ever notice the little blue files? ) If you are afraid you might need something later on, write it to a CD instead of deleting it. (or have a cron do it by date of the file or something.) This is not so complex. What am I missing here? (I really used to like the way Novell archived your servers by the date of the files.)

Dad32

whatever.

Why not do it for real?

[Salamander]

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.

Two things.

[neo]

1. It's very likely that whatever the undelete command was, that it would have been in the bin as well. It's unlikely that you've be able to run it from the trashcan and unlikely you could have gotten to it without the contents of /bin.

2. Undelete is not for 'rm -rf'. It's for deleting a copy of that invoice/letter/utility you know you'll never need again, only to get a phone call ten minutes later.

Re:Smug Linux users - don't you just hate them?

[tomhudson]

No, but after a couple of decades you learn to back up your important stuff before leaving the office for the day ... 'cause, after all, between the human failures, the software failures, and the hardware failures, you can't have too many backups.

Re:Here's a Handy Hint

[russellh]

That's why you use the old trick of having a file named something like "-normstar" (or anything that begins with '-' and which isn't an rm option). rm chokes on it as it scans argv[] for options, and won't delete your files.

just don't have a file named -rf

RPM is a mess.

[bcrowell]

The problem is that RPM is a mess. You see web sites saying "Here's the RPM for Red Hat. Also, here's this RPM for Mandrake, but it's out of date," etc.

There's also the whole problem of library incompatibilities, which is part and parcel of the decision to make shared libraries the standard way for software to work on Linux. That's a classic example of reducing ease of use in return for better performance (smaller downloads) for more sophisticated users.

Re:Wake-up call

[schon]

How about STOP deleting sh!t you don't want to delete?

OK, what about software that deletes stuff you wanted?

I downloaded an MS update once, and it asked where to store it, so I put it on a directory on my server (running Linux), where I put all of my downloaded files.

So as soon as it downloads, it runs, and after installing (I got no warning that it would do any of this) presents the dialog box "Would you like to delete temporary files used during the install process" - so (naturally) I say YES (since it put the damn files in the folder, and it should know which files it created.) It then proceeds to delete the entire damn folder, including all of my other files, which it DIDN'T install, and which I wanted to keep.

Windows installer is fatally flawed + Tangent

[ivan256]

Tanget first: The thing that pisses me off the most about windows installers is that they insist on going full screen and requiring you to close or ignore background applications while they are running. I don't want my machine to be useless during an install. Let me start the installer and then do something else while it's doing whatever rediculous crap installers have to do on windows.

One good thing about Windows Installer is that the install is an atomic procedure. That is, if it fails for any reason (file missing, user cancel, etc.), then it will completely roll-back and not leave bits of a partially installed application.

I call bullshit. First, if the installer crashes the system then you're still left with a mess, so it's hardly an atomic process; It only appears atomic if it ends cleanly. Everything else you're describing is handled by any decent installer (including RPM, and dpkg), so it's not something that is nice about the MS installer in particular. Worse, Windows doesn't properly handle unused shared libraries when handling dependancies. Since they are part of an application package they can't be easily uninstalled seperate from the application, but the default behavior is to not delete libraries marked as shared even if their usage count is zero. You need to pick one or the other: delete the libraries when no one needs them anymore, or package them seperately so that they can be cleanly uninstalled. This is one of the most broken parts of Windows.

My point is, is that while it's possible to use different front-end installers, they all use the same back-end, unlike the different Linux package systems.

Each distribution has it's own package management system. On a particular distribution, there is a common installation back-end that is for managing uninstaller applications (usually scripts since administrative tasks are easily scriptable on linux, unlike windows) and dependancies. Stop trying to spew FUD. It's a moot point anyway, because a typical linux distribution is not hampered by a monolithic configuration database, so there is no need or benifit to a unified installer backend in the form you're describing about windows.

Purdue has had unrm for years and years

[bee]

Purdue had an unrm package when I was a sysadmin there in 1995, and it was old then. It worked by having a new unlink() that could then be merged in with libc (if you were brave) or linked to separately so you could have /usr/local/bin/rm instead (if you weren't), along with tools that understood how to read the filesystem tomb and restore files from it, and a daemon (preend) that cleaned the tombs of old files. Unfortunately, it has never been extremely portable, since it involves rewriting unlink(). It had pretty much everything you could want in an entombing package; but I don't know if anyone has picked up the ball with it. Last I heard they were having trouble porting it to the newer versions of FreeBSD; check out this note from Purdue ECN.

A spec for how to do it right

[steveha]

I'd like to see support for this in the kernel. What I want is to see all the functionality of the Norton Protected Recycle Bin (NPRB), which you get with Norton Utilities under Windows.

When you remove a file, from anywhere, it is saved. This means Nautilus, shell prompt, FTP client, whatever. (Tricks involving editing .bashrc need not apply.)

When you overwrite a file, it is still saved. This means if you save a huge edit to a file and then regret it, you can recover the previous version. If I am not mistaken, libtrash does not handle this case.

You can specify some files/directories to not be backed-up. NPRB allows you to specify wildcard patterns, such as "C:\Temp\*" (anything in C:\Temp) or "*.bak" (any file ending in .bak). I like the wildcard feature for "*.bak" and such, but I would also like to see this new kernel feature do the right thing with the "chattr +u" flag, which Linux has had forever but doesn't acutually do anything.

You specify an automatic date for the backups to be purged: e.g., anything older than 3 days old gets purged. A user-space utility running on a cron job would handle this nicely.

There should be user-space utilities that allow for recovering a deleted file (to original location or to someone else), and for purging all the kept files to truly get the space back. (And I want a nice Nautilus interface for this stuff.)

When you are up against the wall on disk space, the oldest files get purged automatically to make enough room for a file write. (This one would be nice but I could live without it.)

This would be nice on servers, but I also want it on the workstation!

NPRB is the one big feature available in Windows that I really wish for in Linux.

steveha

Re:A spec for how to do it right

[steveha]

The norton protected recycle bin really does nothing but take advantage of a few (mis)features of the FAT file system.

You are mistaken. Perhaps you are thinking of the Norton "Undelete" program, not the Norton Protected Recycle Bin.

Undelete does take advantage of the way the FAT filesystem deletes files. (However, it also takes advantage of the "image" files written by the Norton Disk Image program, which are basically copies of the FAT written to known locations on the disk. If you have been imaging your disk, your odds of a successful undelete improve.)

If this works on NTFS too, then they are actually doing something new

It does work on NTFS.

NPRB works by intercepting disk writes that would delete or overwrite files, and then backing up the original file.

If you edit a file and then hit save, and do it again three more times, then when you check the NPRB recovery you will see four versions of the file that you can recover--one for each save.

steveha

Snap filesystem?

[steveha]

A couple of years ago I heard about something called the "snap filesystem" which would allow for recovering deleted or overwritten files. But I haven't heard of it since, or seen anything on the web. Does anyone know anything about a "snap filesystem"?

steveha

Snapshots (with LVM)

[steveha]

If you set up your system with LVM, you can use LVM's "snapshots" feature. Each snapshot is a virtual copy of the entire file system, as it existed when the snapshot is taken.

This is primarily intended for backups of volatile filesystems, such as databases. You would backup a database like this:

suspend database transactions

wait for pending transactions to finish (so database indexes are consistent)

make a snapshot

resume database transactions

backup the snapshot

remove the snapshot

But if you have a lot of free disk space, you could set up your system to make a snapshot every hour, and keep the snapshot for, say, 8 hours. Then you would have a coarse-grained undelete.

If your shapshots happen on the hour (1:00, 2:00, 3:00 and so on) and the user creates a file at 1:02 and deletes it at 1:40, the snapshot won't help, which is why I call it coarse-grained. But if you accidentally do "rm * .mp3" in your home directory, the snapshot would be a huge help. You would get back everything over an hour old.

It is specifically for snapshots that I plan to try out LVM on my next file server.

steveha

Re:Linux needs this at the filesystem level ... NO

[ashitaka]

Absolutely.

It doesn't happen often but when a user saved over an older version of a document in our DMS (iManage) we could count on Salvage to get it (or any other previous version) back.

Having migrated to Samba on Linux for File/Print we now have to resort to tape.

Relax. Say "Uhhmmmmm"

[FreeLinux]

I'm not trying to frustrate you. I see where you are coming from on the fragmentation issue and I see where this might be a problem in some cases.

Frankly I want this feature more for servers than anything else, although having it on the workstation is an added bonus. But, in terms of servers they will usually use RAID and mine always use RAID 5. In this case fragmentation is often beneficial.

But, the server arguement is just an excuse. The fact is that if fragmentation is such an issue then this proposed file system should not do fragmentation avoidance as ext2/3 does but, rather perform defragmentation functions with a seperate utility as is the case with M$ file systems. I've got no issues with a CRON job that runs a defragmentation process in the wee hours.

One final note: I can assure you that the Novell guys aren't taking your approach -- only overwriting something when they absolutely have to do so.

This is absolutely exactly what the Novell file system has done since v3.1 and has been maintained in all 9 versions since then, right up to today's Netware 6.0. Granted, I don't know how it's coded but, this is definitely the resulting behavior. No file is overwritten until the disk is physically out of space, or very near it. The only exceptions are those that are explicitly configured to "Purge" immediately. If your disk hasn't run out of space, say a really large disk or a really quiet server, it's possible to Salvage a file from six years ago, even if the server has been rebooted everyday.

lvm snap

[martinflack]

I don't use a "trash can" on my home linux computer per se, but I do run Logical Volume Manager and one of the _best_ features is the ability to take a snapshot of a logical volume.

The snapshot uses zero bytes when you first make it, and then as activity happens on your drives it records changes (imagine a "super-diff"). The amount of space you need to allocate to the snapshot depends on how long you want it around and how frequently you write to disk.

I decided this is useful when automated so my home computer makes a place called /mnt/snap every Sunday morning with enough space (1G) to last all week. During the week I can then recover any file that existed on the previous Sunday morning, but there was no lengthy "backup" process or tape drive or anything. I like it very much.

Here's my /etc/cron.weekly/lvsnap:
#!/bin/bash
umount /mnt/snap
lvremove -f /dev/big/snap >/dev/null
lvcreate -L 1G --snapshot -n snap /dev/big/rh >/dev/null
mount -r /dev/big/snap /mnt/snap

BTW, I don't even have two HD's on my LVM. I just imlpemented it on my main drive for the sheer geekiness of it, i.e. cool features like this one. Yes, before someone points it out, I realize theoretically with just 1 drive LVM makes it slower rather than faster but (a) I didn't notice any speed difference, probably because my CPU is fast, and (b) it's a non-critical home computer.

Version Control Systems

[aaarrrgggh]

I'll go for the easy argument:

If all your files are in a RCS... shouldn't it be a function of the file system?

Re:Wake-up call

[phorm]

Hockey: It's a Canadian game. Not, it's a game Canada made, but a game Canadians love and tend to center their lives around

Basketball: Did we really invent this? I remember something about lacrosse being originally a Native sport from Canada, never realized we invented basketball too.

Wonder if anyone would be successful on a topic of factual "who invented what" for popular recreation and technology. Last time I heard Americans were trying to steal credit from us for the Telephone/telegraph (Mr. Bell is the man for this, sorry guys)

For those who wont.......

[tanveer1979]

use trash can, I have a suggestion alias rm "rm -i" .

Use GNU rm!

[FooBarWidget]

[hongli@izumi src]$ rm -rf .*
rm: cannot remove `.' or `..'
rm: cannot remove `.' or `..'
[hongli@izumi src]$