Date: Tue, 28 Oct 1997 04:03:15 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: perlsta@cs.sunyit.edu (Alfred Perlstein) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Recovering Lost Inode? Message-ID: <199710280403.VAA05753@usr08.primenet.com> In-Reply-To: <Pine.BSF.3.96.971027215943.1224C-100000@server.local.sunyit.edu> from "Alfred Perlstein" at Oct 27, 97 10:31:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> i've always wondered why when a file was deleted there was an intelegent > way of moving it to a volatile directory where it could be overwritten at > any time, but if moved out of that dir it would be marked non-volitile > again.... Yes, but it's best implemented as a stacking layer. 8-). You could also set a "deleted" bit (there's an extra bit in the flags field in the directory entry -- or was), and not return it on search based on a mount option. The "purge" issue is a little more complex. I used a POSIX namespace escape to implement this functionality in an attributed FS I wrote for NetWare. Without the escape, deleted files were hidden; with it, they were visibile. An unlink of a visible file made it invisibile, and an unlink of an invisible file actually removed it. You would want to make /tmp and probably several other places immune from deletes like this. You can get a similar effect to VMS versions using another namespace escape; stacking name space escapes, anyone? 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710280403.VAA05753>