Date: Wed, 28 Aug 2013 15:36:53 -0600 From: "Kenneth D. Merry" <ken@freebsd.org> To: Bryan Drewery <bryan@shatow.net> Cc: swills@freebsd.org, svn-src-all@freebsd.org, kwm@freebsd.org, antoine@freebsd.org, madpilot@freebsd.org 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> In-Reply-To: <13d31864e269b87bbf573d33b0bb6494@shatow.net> References: <201308212304.r7LN4mr6058450@svn.freebsd.org> <13d31864e269b87bbf573d33b0bb6494@shatow.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130828213653.GA62128>