From owner-freebsd-hackers Tue Oct 28 14:38:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA26979 for hackers-outgoing; Tue, 28 Oct 1997 14:38:36 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA26974 for ; Tue, 28 Oct 1997 14:38:31 -0800 (PST) (envelope-from faber@ISI.EDU) Received: from ISI.EDU (vex-s.isi.edu [128.9.192.240]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA27532; Tue, 28 Oct 1997 14:37:44 -0800 (PST) Message-Id: <199710282237.OAA27532@tnt.isi.edu> To: Terry Lambert Cc: perlsta@cs.sunyit.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Recovering Lost Inode? In-Reply-To: Your message of "Tue, 28 Oct 1997 17:10:15 GMT." <199710281710.KAA25828@usr06.primenet.com> X-Url: http://www.isi.edu/~faber Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Oct 1997 14:37:44 -0800 From: Ted Faber Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Terry Lambert wrote: >> >(maybe i've used win95 once too many...) >> >> I won't bore you with the short scripts that provide this behavior on >> UNIX. If that's the file deletion paradigm that you like, it's easy >> to do... >> >> "UNIX was not designed to stop you from doing stupid things, because >> that would also stop you from doing clever things." -- Doug Gwyn > >I'll note that these methods are generally restricted to interactive >shells, and are not effective for deletes under programmatic control. >So these methods are probably *not* what he wants, and certainly not >what his system administrator wants. When I jotted off the earlier note, I thought he wanted a safe rm script. Seems reasonable -- file deletion from the Windows GUI is the moral equivalent of file deletion from the shell -- since they both protect from file deletion from the primary user interface. However, your note got me thinking... One quick and dirty way to get trashcan behavior, even outside the shell, is to create a mirror of the user's directory structure under ~/trashcan (omitting ~/trashcan from the mirror, of course). Populate the ~/trashcan with hard links to the user's real files. Use cron to add new files and directories to the trashcan mirror regularly. Emptying the trashcan is just a matter of removing files that don't have links outside the trashcan (deleting files with only one link approximates this, but doesn't take into account files that are multiply linked in the user's home directory). Restoring a file is relinking it. Now, I just dashed that off the top of my head, and I'm sure that there are special cases that it doesn't cover (files created and deleted between cron jobs, symlinks, renaming files), but it's a long way toward trashcan behavior for all files without touching any file system code. (And I think most of the special cases could be caught.) There's a cost for maintaining the directory structure, but beyond that, it's even pretty cheap in terms of system resources, which would make his sysadmin happy. As you mentioned in another note, getting real "soft delete" behavior is a hard problem, and an interesting one. For me, it's solved by frequent, easily accessible backups, but I'm sure there are others who would appreciate such a system. - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNFZpN4b4eisfQ5rpAQEQgwP/ZiEI3YupGnBNDSxIdb//TCLO4OIj+Ija RlwkvvlLOUmmD2jDKm2Q8R7py/Rwn+qCv1lJOHJJAPdVdPpmfWqO0OpFIGUcuo6r 2SCUP8H/UNUuodDDLzmTLKgjAUkxCwcFbFjFUjCToguoLK5d+suWY0Usw8NUKBWy UrcxByLjwaU= =0O6M -----END PGP SIGNATURE-----