Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!rutgers!sri-spam!sri-unix!hplabs!hao-wks!woods
From: woods@hao-wks.UUCP (Greg Woods)
Newsgroups: net.bugs.4bsd
Subject: Re: Bug in /etc/quotacheck
Message-ID: <289@hao-wks.UUCP>
Date: Sat, 8-Nov-86 02:33:05 EST
Article-I.D.: hao-wks.289
Posted: Sat Nov  8 02:33:05 1986
Date-Received: Sun, 9-Nov-86 03:39:36 EST
References: <862@chalmers.UUCP>
Organization: High Altitude Obs./NCAR, Boulder CO
Lines: 24
Summary: Large amounts of create/remove users not necessary to see this...

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