Date:        Thu, 17 Aug 2000 12:31:50 +0200 (CEST)
    From:        Mirko Thiesen <thiesi@NetWork23.BSDOnLine.ORG>
    Message-ID:  <Pine.NEB.4.21.0008171220030.10936-100000@ReLink.NetWork23.BSDOnLine.ORG>

  | The highest UIDs I have are the following:

That's in the passwd file - what matters is what is on the filesystem.
Your filesystem can get strange uids in several ways - one is unpacking a
tar file as root (the uids built into the tar file will be extracted).
Another is just random disk errors (even filesystem bugs) causing bad
data getting written in an inode.

  | I'm still unsure what to do. One the one hand I don't want to touch my
  | running system, because it is *very* stable right now.

As Steve Bellovin said, you probably don't have to do anything while your
system is running and stable.

  | On the other hand I
  | see my disk space being used up more and more ...

That's unlikely to be the quota file, unless you're creating files
owned by more and more user numbers.

  | And I also remember that
  | some time ago I had some problems booting up my system when there was
  | something wrong with the quota files (i.e. quotacheck simply hung the
  | machine).

But when you need to reboot, that is going to happen again if you
don't fix it (so Steve Bellovin's "harmless" isn't quite right, though
it should be).   It is unlikely the machine was hung though - had you
waited long enough (when I had this the quotacheck would take about 20
minutes to complete) it would have finished, and you should be able to ^C
(interrupt) on the console to simply abandon the quotecheck and continue the
boot.

The huge file is the cause of this, along with a bug in quotacheck that
causes it to spin its wheels pretending to update all of the empty entries
that don't really exist.

  | I'd prefer to not touch the quota files if I didn't need to.

You probably do need to.  But you need to find whatever file is out there
owned by a huge user ID first, or it will simply grow back to this big
again, and you will be wasting effort.

It is pretty easy to hack quotacheck to inform you of, and then ignore,
any uids that are outside a range that you define.  Perhaps it should do
that all the time, taking the largest uid in the passwd file as the limit
it deals with?

Quotacheck can be made (by source modification) to tell you the inode number
of the file with the huge uid (or files), after that it is a simple (if
perhaps slow, if the filesystem is big) find to locate the files (and if
find, when run as root, can't locate the things, then a clri to zap the
inodes is warranted).  (Pity that we don't have ncheck which would tell
you the path name much quicker than find is able).

Once the files with the weird uids are gone, you need to truncate the
quota file.   You can do that just by creating a ftruncate.c program
which opens quote file, and does the ftruncate sys call with the size
you want it to have - maxuid * sizeof (struct dqblock)

Or, if you can easily recreate the limits you have set for the
various users (like they're all the same or something), you can just
zap the quota file (disable quotas on the filesystem first), and then
recreate the limits, then run quotacheck to recalculate all the usage
info.   Other than losing what limits the users are all set to (if the
quota file is the only home for that data) there's not much damage that
you can do by fooling with the quota file - about the worst that can
happen is the possibility that some users may hit a fake low limit if
you manage to set bad limits on the users - that will not make people
happy.  About the next worst is that while quotas are off, people can
run over their limits, which might run you out of space, or cause them
inconvenience when the limits are put back and quotas re-enabled.

If you need help modifying quotacheck to do any of this, I can probably
send mods that work (I may have submitted a PR about this, if you search).

kre