On 10/21/13 10:14 AM, Eric Sandeen wrote: > On 10/21/13 10:09 AM, Josef Bacik wrote: >> On Mon, Oct 21, 2013 at 10:03:10AM -0500, Eric Sandeen wrote: >>>> On 10/18/13 1:26 PM, Josef Bacik wrote: >>>>>> There was a problem with send trying to overwrite a file that wasn't actually >>>>>> the same. This is a test to check this particular case where receive fails when >>>>>> it should succeed properly. I tested this to verify it fails without my fix and >>>>>> passes with my fix. Thanks, >>>> >>>> 2 things - >>>> >>>> Why does the selinux context break things? That seems like a problem w/ send >>>> if it can't work on a context-mounted fs? (disabling it for now doesn't bother >>>> me, but I'm surprised that it's required). >>>> >> So it is the context that xfstests is using, not contexts itself. Xfstests is >> using the nfs context, and using selinux contexts intercepts all getxattr calls, >> so when send tries to copy the xattrs for the file it calls getxattr, and >> because we are using the nfs context it returns EOPNOTSUPP from selinux, it >> never makes it down to btrfs. When using the actual real context it works fine >> because it calls down into the file system. >> > > This still sounds weird. Is btrfs send trying to copy the selinux attrs directly? > > Shouldn't they be skipped, and be left up to the receiving end to set the selinux > xattrs (or not) per the policy for the destination? Eh, ok, Josef pointed out that "cp -a" does exactly the same thing. So I'll retract the concern & go learn more about selinux. ;) -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
