From owner-svn-src-all@FreeBSD.ORG Wed Aug 28 21:36:55 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 276D2A10; Wed, 28 Aug 2013 21:36:55 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6EF62970; Wed, 28 Aug 2013 21:36:54 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id r7SLars6062842; Wed, 28 Aug 2013 15:36:53 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id r7SLar0H062841; Wed, 28 Aug 2013 15:36:53 -0600 (MDT) (envelope-from ken) Date: Wed, 28 Aug 2013 15:36:53 -0600 From: "Kenneth D. Merry" To: Bryan Drewery Subject: Re: svn commit: r254627 - in head: bin/chflags bin/ls lib/libc/gen lib/libc/sys sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/fs/msdosfs sys/fs/smbfs sys/sys sys/ufs/ufs Message-ID: <20130828213653.GA62128@nargothrond.kdm.org> References: <201308212304.r7LN4mr6058450@svn.freebsd.org> <13d31864e269b87bbf573d33b0bb6494@shatow.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13d31864e269b87bbf573d33b0bb6494@shatow.net> User-Agent: Mutt/1.4.2i Cc: swills@freebsd.org, svn-src-all@freebsd.org, kwm@freebsd.org, antoine@freebsd.org, madpilot@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 21:36:55 -0000 On Wed, Aug 28, 2013 at 15:54:18 -0500, Bryan Drewery wrote: > On 2013-08-21 18:04, Kenneth D. Merry wrote: > >Author: ken > >Date: Wed Aug 21 23:04:48 2013 > >New Revision: 254627 > >URL: http://svnweb.freebsd.org/changeset/base/254627 > > > >Log: > > Expand the use of stat(2) flags to allow storing some Windows/DOS > > and CIFS file attributes as BSD stat(2) flags. > > > > This work is intended to be compatible with ZFS, the Solaris CIFS > > server's interaction with ZFS, somewhat compatible with MacOS X, > > and of course compatible with Windows. > > > > The Windows attributes that are implemented were chosen based on > > the attributes that ZFS already supports. > > > > The summary of the flags is as follows: > [...] > > > > UF_ARCHIVE: Command line name: "uarch", "uarchive" > > ZFS_NAME: XAT_ARCHIVE, ZFS_ARCHIVE > > Windows name: FILE_ATTRIBUTE_ARCHIVE > > > > The UF_ARCHIVED flag means that the file has changed and > > needs to be archived. The meaning is same as > > the Windows FILE_ATTRIBUTE_ARCHIVE attribute, and > > the ZFS XAT_ARCHIVE and ZFS_ARCHIVE attribute. > > > > msdosfs and ZFS have special handling for this flag. > > i.e. they will set it when the file changes. > > Is it intended that this flag is automatically added to all new and > existing ZFS files? Yes, that is intentional. ZFS already has the flag internally, this just exposes it to FreeBSD. With ZFS at least, it is set any time a file changes. If an application clears it on files it has archived, it will know when the file has changed and it needs to archive the file again. This is the inverse (more or less) of the SF_ARCHIVED flag. With UFS, the flag is just passed through and stored. One application for this is to support CIFS servers that need to store DOS/CIFS/Windows attributes on a FreeBSD server. > # touch test > # ls -alo test > -rw-r--r--- 1 root wheel uarch 0 Aug 28 15:46 test > > This breaks 'cp -p' to tmpfs as tmpfs does not allow this flag. > > # mkdir /tmp/tmpfs > # mount -t tmpfs tmpfs /tmp/tmpfs > # cp -f test /tmp/tmpfs > cp: test: Operation not supported Right. For some filesystems, like UFS and probably tmpfs, the right answer may be to just pass through most all of the file flags, and reject specific flags that it doesn't support. For some filesystems, like smbfs, the right answer seems to be to just ignore flags that are set that aren't supported. Other filesystems, like msdosfs, support a small number of flags and reject any that aren't supported. In other words, this isn't a new problem, and it would have cropped up if you tried to copy a file with the SF_IMMUTABLE flag set from UFS to msdosfs with cp -p. > [...] > >Modified: head/sys/ufs/ufs/ufs_vnops.c > >============================================================================== > >--- head/sys/ufs/ufs/ufs_vnops.c Wed Aug 21 22:57:29 2013 (r254626) > >+++ head/sys/ufs/ufs/ufs_vnops.c Wed Aug 21 23:04:48 2013 (r254627) > >@@ -528,9 +528,11 @@ ufs_setattr(ap) > > return (EINVAL); > > } > > if (vap->va_flags != VNOVAL) { > >- if ((vap->va_flags & ~(UF_NODUMP | UF_IMMUTABLE | UF_APPEND | > >- UF_OPAQUE | UF_NOUNLINK | SF_ARCHIVED | SF_IMMUTABLE | > >- SF_APPEND | SF_NOUNLINK | SF_SNAPSHOT)) != 0) > >+ if ((vap->va_flags & ~(SF_APPEND | SF_ARCHIVED | > >SF_IMMUTABLE | > >+ SF_NOUNLINK | SF_SNAPSHOT | UF_APPEND | UF_ARCHIVE | > >+ UF_HIDDEN | UF_IMMUTABLE | UF_NODUMP | UF_NOUNLINK | > >+ UF_OFFLINE | UF_OPAQUE | UF_READONLY | UF_REPARSE | > >+ UF_SPARSE | UF_SYSTEM)) != 0) > > return (EOPNOTSUPP); > > if (vp->v_mount->mnt_flag & MNT_RDONLY) > > return (EROFS); > > Seems a similar change is needed in tmpfs_subr.c:tmpfs_chflags() > (antoine pointed this out) Sure, I can fix tmpfs. Ken -- Kenneth Merry ken@FreeBSD.ORG