patches to add new stat(2) file flags

[Bruce Evans]

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