fsgqa group membership?

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



Hi!

After migrating to a new test environment, I observed that generic/193 failed.
Initially, I assumed it was a UBIFS regression, but it appears that all other file systems have also been affected.

generic/193       - output mismatch (see /root/xfstests-dev/results//generic/193.out.bad)
    --- tests/generic/193.out   2024-01-14 08:55:20.114082471 +0000
    +++ /root/xfstests-dev/results//generic/193.out.bad 2024-01-14 14:30:51.598725128 +0000
    @@ -45,10 +45,10 @@
     check that suid/sgid bits are cleared after successful truncate...
     with no exec perm
     before: -rwSr-Sr--
    -after:  -rw-r-Sr--
    +after:  -rw-r--r--
     with user exec perm
     before: -rwsr-Sr--
    ...
    (Run 'diff -u /root/xfstests-dev/tests/generic/193.out /root/xfstests-dev/results//generic/193.out.bad'  to see the entire diff)

It turned out that the test failed because the user "fsgqa" did not have the "fsgqa" group assigned.
After rectifying this, the test passed successfully.

But it is nowhere stated that this has to be that way.

README says only:
6. (optional) Create fsgqa test users and groups:

   $ sudo useradd -m fsgqa
   $ sudo useradd 123456-fsgqa
   $ sudo useradd fsgqa2
   $ sudo groupadd fsgqa

Just in case, users fsgqa and fsgqa2 want the groups fsgqa/fsgqa2 as their primary groups
to have all tests work as expected?

Thanks,
//richard




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux