lindberg@chalmers.UUCP (Gunnar Lindberg) (11/04/86)
/etc/quotacheck does not correct quota file entries for users that
no longer owns any files in the file system.
System:
UNIX BSD 4.2++ (TURBO), VAX 11/780.
Mainly used for education so we quite frequently create and
remove users (which may be part of the problem).
Observation:
/etc/repquota starts reporting numerous "#1234..." entries. Using
"find -user 1234", however, does not give anything. In fact, the
quota file is in error since the user's entry should have been
cleared out but hasn't.
Repeat by:
God knows! I have no idea on how to reproduce the situation.
There could be bugs in the way the kernel manipulates the quota
files when root removes files (is this likely?). At times we remove
quite large amounts of users (200-300) using shell scripts, possibly
this could lead to "quota overrun"...
Fix:
What /etc/quotacheck mainly does, is going through the file system
(inode tables) collecting file sizes etc. for each user. These
values are the compared to the content of the quota file for the
users that were found during the search. However, no check is made
that the users *not* found in the search has zero entries in the
quota file! Diff's, see below.
Gunnar Lindberg (lindberg@chalmers.{UUCP,CSNET})
Department of Computer Science
Chalmers University of Technology
S-412 96 Gothenburg, SWEDEN
RCS file: quotacheck.c,v
retrieving revision 1.1
diff -r1.1 quotacheck.c
56a57
> struct fileusage zerofupbuf; /* Empty entry */
163,166c164
< for (uid = 0; uid <= highuid; uid++) {
< fup = lookup(uid);
< if (fup == 0)
< continue;
---
> for (uid = 0, i = 1; ; uid++) {
170,175c168,190
< dqbuf = zerodqbuf;
< if (dqbuf.dqb_curinodes == fup->fu_usage.du_curinodes &&
< dqbuf.dqb_curblocks == fup->fu_usage.du_curblocks) {
< fup->fu_usage.du_curinodes = 0;
< fup->fu_usage.du_curblocks = 0;
< continue;
---
> dqbuf = zerodqbuf; /* Unknown... */
> if (i == 0 && uid > highuid) /* EOF && End of users */
> break;
> fup = lookup(uid);
> if (fup == (struct fileusage *)0)
> {
> /*
> * If we didn't find him in our inode-search he (hopefully)
> * doesn't own any files here. If quota file says different
> * we'd better fix it!
> */
> if (dqbuf.dqb_curinodes == 0 && dqbuf.dqb_curblocks == 0)
> continue; /* Empty, OK */
> fup = &zerofupbuf; /* clear it out */
> }
> else
> {
> if (dqbuf.dqb_curinodes == fup->fu_usage.du_curinodes &&
> dqbuf.dqb_curblocks == fup->fu_usage.du_curblocks) {
> fup->fu_usage.du_curinodes = 0;
> fup->fu_usage.du_curblocks = 0;
> continue;
> }woods@hao-wks.UUCP (Greg Woods) (11/08/86)
In article <862@chalmers.UUCP>, lindberg@chalmers.UUCP (Gunnar Lindberg) writes: > > /etc/quotacheck does not correct quota file entries for users that > no longer owns any files in the file system. > > Observation: > /etc/repquota starts reporting numerous "#1234..." entries. Using > "find -user 1234", however, does not give anything. I have also observed this on our VAX 11/750's running 4.2BSD (vanilla, with some local hacks, but none in the quota system). It can be reproduced by removing all the files for a given user ID, removing the line for that user ID from the passwd file, and then immediately running quotacheck(8). After that run repquota(8) and you will see the #1234.. entry for the user you just removed. As stated, find(1) won't find any files for this user ID, because there aren't any. I haven't tried Gunnar's fix yet, but I plan to! --Greg -- {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA