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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to