On Wed, Jun 05, 2002 at 10:02:36PM +0100, Graeme Hewson wrote: > Presently, if the argument to -r is a FIFO, ethereal and tetheral > crash. It musn't be a FIFO because (t)ethereal wants to seek on it; the > attached patch to wiretap/file.c prevents the user specifying a FIFO.
Ethereal is unlikely ever to support reading from a pipe or FIFO unless it makes a copy of the *entire* pipe or FIFO either to memory or a temporary file. Tethereal, however, may someday be able to do so if we do some of our own buffering, to allow a limited amount of backward seeking. As such, I made "wtap_open_offline()" return an error on a FIFO only if asked to open for random access; I added a new error for that, so the user can be told "sorry, Ethereal doesn't read pipes". > It turns out there's a more fundamental reason for the crash, though. > There's a bug in zlib 1.1.3 and 1.1.4 (and presumably earlier versions > too) where gzseek() doesn't save its internal error status if its call > to fseek() fails. This means a subsequent call to gzerror() sets errnum > to whatever the error was before the call to gzseek(), which is likely > to be Z_OK (gzopen() and gzdopen() initialise the error status to > Z_OK). I changed "file_seek()" to take an additional "int *" argument, and had it return an error code through that pointer if the seek fails. The with-zlib version of the code assumes that if the seek fails but "file_error()" returns 0, it's because of that bug; it returns "errno" through that pointer in that case. That hides the problem inside Wiretap, rather than having Ethereal and Tethereal know about it.
