From xemacs-m  Sun Jan 12 17:55:31 1997
Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id RAA02515 for <xemacs-beta@xemacs.org>; Sun, 12 Jan 1997 17:55:29 -0600 (CST)
Received: from mailhost.dstc.edu.au (jacaranda.dstc.edu.au [130.102.176.186])
          by piglet.dstc.edu.au (8.8.4/8.8.4) with ESMTP
	  id JAA03679 for <xemacs-beta@xemacs.org>; Mon, 13 Jan 1997 09:55:24 +1000 (EST)
Message-Id: <199701122355.JAA03679@piglet.dstc.edu.au>
X-Mailer: exmh version 1.6.9 8/22/96
To: xemacs-beta@xemacs.org
X-Url: http://www.pobox.com/~phelps/
Subject: Re: Deletion of read-only extents (was Re: scrollbars) 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 13 Jan 1997 09:57:56 +1000
From: Ted Phelps <phelps@dstc.edu.au>



> >> Do you consider the 19.14 ability to kill read-only extents a
> >> feature you must have, may sometimes need, or don't need at all?

> bp>   I call it a bug. :)  If its read-only, its read-only, dammit.

> I'm not arguing either way on this, but the Unix file system provides
> similar semantics, in that the permission to delete a file is
> completely independent of the permission to write to it.  So one could
> (even though I'm not) argue that permission to delete a read-only
> extent should depend only on whether the buffer is read-only.

I agree with BP on this one.

Unix lets you delete read-only files because Unix's
security model is broken.  Allowing the user to modify
read-only files is even more broken, not all that useful,
and most definitely inconsistent.  Just Don't Do It!

My 2 cents.
-Ted


