Date: Fri, 16 Jan 2004 19:43:38 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: current@FreeBSD.org Subject: Re: Error build -STABLE ports on bento Message-ID: <20040116192603.K3280@gamplex.bde.org> In-Reply-To: <1074239456.75600.31.camel@shumai.marcuscom.com> References: <1074239065.75600.28.camel@shumai.marcuscom.com> <1074239456.75600.31.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <bsd@w.evip.pl> % ---------------------------- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040116192603.K3280>