Date: Wed, 6 Aug 2008 23:32:24 +0200 From: Edward Tomasz Napierala <trasz@freebsd.org> To: Tim Kientzle <kientzle@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 146774 for review Message-ID: <20080806213224.GA5906@pin.if.uz.zgora.pl> In-Reply-To: <4899CA21.8000307@freebsd.org> References: <200808061413.m76EDIfR043441@repoman.freebsd.org> <4899CA21.8000307@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080806213224.GA5906>