From owner-cvs-src@FreeBSD.ORG  Sat Dec 11 19:29:45 2004
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0D64A16A4CE; Sat, 11 Dec 2004 19:29:45 +0000 (GMT)
Received: from harmony.village.org (rover.village.org [168.103.84.182])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id A840C43D5E; Sat, 11 Dec 2004 19:29:44 +0000 (GMT)
	(envelope-from imp@harmony.village.org)
Received: from localhost (localhost [IPv6:::1])
	by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBBJStpj013182;
	Sat, 11 Dec 2004 12:28:55 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Date: Sat, 11 Dec 2004 12:28:54 -0700 (MST)
Message-Id: <20041211.122854.74737190.imp@harmony.village.org>
To: kientzle@FreeBSD.org
From: Warner Losh <imp@harmony.village.org>
In-Reply-To: <200412110711.iBB7BgLi030397@repoman.freebsd.org>
References: <200412110711.iBB7BgLi030397@repoman.freebsd.org>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/lib/libarchive archive_entry.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Dec 2004 19:29:45 -0000

>   Be more careful about assembling/disassembling
>   device numbers.  In particular, this should fix
>   a bug where archiving a device node with a very
>   large minor number would sometimes overflow and
>   corrupt the major number.

This also pointed out a bug in our mknod() routine in one edge case.
I believe we should return EINVAL when that happens in the syscall.

Specifically "mknod foo c 255 0xffff00ff" results in a file foo with
major/minor number of 0.  This is because VNOVAL is -1 and there
appear to be checks against it in the code later, hence we end up with
0, 0.  I believe that we should either make it work (hard), or we
should return EINVAL from the syscall wrapper or some routine early in
the path.

Comments?

Warner