On 7/11/13 1:28 PM, Carlos Maiolino wrote: >>> >>> generic/313 - output mismatch (see /root/xfstests/results/generic/313.out.bad) >>> --- tests/generic/313.out 2013-07-08 16:27:41.787710646 -0500 >>> +++ /root/xfstests/results/generic/313.out.bad 2013-07-08 16:47:46.052683735 -0500 >>> @@ -1,3 +1,3 @@ >>> QA output created by 313 >>> -drwxr-sr-x. TEST_DIR/313-dir/subdir >>> +drwxr-sr-x TEST_DIR/313-dir/subdir >>> drwxrwsr-x+ TEST_DIR/313-dir/subdir2 >>> ... >>> (Run 'diff -u tests/generic/313.out /root/xfstests/results/generic/313.out.bad' to see the entire diff) >>> >>> Looks like there could be a problem with ls? Have you seen that? >>> >>> Thanks, >>> Ben >>> >> Actually I don't think this is a problem, but the way newer `ls` versions are >> displaying the object permissions (the 'dot' at the end of the permissions, >> indicating there are no extra attributes). >> >> I'm going to take a look on what's going on, but I still believe it's just a >> matter of add the 'dot' to the xfstests correct output. >> >> I had this same problem when testing my patch and needed to fix it locally, but >> missed to warn you guys, my apologies >> > Just a matter of information: > > From coreutils: > > commit b3677e5e383103bf1764b2c8a9329b1c17934b24 > Author: Jim Meyering <meyering@xxxxxxxxxx> > Date: Wed Apr 2 22:26:45 2008 +0200 > > ls: use '.' (not +) as SELinux-only alt. access flag in ls -l output > > > > So, this test is selinux dependent, it will provide different outputs whether > the system has selinux enabled or not. > > Since the test itself creates their own directories, checking if the selinux is > enabled or not and checking the proper output depending on selinux activity > should avoid false positives on this test. I.e. if the selinux is enabled, the > `ls -l` output will print the 'dot' at the end of the permissions, otherwise, > nothing will be printed and Eric's test will pass without problem. Hm, I thought we always mounted with a global selinux context, and therefore wouldn't get these differences (i.e. no on-disk selinux attrs should be created) > I think this is something worth to mention on xfstests README or some other > documentation, mainly because any kind of test like this, but done with the > TEST_DEV might be even worst since we don't recreate the filesystem while using > TEST_DEV, so, objects there can be created with selinux attrs or not (if created > when selinux is disabled) and have the attributes added later. It'd be better to just add a filter if we need it. But I'd like to know why we need it, I thought the global context made these problems go away... Guess I'll go look... -Eric > I'm probably being too paranoid here talking about the TEST_DEV, but, I thought > it was worth to mention. > > Cheers. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
