From owner-freebsd-hackers Fri Apr 12 6:15:53 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id 68F6037B405 for ; Fri, 12 Apr 2002 06:15:50 -0700 (PDT) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g3CDFnv74028; Fri, 12 Apr 2002 08:15:49 -0500 (CDT) (envelope-from tinguely) Date: Fri, 12 Apr 2002 08:15:49 -0500 (CDT) From: mark tinguely Message-Id: <200204121315.g3CDFnv74028@web.cs.ndsu.nodak.edu> To: freebsd-hackers@FreeBSD.ORG, wayne@staff.msen.com Subject: Re: quotactl issues In-Reply-To: <20020411170324.K56996@staff.msen.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > No replies on this. Nobody has any ideas? > > > > Nobody has seen it until now. > > SOMEbody did - that's why they hacked edquota.c! See code fragment below. I tried to replicate the problem with DDB and QUOTA compiled into the kernel but could not. Grasping at straws, I am wondering if he has some kind of corruption in the quota file. But even corruption in the quota file should not make quotactl() return a EINVAL (besides the documented bad command, or type, that would be from a low driver with a bad unit number). Since this is not generically reproducable, could you add DDB to the kernel and trace a run through the quoactl() routine to see why the EINVAL is generated? --mark tinguely To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message