From owner-freebsd-hackers Sat Apr 17 5: 4:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 2CAE5151ED for ; Sat, 17 Apr 1999 05:04:37 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 22987 invoked by uid 1001); 17 Apr 1999 11:48:14 -0000 Message-ID: <19990417114814.22986.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Sat, 17 Apr 1999 21:48:14 +1000 From: Greg Black To: "C. Stephen Gunn" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Entombing for FreeBSD References: <199904160332.WAA28377@poynting.physics.purdue.edu> <19990416113734.18605.qmail@alice.gba.oz.au> <19990416150649.A1060@ohm.physics.purdue.edu> In-reply-to: <19990416150649.A1060@ohm.physics.purdue.edu> of Fri, 16 Apr 1999 15:06:49 EST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If we're restricting this to restoring lost files, I can't > > remember the last time I did that either. It was certainly more > > than 15 years ago. I don't use entombing. Can't see the point. > > It's not the last time _you_ had to restore a file that's the issue. For me, it *is* the point. I'm the person who would be restoring files for all the users on my networks and for all the users on my customers' networks. > If you've not had to do it for 15 years, entombing probably isn't > for you. Indeed. But I don't think it's desirable for anybody in the way you have proposed, and I was (and still am) arguing against that. > When was the last time you took care of 500+ users on a single > machine. Is this supposed to mean something? What makes you imagine that you know anything at all about what I do? If it matters, which it doesn't, I have regularly taken care of many hundreds of users on individual systems; and I do have some practical experience with what that means. But I don't think this should degenerate into one of those "mine is bigger than yours" things. > Users delete files. Users clobber files. Users intentionally > make changes to files and then don't want them tomorrow. Users can be trained, no matter what anybody claims to the contrary. Users who are so difficult to train that it doesn't seem to be worth the effort rarely have to be let loose with tools that can delete files, but can be accommodated within some GUI interface to the company database or whatever it is they do. > We have _serious_ users around here with serious needs. My users are serious. Their needs are serious. Their data is precious, both to them and to their customers. I go to great lengths to ensure that their data is not in danger. And those efforts are successful, as I indicated in my initial response. > The best part is if you don't like it, don't use it. ENTOMB=no, > and you're completely screwed as usual when you delete a file. ;-) Ah, no -- that's not what you have presented to us. You're talking about hacking this thing into libc where it will affect every program in the world, to provide a facility that would have been invented a million years ago if it was really useful. If you can dream up a way to provide it *without* affecting all those people who don't want it, then I would have no objection. But if it has to be via a hack to libc, then I trust that the decision makers in the FreeBSD team will choose not to commit it to the standard system. -- Greg Black To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message