From owner-freebsd-current@FreeBSD.ORG Fri Jan 16 00:43:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAF4F16A4CE for ; Fri, 16 Jan 2004 00:43:56 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B649C43D1D for ; Fri, 16 Jan 2004 00:43:53 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id TAA17117; Fri, 16 Jan 2004 19:43:38 +1100 Date: Fri, 16 Jan 2004 19:43:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Joe Marcus Clarke In-Reply-To: <1074239456.75600.31.camel@shumai.marcuscom.com> Message-ID: <20040116192603.K3280@gamplex.bde.org> References: <1074239065.75600.28.camel@shumai.marcuscom.com> <1074239456.75600.31.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org Subject: Re: Error build -STABLE ports on bento X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 08:43:57 -0000 On Fri, 16 Jan 2004, Joe Marcus Clarke wrote: > On Fri, 2004-01-16 at 02:44, Joe Marcus Clarke wrote: > > I'm trying to get the latest 4-exp build done, and I'm seeing a strange > > problem. The -STABLE chroots (running 490101) built under FreeBSD > > -CURRENT (501114) refuse to copy 0 length files. Whenever cp encounters > > a 0 length file, it fails with EINVAL. For example: > > > > cp: /tmp/a/ports/sysutils/usermin/work/usermin-1.051/install-type: > > Invalid argument > > > > This is not happening with the same -STABLE version built and run under > > FreeBSD -CURRENT 501108. Non-zero length files are copied just fine. > > Is this something I should expect to be fixed if the cluster is upgraded > > to today's -CURRENT? Is there a simple workaround that can be used in > > lieu of upgrading at this time? Thanks. > > Hmmm...sorry to follow up to myself, but I just tested the same -STABLE > under a -CURRENT 502101 machine, and the behavior is the same. cp > returns EINVAL when trying to copy zero-length files. munmap(2) was recently perfectly broken to POSIX spec so that it doesn't work on zero-length files. cp and probably other utilities in RELENG_4 and older versions of FreeBSD are missing the fix for this, so they can't work right under -current. % RCS file: /home/ncvs/src/sys/vm/vm_mmap.c,v % Working file: vm_mmap.c % head: 1.177 % ... % ---------------------------- % revision 1.171 % date: 2003/11/10 01:37:40; author: alc; state: Exp; lines: +8 -6 % - The Open Group Base Specifications Issue 6 specifies that an munmap(2) % must return EINVAL if size is zero. Submitted by: tegge % - In order to avoid a race condition in multithreaded applications, the % check and removal operations by munmap(2) must be in the same critical % section. To accomodate this, vm_map_check_protection() is modified to % require its caller to obtain at least a read lock on the map. % ---------------------------- % RCS file: /home/ncvs/src/bin/cp/utils.c,v % Working file: utils.c % head: 1.42 % ... % ---------------------------- % revision 1.42 % date: 2003/11/13 05:26:55; author: alc; state: Exp; lines: +2 -1 % Don't mmap(2) and munmap(2) zero-length files. % % Submitted by: Wiktor Niesiobedzki % ---------------------------- Note that only munmap(2) is specified to be (or implemented to be) broken. You can mmap() zero-length files, but you can't munmap() them. Bruce