Date: Sun, 18 Apr 1999 13:03:44 -0400 (EDT) From: Bill Pechter <pechter@i4got.pechter.dyndns.org> To: hackers@FreeBSD.ORG Subject: Re: freebsd-hackers-digest V4 #458 Message-ID: <199904181703.NAA03039@i4got.pechter.dyndns.org> In-Reply-To: <bulk.83499.19990417230915@hub.freebsd.org> from freebsd-hackers-digest at "Apr 17, 1999 11: 9:15 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sat, 17 Apr 1999 21:52:14 +1000 > From: Greg Black <gjb-freebsd@gba.oz.au> > Subject: Re: Entombing for FreeBSD > > Matthew Dillon writes: > > > I've been thinking about this enombing thing... well, I hate to say it, > > but crowbaring into libc is *not* the right way to do it. It's > > just too intrusive. The right way to do it would be to write a device > > driver similar to NULLFS which handles backing up the files, thus giving > > the sysad the option to use such a device to mount-through those partitions > > that the sysad wants to keep checkpointed. Also, putting such intrusive > > code into libc would be fairly dangreous from a security point of view > > even if it is turned off. > > I am completely in agreement with this. It's not something for > libc and it needs to be kept at arm's length from everything > else if it's ever to be part of the core of FreeBSD. > > - -- > Greg Black <gjb@acm.org> Actually, the entombing stuff is interesting, but not for libc. Perhaps a separate daemon and rm replacement might be reasonable. Maybe something like an attribute could be used to turn it on and off by directory or user id. We don't need this on all files and on all file systems. Imagine entombing on /usr/spool/news/... Ugh. I'd even like to see a file system with VAX/VMS like version numbers available which would make the entombing less necessary. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904181703.NAA03039>