From owner-freebsd-current  Sun May 25 21:15:59 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id VAA26257
          for current-outgoing; Sun, 25 May 1997 21:15:59 -0700 (PDT)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA26252;
          Sun, 25 May 1997 21:15:53 -0700 (PDT)
Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5])
          by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id VAA01976;
          Sun, 25 May 1997 21:15:52 -0700 (PDT)
Date: Sun, 25 May 1997 21:15:50 -0700 (PDT)
From: Jaye Mathisen  <mrcpu@cdsnet.net>
To: Julian Elischer <julian@FreeBSD.ORG>
cc: current@FreeBSD.ORG
Subject: Re: NEW FEATURE.. RFC will commit unless....
In-Reply-To: <199705260138.SAA25070@freefall.freebsd.org>
Message-ID: <Pine.NEB.3.95.970525211516.28807J-100000@mail.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


I think this would be great, especially when you want to keep certain
files/dirs in the directories of customers that they can't remove.



On Sun, 25 May 1997, Julian Elischer wrote:

> 
> I would like feedback on a new feature I want to add to the 
> filesystem code.
> 
> In addition to the immutible and append flags, we at whistle are
> using a flag NOUNLINK
> 
> The action of this flag is to allow the file or dir in question
> to be modified in any way but never deleted.
> 
> 
> There are several places we find this to be of use..
> but the basic usage is to ensure that a particular
> skeleton of directories and files remains untouched, even while allowing
> new files to be added and deleted TO that hierarchy, and while allowing
> some users administrative privs in that hierarchy.
> 
> 
> The changes are simple and easy to follow.
> I can forward  them to anyone for inspection. I will also put them
> on ref.tfs.com /incoming/NOUNLINK.
> these are relative to 2.2 as that is what we are using in production,
> however I will commit them to -current if I get no violent objections.
> 
> I would ALSO like to add them to 2.2 as they can easily be shown to be
> non interfering to any file without the new flag set, and that all conditionals
> affected, are such that this is an entirely new behaviour and 100% compatible
> for allpeople not using this feature.
> 
> comments?
> 
> tomatoes?
> potatoes?
> 
> julian
>