From owner-freebsd-current Sun Sep 8 1:47:46 2002 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 EBC5B37B400; Sun, 8 Sep 2002 01:47:43 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FA7043E42; Sun, 8 Sep 2002 01:47:42 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA23988; Sun, 8 Sep 2002 18:47:39 +1000 Date: Sun, 8 Sep 2002 18:55:16 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Bruce A. Mah" Cc: Poul-Henning Kamp , Subject: Re: libmd bug on -CURRENT In-Reply-To: <200209071604.g87G44pc019967@intruder.bmah.org> Message-ID: <20020908183745.X2381-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 7 Sep 2002, Bruce A. Mah wrote: > If memory serves me right, Bruce Evans wrote: > > libmd is also broken for some cases involving pipes. IIRC, this is > > caused by the bogus st_size checks in the same function. st_size is > > only valid for regular files. > > It's puzzling that the call to lseek(2) doesn't always return an error > in these cases as well (as the manpage seems to imply). Yet, one can do > md5(1) on a pipe: > > tomcat:bmah% cat /etc/motd | md5 > 9caae6eae6f9c2dfea77d6a5fae2e93c > tomcat:bmah% md5 /etc/motd > MD5 (/etc/motd) = 9caae6eae6f9c2dfea77d6a5fae2e93c I don't remember exactly which case(s) are broken. The above works, but cat /dev/motd | md5 /dev/stdin doesn't -- it gives the seek error. I think the open() in mdXFileChunk() gets used for the latter but not when stdin is used directly. This is with /dev/stdin not on devfs or fdescfs. Named pipes seem to work too: mkfifo p; md5 < p & cat /etc/motd >p # same result as md5 /etc/motd > > The loop in the function fails to to terminate if read() returns 0, > > which can probably happen if the file shrinks underneath us. > > Maybe add a check after the read(2), so that if it returns zero, we set > n = 0? It's not clear to me what result should be returned in the case > of trying to compute a checksum on a file that shrinks in the middle of > the computation. Writes that change the file underneath us will make a mess of the result. Hmm ... detecting changes is very easy, at least for regular files - just use fstat() and compare ctimes. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message