From owner-p4-projects@FreeBSD.ORG Wed Aug 6 21:49:49 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 7C03A1065691; Wed, 6 Aug 2008 21:49:49 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EE671065678; Wed, 6 Aug 2008 21:49:49 +0000 (UTC) (envelope-from trasz@freebsd.org) Received: from pin.if.uz.zgora.pl (pin.if.uz.zgora.pl [212.109.128.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6463C8FC16; Wed, 6 Aug 2008 21:49:47 +0000 (UTC) (envelope-from trasz@freebsd.org) Received: by pin.if.uz.zgora.pl (Postfix, from userid 1001) id 9C9AD39BC9; Wed, 6 Aug 2008 23:32:24 +0200 (CEST) Date: Wed, 6 Aug 2008 23:32:24 +0200 From: Edward Tomasz Napierala To: Tim Kientzle Message-ID: <20080806213224.GA5906@pin.if.uz.zgora.pl> References: <200808061413.m76EDIfR043441@repoman.freebsd.org> <4899CA21.8000307@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <4899CA21.8000307@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Perforce Change Reviews Subject: Re: PERFORCE change 146774 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2008 21:49:49 -0000 On 0806T0858, Tim Kientzle wrote: > > http://perforce.freebsd.org/chv.cgi?CH=146774 > > > > Change 146774 by trasz@trasz_traszkan on 2008/08/06 14:12:37 > > > > Ignore "append" permission - use "write_data" instead - on regular > > files to match SunOS (and ZFS) behaviour. > > I always thought the reason for a separate "append" > bit was to protect files such as log files by allowing > them to be appended but not overwritten. Yes. > Maybe Sun is wrong here? I think it's just that they didn't finish this part yet. > Does the NFS4 spec say anything about this? Well, "append_data" permission works just as one might imagine - it controls appending data at the end of the file. On a directory, it is somewhat less intuitive - with "write_data" permission, one can create files in that directory. With "append_data", one can create subdirectories. NFS4 spec does not require full support for that "granularity" in access permissions, however. So ignoring append permission on files seems ok. The main reason for this change is for UFS and ZFS to behave in the same way. If we cannot be fully right (and I think fixing granularity in ZFS is somewhat outside of scope of my project), lets at least be consistent. ;-) -- If you cut off my head, what would I say? Me and my head, or me and my body?