On 10/16/13 10:52 AM, Filipe David Borba Manana wrote: > This test is motivated by an issue found by a btrfs user, addressed > and described by the following GNU/Linux kernel patch: > > https://patchwork.kernel.org/patch/3046931/ > > The steps to reproduce the issue on btrfs are the following: > > $ mkfs.btrfs -f /dev/loop0 > $ mount /dev/loop0 /mnt > $ mkdir /mnt/acl > $ setfacl -d --set u::rwx,g::rwx,o::- /mnt/acl > $ getfacl /mnt/acl > user::rwx > group::rwx > other::r-x > default:user::rwx > default:group::rwx > default:other::--- > > $ mkdir /mnt/acl/dir1 > $ getfacl /mnt/acl/dir1 > user::rwx > group::rwx > other::--- > > After unmounting and mounting again the filesystem, getfacl returned the > expected default ACL for the subdirectory: > > $ umount /mnt/acl > $ mount /dev/loop0 /mnt > $ getfacl /mnt/acl/dir1 > user::rwx > group::rwx > other::--- > default:user::rwx > default:group::rwx > default:other::--- > > This means that the underlying ACL xattr was persisted correctly but > the in memory representation of the inode had (incorrectly) a NULL ACL. > > Signed-off-by: Filipe David Borba Manana <fdmanana@xxxxxxxxx> > --- > > V2: Moved the regression test into a dedicated and new file, as suggested > by Eric Sandeen. Great, thanks. Verified that it succeeds on xfs & ext3 as well. It also fails properly when mounting ext3 -o noacl: shared/052 1s ... [not run] ACLs not supported by this filesystem type: ext3 ... > +# real QA test starts here > +_supported_os Linux Technically this should have a: +_supported_fs generic here. And then it can move to tests/generic/xxx (I guess that's a little odd and redundant, and it does run today w/o the _supported_fs, I guess, but still best to be consistent). Sorry for the runaround :) If you don't mind a V3, we'll be done, I think! -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
