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:
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
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
# 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 (
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 if you’re interested in patching this facility into your kernel. The most recent patch I know of is by Rogier Wolff , Darren J Moffat and Kurt Huwig . 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).