Date: Fri, 16 Jan 2004 03:48:10 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.org Subject: Re: Error build -STABLE ports on bento Message-ID: <1074242890.75600.37.camel@shumai.marcuscom.com> In-Reply-To: <20040116192603.K3280@gamplex.bde.org> References: <1074239065.75600.28.camel@shumai.marcuscom.com> <1074239456.75600.31.camel@shumai.marcuscom.com> <20040116192603.K3280@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-HVrqx1v/9D5dRyv3sMZw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-01-16 at 03:43, Bruce Evans wrote: > On Fri, 16 Jan 2004, Joe Marcus Clarke wrote: >=20 > > 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 stran= ge > > > problem. The -STABLE chroots (running 490101) built under FreeBSD > > > -CURRENT (501114) refuse to copy 0 length files. Whenever cp encount= ers > > > 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 und= er > > > FreeBSD -CURRENT 501108. Non-zero length files are copied just fine. > > > Is this something I should expect to be fixed if the cluster is upgra= ded > > > to today's -CURRENT? Is there a simple workaround that can be used i= n > > > 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. >=20 > 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. >=20 > % 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, th= e > % check and removal operations by munmap(2) must be in the same critic= al > % section. To accomodate this, vm_map_check_protection() is modified = to > % require its caller to obtain at least a read lock on the map. > % ---------------------------- >=20 > % 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> > % ---------------------------- >=20 > 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. Thanks for the pointer! Are there plans to MFC this? At least I can hack our local tree in the meantime. Joe >=20 > Bruce --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-HVrqx1v/9D5dRyv3sMZw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAB6VKb2iPiv4Uz4cRAlMBAKCglgmd2L0LPtVWMia3svYfmUwtPACfUi+U D30wNJKsNnVbOXxmpB8Vbpk= =wwD7 -----END PGP SIGNATURE----- --=-HVrqx1v/9D5dRyv3sMZw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1074242890.75600.37.camel>