From owner-freebsd-arch@FreeBSD.ORG Mon Apr 29 13:34:40 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69E236EE; Mon, 29 Apr 2013 13:34:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id 079D01560; Mon, 29 Apr 2013 13:34:39 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3TDYUD3020661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 23:34:31 +1000 Date: Mon, 29 Apr 2013 23:34:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Kenneth D. Merry" Subject: Re: patches to add new stat(2) file flags In-Reply-To: <20130426221023.GA86767@nargothrond.kdm.org> Message-ID: <20130429231638.N1440@besplex.bde.org> References: <20130307000533.GA38950@nargothrond.kdm.org> <20130307222553.P981@besplex.bde.org> <20130308232155.GA47062@nargothrond.kdm.org> <20130310181127.D2309@besplex.bde.org> <20130409190838.GA60733@nargothrond.kdm.org> <20130418184951.GA18777@nargothrond.kdm.org> <20130419215624.L1262@besplex.bde.org> <20130426221023.GA86767@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Tre+H0rh c=1 sm=1 a=n2O7wv11oSwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=YOiZBDKP_E4A:10 a=wjh2EmcBLpGD4jLuB4EA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: arch@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 13:34:40 -0000 On Fri, 26 Apr 2013, Kenneth D. Merry wrote: I haven't looked at this much. Just a quick reply since I will be away for a while. > On Fri, Apr 19, 2013 at 22:53:50 +1000, Bruce Evans wrote: >> On Thu, 18 Apr 2013, Kenneth D. Merry wrote: >> >>> On Tue, Apr 09, 2013 at 13:08:38 -0600, Kenneth D. Merry wrote: >>>> ... >>>> Okay, I think these issues should now be fixed. We now refuse to change >>>> attributes only on the root directory. And I updatd deupdat() to do the >>>> same. >>>> >>>> When a directory is created or a file is added, the archive bit is not >>>> changed on the directory. Not sure if we need to do that or not. (Simply >>>> changing msdosfs_mkdir() to set ATTR_ARCHIVE was not enough to get the >>>> archive bit set on directory creation.) >>> >>> Bruce, any comment on this? >> >> I didn't get around to looking at it closely. Just had a quick look at >> the msdosfs parts. >> >> Apparently we are already doing the same as WinXP for ATTR_ARCHIVE on >> directories. Not the right thing, but: >> - don't set it on directory creation >> - don't set it on directory modification >> - allow setting and clearing it (with your changes). Further testing showed the same behaviour for ntfs under WinXP (you can manage all the attribute bits for directories, but they don't control anything for directories, at least using Cygwin utilities). About not setting the archive bit in for modifications of directories in msdosfs: most settings of this bit are managed by the DETIMES() macro. It is set when the directory mtime is set (the denode is first marked for update of the mtime -- DE_UPDATE flag). But since modifications of directories don't change the mtime (we are bug for bug compatible with Win/DOS here), this never sets the archive bit for directories. The mtime can be changed for directories using utimes() in my version but not in -current, and using some Win/DOS syscall. I'm setting the archive bit for this, but will change to be bug for bug compatible with Win/DOS by not setting it. Then only chflags will set it for directories. >> @ *** src/lib/libc/sys/chflags.2.orig >> @ --- src/lib/libc/sys/chflags.2 >> @ *************** >> @ *** 112,137 **** >> @ ... >> @ --- 112,170 ---- >> @ ... >> @ + .It Dv UF_IMMUTABLE >> @ + The file may not be changed. >> @ + Filesystems may use this flag to maintain compatibility with the DOS, >> Windows >> @ + and CIFS FILE_ATTRIBUTE_READONLY attribute. >> >> msdosfs doesn't use this yet. It uses ATTR_READONLY, and doesn't map this >> to or from UF_IMMUTABLE. I think I want ATTR_READONLY to be a flag and >> not affect the file permissions (just like immutable flags normally don't >> affect the file permissions. > > Okay, done. The permissions are now always 755, and writeability is > controlled by ATTR_READONLY. Should be 755 by default, but there is a mount option to change this. >> Does CIFS FILE_ATTRIBUTE_READONLY have exactly the same semantics as >> IMMUTABLE? That is, does it prevent all operations on the file and the >> ... > Okay. I added a new flag, UF_READONLY that maps to ATTR_READONLY directly > instead of using an immutable flag. > ... > The other outstanding issue is the suggestion by Gordon Ross on the Illumos > developers list to make ZFS not enforce the readonly bit. It looks like it > has not yet gone into Illumos. We may not want to make the change in > FreeBSD since it hasn't gone in upstream yet. This shows that we want to not enforce the readonly bit (or other flags) even for msdosfs. msdosfs is a good place to test changing the policy since there aren't many critical file systems using it. Bruce