+++ This bug was initially created as a clone of Bug #688161 +++

Description of problem:
repquota reports 'Illegal reference (6 >= 6) in user quota file on /dev/loop0. Quota file is probably corrupted.' after chown command.
This is reproducible on all ext filesystems (ext2, ext4 and ext4).

Version-Release number of selected component (if applicable):
2.6.32-119.el6

How reproducible:
Always

Steps to Reproduce:
1. create & mount ext2/3/4 filesystem with usrquota and grpquota
mkfs.ext4 /dev/loop0
mount /dev/loop0 /mnt/ -o usrquota,grpquota
2. quotacheck and quotaon
quotacheck -u -g /mnt/
quotaon /mnt/
3. create file in the mountpoint and check quota with repquota (so far it should be ok)
touch /mnt/file
repquota -u -g /mnt/
4. chown file to a regular user and group
chown fsgqa:fsgqa /mnt/file # fsgqa is xfstests user/group
5. Show quota with repquota
repquota -u -g /mnt/
  
Actual results:
*** Report for user quotas on device /dev/loop0
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
repquota: Illegal reference (6 >= 6) in user quota file on /dev/loop0. Quota file is probably corrupted.
Please run quotacheck(8) and try again.

Expected results:
Repquota works normally and test 235 pass.

[...]

--- Additional comment from branto on 2011-03-17 17:52:55 GMT ---

Yes, it is a regression but not in kernel. I forgot that I updated quota package along with kernel package on my machine so I considered it to be a kernel bug but the real cause was the update of the quota package.
quota-3.17-10.el6 works fine.
quota-3.17-11.el6 has the bug (as well as latest quota-3.17-15.el6).

[...]

--- Additional comment from ppisar on 2011-03-21 14:30:32 GMT ---

According manual `quotacheck' on uninitialized file system should have the same effect as `quotacheck -c'. So this not the problem.

The problem is repquota from RHEL does not synchronize quota files (i.e does not ask kernel to dump current quota data into quota file) before parsing them and printing data form them.

If you run `quotasync' explicitly before, you will get correct results. Also running repquota twice has the same effect despite not calling quotactl(Q_SYNC, ...) (probably some side effect of other quotactl() query).

This bug seems to be fixed in newer (Fedora) quota tools version.

Thank you for reporting this issue.

--- Additional comment from ppisar on 2011-03-21 14:59:01 GMT ---

More precisely, it current RHEL code calls quotactl(Q_SYNC, ...) too but too late (after opening and buffering part of the quota file content).

Fixed in upstream tree by commit:

commit b58944b582722dd3c56893eb4b6c8b8a0291201d
Author: jkar8572 <jkar8572>
Date:   Thu May 27 13:12:57 2010 +0000

    * fix repquota to get latest quota info header (Jan Kara)
-----

Fedoras 16--15 affected too. Fedora 14 rereads headers after synchronization.