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
> 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