X903%DMAFHT1.BITNET@cunyvm.cuny.edu ( Marc Wachowitz) (04/24/91)
Undelete utility? Unneccessary. Just make "rm" an alias to a simple program that moves your file to a designated directory, perhaps giving a unique name to it and recording the association between the original name (including path) in a log file; including the date of "deletion". Recovery from unwanted deletion should now be trivial. To get rid of files you really want to forget (say, a few days after the pseudo-deletion), have a kind of "purge" command really remove such old files in the trash directory. If you fear having too much garbage occupying your precious space if you forget to purge, make it a daemon (running it once over night should suffice; e.g. with cron). Implementation is trivial and left to the interested reader :-) Marc Wachowitz X903@DMAFHT1.BITNET
protin@pica.army.mil (Arthur W. Protin Jr.) (04/24/91)
Folks,
Marc Wachowitz <X903%DMAFHT1.BITNET@cunyvm.cuny.edu> gave some
very bad advice in his message of <9104240626.aa04084@VGR.BRL.MIL>
Wed, 24 Apr 91 11:50:34 GMT when he said:
> ... Just make "rm" an alias to a simple
NEVER EVER make "rm" an alias for something less dangerous than "/bin/rm".
People get used to using the command in a friendlier form and wreck havoc
when they get into a normal environment.
When you want a "delete" that protects you, use "delete" or "del" or
"RM" or ........
Of course, such a replacement for "rm" won't remove all use that we
might have from an undelete utility. Most of the files that I destroy
I do with implicit deletes.
Arthur Protin <protin@pica.army.mil>
These are my personal views and do not reflect those of my boss
or this installation.
X903%DMAFHT1.BITNET@cunyvm.cuny.edu ( Marc Wachowitz) (04/25/91)
On Wed, 24 Apr 91 11:59:22 EDT GC-ACCURATE Arthur W. Protin Jr. said: ... >NEVER EVER make "rm" an alias for something less dangerous than "/bin/rm" >People get used to using the command in a friendlier form and wreck havoc >when they get into a normal environment. >When you want a "delete" that protects you, use "delete" or "del" or >"RM" or ........ Well, perhaps you misunderstood what I proposed. I didn't think of replacing "/bin/rm", I meant you should replace it in your usage, just like Mr. Protin said :-) Depending on your personal taste, you may define it as a shell alias command, just to avoid typing "rm" where you would - as you'll for sure notice some seconds later - have liked "delete" (or whatever you call it). I'd never replace any system tool if I can avoid it (except perhaps extended backwards-compatible replacements to change the behaviour of otherwise unconfigurable tools, which shouldn't exist anyway). ... >Of course, such a replacement for "rm" won't remove all use that we >might have from an undelete utility. Most of the files that I destroy >I do with implicit deletes. Implicit deletes? I'd never let something delete my files implicitly. If you are referring to such things as the GNU-Emacs dired-mode, just change the effect of the command. These are just my personal views, modify as applicative to you. Don't start a flame war, it isn't worth it :-) Marc
jik@athena.mit.edu (Jonathan I. Kamens) (04/26/91)
In article <26647@adm.brl.mil>, X903%DMAFHT1.BITNET@cunyvm.cuny.edu ( Marc Wachowitz) writes: |> Undelete utility? Unneccessary. Just make "rm" an alias to a simple |> program that moves your file to a designated directory, perhaps giving |> a unique name to it and recording the association between the original |> name (including path) in a log file; including the date of "deletion". |> ... |> Implementation is trivial and |> left to the interested reader :-) Implementation is very trivial, because it has already been done. See the "delete" package in comp.sources.misc. My implementation differs from yours -- deleted files are kept in the current directory, rather than in a temporary directory, and no log files are kept. We considered the implementation you describe when designing the program, but it is not appropriate in a distributed computing environment and in a program that wants to be robust. If you want something simpler than "delete", there are several other programs in the comp.sources.unix archives to do recoverable rm's. Note the Followup-To; the discussion of how to write user-level undelete programs isn't a wizardly topic, even though the discussion of modifying Unix so that it allows undeletion might be. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
rockwell@socrates.umd.edu (Raul Rockwell) (04/26/91)
Arthur Protin writes: > NEVER EVER make "rm" an alias for something less dangerous than > "/bin/rm". [ cause when it isn't, things get bad.. ] Maybe this shouldn't be in .wizards, but I can't help but add: never make "em" an alias for emacs. There's this key just to the right of "e" on most keyboards... Raul
martin@mwtech.UUCP (Martin Weitzel) (04/27/91)
In article <26647@adm.brl.mil> X903%DMAFHT1.BITNET@cunyvm.cuny.edu ( Marc Wachowitz) writes:
There are several 'undelete'-programs available as PD- or commercial
software. But one thing I'm missing is an 'unformat'. For example if
I go and format a floppy or even the harddisk and some days later I
find that I've thrown away some valuable files, it would be nice to
get them back. The fact that there is no such 'unformat'-command is
exactly that sort of thing that makes UNIX such a unfriendly system
for the non-guru users.
Must I really note that the above was pure sarcasm? Oh, better I do,
before my mailbox flows over.
--
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
rayan@cs.toronto.edu (Rayan Zachariassen) (04/29/91)
Since this is supposed to be unix-wizards how about this modified Q: In the BSD FFS (at least), whenever an inode is deallocated it is very thoroughly zero'ed out and then written to disk. In particular, the block pointers and size field all get nuked. I think this was intended to help fsck with its job, but I can't see why it is *necessary* to use this particular destructive technique instead of some other flag. If the information was kept, an inode-based undelete would be practical. I'm upset 'cuz this field-nulling business cost a friend and I a couple of days once in retrieving a file. Mutter. Chris?... rayan
jik@athena.mit.edu (Jonathan I. Kamens) (04/29/91)
In article <26671@adm.brl.mil>, X903%DMAFHT1.BITNET@cunyvm.cuny.edu ( Marc Wachowitz) writes: |> On Wed, 24 Apr 91 11:59:22 EDT GC-ACCURATE Arthur W. Protin Jr. said: |> ... |> >NEVER EVER make "rm" an alias for something less dangerous than "/bin/rm" |> >People get used to using the command in a friendlier form and wreck havoc |> >when they get into a normal environment. |> >When you want a "delete" that protects you, use "delete" or "del" or |> >"RM" or ........ |> Well, perhaps you misunderstood what I proposed. I didn't think of |> replacing "/bin/rm", I meant you should replace it in your usage, |> just like Mr. Protin said :-) Mr. Protin understood just fine what you proposed. You have not understood his objection to your suggestion. If you make "rm" an alias for some less destructive file deletion command, then you might become accustomed to typing "rm" when you actually mean to do something less drastic. Then, some day you'll go to work on another Unix system, type "rm" when you were expecting the less drastic behavior, and lose. Allow me to present an example. I have "rm" aliased to "delete", my file deletion program (see comp.sources.misc). I'll be honest -- that's probably a bad idea. I tend to do things like "rm paper.*; undelete paper.tex && expunge" to get rid of all the chaff that latex generates and be left with only my original tex file (obviously, I don't do this when I have bibliography files too :-). It is quite possible that one day I'll be working on some other system where I don't have that alias, and make the mistake of removing important work. Now, obviously I don't *think* it'll happen, which is why I have the alias. The main reason I don't think it'll happen is that I do nearly all of my "real" work on systems that have my delete program and have my alias in my dotfiles. It may be true that, for me, the alias is safe, because I can remember when I'm working where. However, doing something like putting a system-wide alias for "rm" in /etc/profile (or whereever) would be a REALLY bad idea. The reason for this is that many users will never realize that the "rm" they're using that allows for recovery is not standard. They'll graduate and go to work somewhere, and the first time they accidentally delete something, presto, there's no way to get it back, and they've got a rude awakening to face. That's why I'm a bit uncomfortable with what Purdue does. They've got this "entomb" thing which replaces file-destructive system calls with functions that first move the old file out of the way before creating the new one. What happens when Purdue students go out into the real world and discover that "mv" and "rm" are permanent operation in most of it? Perhaps the benefit from the recoverability outweighs this danger; that's a judgment I'm not prepared to make here, but as I said, I'm uncomfortable with that system. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
navarra@casbah.acns.nwu.edu (John 'tms' Navarra) (04/29/91)
In article <1991Apr29.015855.26661@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <26671@adm.brl.mil>, X903%DMAFHT1.BITNET@cunyvm.cuny.edu ( Marc Wachowitz) writes: >|> On Wed, 24 Apr 91 11:59:22 EDT GC-ACCURATE Arthur W. Protin Jr. said: >|> ... >|> >NEVER EVER make "rm" an alias for something less dangerous than "/bin/rm" >|> >People get used to using the command in a friendlier form and wreck havoc >|> >when they get into a normal environment. >|> >When you want a "delete" that protects you, use "delete" or "del" or >|> >"RM" or ........ >|> Well, perhaps you misunderstood what I proposed. I didn't think of >|> replacing "/bin/rm", I meant you should replace it in your usage, >|> just like Mr. Protin said :-) > >Mr. Protin understood just fine what you proposed. You have not understood >his objection to your suggestion. > > >However, doing something like putting a system-wide alias for "rm" in >/etc/profile (or whereever) would be a REALLY bad idea. The reason for this >is that many users will never realize that the "rm" they're using that allows >for recovery is not standard. They'll graduate and go to work somewhere, and >the first time they accidentally delete something, presto, there's no way to >get it back, and they've got a rude awakening to face. > >That's why I'm a bit uncomfortable with what Purdue does. They've got this >"entomb" thing which replaces file-destructive system calls with functions >that first move the old file out of the way before creating the new one. What >happens when Purdue students go out into the real world and discover that "mv" >and "rm" are permanent operation in most of it? > >Perhaps the benefit from the recoverability outweighs this danger; that's a >judgment I'm not prepared to make here, but as I said, I'm uncomfortable with >that system. > I disagree. I like what Purdue does. I am WELL aware that if I type rm that I will lose a file that I have been currently working on. And I don't always count on systems backups that are done once a week. If you have an alias or a program like entomb running chances are the ones who understand what is going on understand that on another system if they type rm then the file might be gone forever, and the ones that don't are also helped since they are probably surprised that they can retrieve thier files. Either way, I don't think anyone will get in the habit of typing rm and then going to the sysadmin to get their files back. Also, if you are using this machine MOST of the time, then there is little chance of you making the same mistake on another computer. What needs to be done is to make sure the sysadmin informs the users that the alias, program etc is NOT standard and whether you know alot about Unix or not, don't get in the habit of typing rm and expecting to regain your files. I have written a number of programs (including an rm function) to enhance my envirionment -- that is the fun of Unix. Why take away something that does more good than harm? I guarentee there is more instances where people accidently delete unwanted files straight out than people who remove files because they forgot there is an undelete function somewhere. >-- >Jonathan Kamens USnail: >MIT Project Athena 11 Ashford Terrace >jik@Athena.MIT.EDU Allston, MA 02134 >Office: 617-253-8085 Home: 617-782-0710 -- From the Lab of the MaD ScIenTiST: navarra@casbah.acns.nwu.edu
lm@slovax.Eng.Sun.COM (Larry McVoy) (04/29/91)
Most of this sort of thing goes away when you have a hierarchical file system that saves the last days files as /yesterday. Suppose each day, in each UFS file system, you had a copy of the file system that had all the active files from the last 24 hours. Most of the stuff people delete and want back will be found in that spot. Only rarely do you have to go to tape. You can do this with a shell script, by the way. --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
bernie@metapro.DIALix.oz.au (Bernd Felsche) (04/30/91)
In <ROCKWELL.91Apr25234458@socrates.socrates.umd.edu> rockwell@socrates.umd.edu (Raul Rockwell) writes: >Arthur Protin writes: >> NEVER EVER make "rm" an alias for something less dangerous than >> "/bin/rm". [ cause when it isn't, things get bad.. ] >Maybe this shouldn't be in .wizards, but I can't help but add: never >make "em" an alias for emacs. There's this key just to the right of >"e" on most keyboards... How about the famous newsreader: "rn" :-) ? -- Bernd Felsche, _--_|\ #include <std/disclaimer.h> Metapro Systems, / sale \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au
W_FEE%ccvax.unicamp.ansp.br@uicvm.uic.edu (05/01/91)
sei -la'........
akolman@mnsmc1.mnsmc.edu (05/06/91)
Geez, why not just write a shell script to rename the file to have a "non-used" extension to the file name and then have it delete those files with the special extension at the end if your session or upon command? Assuming disk space isn't a problem (like here at SMC), that should work. Of course I know nothing (or NeXT to nothing about UNIX shell scripts). BLx - Pronounced "Blue," the x is silent, the u is non-existent Saint Mary's College #789 CS Major, non-denture wearer 700 Terrace Heights Winona, MN 55987-0857 Veritas in Musica