It is vital to remember that Linux is unlike MS-DOS when it comes to undeletion. For MS-DOS (and its bastard progeny Windows 95), it is generally fairly straightforward to undelete a file - the `operating system' (I use the term loosely) even comes with a utility which automates much of the process. For Linux, this is not the case.
So. Rule number one (the prime directive, if you will) is:
KEEP BACKUPS
no matter what. I know, I'm a fine one to talk. I shall merely plead impoverishment (being a student must have some perks) and exhort all right-thinking Linux users to go out and buy a useful backup device, work out a decent backup schedule, and to stick to it. For more information on this, read Frisch (1995) (see section Bibliography and Credits).
In the absence of backups, what then? (Or even in the presence of backups: belt and braces is no bad policy where important data is concerned.)
Try to set the permissions for important files to 440 (or less): denying
yourself write access to them means that rm requires an explicit
confirmation before deleting. (I find, however, that if I'm recursively
deleting a directory with rm -r, I'll interrupt the program on the first
or second confirmation request and reissue the command as rm -rf.)
A good trick for selected files is to create a hard link to them in a hidden
directory. I heard a story once about a sysadmin who repeatedly deleted
/etc/passwd by accident (thereby half-destroying the system). One of
the fixes for this was to do something like the following (as root):
# mkdir /.backup
# ln /etc/passwd /.backup
It requires quite some effort to delete the file contents completely: if you say
# rm /etc/passwd
then
# ln /.backup/passwd /etc
will retrieve it. Of course, this does not help in the event that you overwrite the file, so keep backups anyway.
On an ext2 filesystem, it is possible to use ext2 attributes to protect things.
These attributes are manipulated with the chattr command. There is an
`append-only' attribute: a file with this attribute may be appended to, but may
not be deleted, and the existing contents of the file may not be overwritten.
If a directory has this attribute, any files or directories within it may be
modified as normal, but no files may be deleted. The `append-only' attribute
is set with
$ chattr +a FILE...
There is also an `immutable' attribute, which can only be set or cleared by root. A file or directory with this attribute may not be modified, deleted, renamed, or (hard) linked. It may be set as follows:
# chattr +i FILE...
The ext2fs also provides the `undeletable' attribute (+u in chattr).
The intention is that if a file with that attribute is deleted, instead of
actually being reused, it is merely moved to a `safe location' for deletion at
a later date. Unfortunately this feature has not yet been implemented in
mainstream kernels. However, various kernel patches exist which provide the
ability to do reversible deletion; see
<http://www.linuxhq.com/>
if you're interested in patching this facility into your kernel. The most
recent patch I know of is by Rogier Wolff
<R.E.Wolff@BitWizard.nl>,
Darren J Moffat
<darren@xarius.demon.co.uk>
and Kurt Huwig
<kurt@huwig.de>.
I would point out though that while this patch implements the feature, it is
not an `undeletion solution' at the moment. Undeletable files are merely moved
into another directory; there should be a daemon to periodically clean up that
directory.
Some people advocate making rm a shell alias or function for rm -i
(which asks for confirmation on every file you delete). Indeed, recent
versions of the
Red Hat distribution
do this by default for all users, including root. Personally, I cannot stand
software which won't run unattended, so I don't do that. There is also the
problem that sooner or later, you'll be running in single-user mode, or using a
different shell, or even a different machine, where your rm function
doesn't exist. If you expect to be asked for confirmation, it is easy to
forget where you are and to specify too many files for deletion. Likewise, the
various scripts and programs that replace rm are, IMHO, very dangerous.
A slightly better solution is to start using a package which handles
`recyclable' deletion by providing a command not named rm. For details on
these, see Peek, et al (1993) (see section
Bibliography and Credits).