I was unable to replicate this bug in the test lab as reported by the
user. I was able to set a user up with a quota of 4 gigs with no error
reported. Please reopen bug if needed and send an exact sequence that
you are using to set the user up along with exact responces from the
system that tells you it is failing.

root@mokona:~# quota -v netstuff
Disk quotas for user netstuff (uid 503):
     Filesystem  blocks   quota   limit   grace   files   quota
limit   grace
      /dev/sda2    9505  100000  100000             163       0
0
       /dev/md011297272       0       0           28195       0
0
root@mokona:~# edquota netstuff

vi starts with:

Quotas for user netstuff:
/dev/sda2: blocks in use: 9505, limits (soft = 100000, hard = 100000)
        inodes in use: 163, limits (soft = 0, hard = 0)
/dev/md0: blocks in use: 11297272, limits (soft = 0, hard = 0)
        inodes in use: 28195, limits (soft = 0, hard = 0)

I set a 5 gigabyte quota for netstuff as follows:

Quotas for user netstuff:
/dev/sda2: blocks in use: 9505, limits (soft = 100000, hard = 100000)
        inodes in use: 163, limits (soft = 0, hard = 0)
/dev/md0: blocks in use: 11297272, limits (soft = 5000000, hard =
5000000)
        inodes in use: 28195, limits (soft = 0, hard = 0)

I save from vi and edquota says:

/dev/md0: cannot change current allocation
root@mokona:~# quota -v netstuff
Disk quotas for user netstuff (uid 503):
     Filesystem  blocks   quota   limit   grace   files   quota
limit   grace
      /dev/sda2    9505  100000  100000             163       0
0
       /dev/md011297272* 805696  805696    none   28195       0
0

root@mokona:~# cat /proc/version
Linux version 2.2.0-pre6 (zblaxell@washu.furryterror.org) (gcc version
2.7.2.3) #2 SMP Thu Jan 14 08:11:02 EST 1999

root@mokona:~# rpm -q quota
quota-1.55-9

root@mokona:~# cat /etc/redhat-release
Red Hat Linux release 5.2 (Apollo)

Here is how edquota fails in 6.1 for i386... note Macomb does NOT fail this way
...

(NOTE: edquota in the example below did NOT set the blocks quota to
5000000 as requested, is erroneously set the quota to 805696)

[root@test95 /root]# edquota user1

Quotas for user user1:
/dev/hda5: blocks in use: 24, limits (soft = 0, hard = 5000000)
        inodes in use: 6, limits (soft = 0, hard = 0)

[root@test95 /root]# repquota /dev/hda5
                        Block limits               File limits
User            used    soft    hard  grace    used  soft  hard  grace
root      --  662436       0       0          47831     0     0
daemon    --       8       0       0              3     0     0
news      --      84       0       0              2     0     0
uucp      --     972       0       0             17     0     0
games     --       0       0       0             37     0     0
gdm       --       4       0       0              1     0     0
xfs       --       8       0       0              3     0     0
user1     --      24       0  805696              6     0     0
[root@test95 /root]#

[root@test95 /root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda5              6103648    663828   5129768  11% /
/dev/hda1                23302      2647     19452  12% /boot

Created attachment 81 [details]
Diff against quota-1.66-8

I fixed this ages ago for quota-1.55, but it seems like that got lost.  Is
anyone maintaining the public (non-RH) quota-1.66 any more?

I've just added an attachment which fixes the problem.  The bug is only in
edquota: requota, quotacheck and quota all seem fine already.  It's a really
silly overflow error occuring during what should be an arithmetic no-op.

--Stephen

this was fixed for 6.2 and later.

*** Bug 9090 has been marked as a duplicate of this bug. ***