A very kind soul has mailed me this reply for the bugs in CView.
Since he isn't in the position to post this himself, he asked me to post
it for him, but to leave his name out. So here it comes:

CView has quite a number of bugs.  The one you mention is perhaps the most
annoying, but not the most dangerous.  As far as I can determine, it has to
do with the temp files that CView creates.  CView gives the user no control
over where it places its temp files: it just places them in its
"current directory".  The problem you mention occurs (as far as I can tell)
when it runs out of disk space for its temp files. It seems as if CView
doesn't check properly for this situation.  As Cview decodes a jpeg, it seems 
to write out a temp file with all the pixel data with 24 bit colour
information. Then, for 8 bit displays, it does the "dithering", again writing
another file with the 8 bit colour information.  While it is writing this
second file, it also writes the data to your colour card. Then when it does
the last chunk of 8 bit data, it recopies all the data from the 8 bit file to
your screen again.  (It does this last "recopy" operation for its
"fit to screen" feature, even when this feature is not enabled.)

 The result of this process is the following:
  
     1) If it runs out of disk space when writing the first 24 bit file, all
        you ever see is as much data as it has room for, and the last bit of
        data is simply repeated over and over again because CView never
        realizes the disk has filled up and disk writes/reads aren't performed.

     2) If it has enough room for the 24 bit data, but runs out of room for
        the 8 bit data, you see almost all of the picture as it does the
        dithering and writes to the screen card.
        However, then when it finishes the dithering and recopies the data
        from the 8 bit file to screen (for whatever reason it does this)
        one again just gets a repetition of the last chunk of data for which
        there was room on the disk.

This is just a guess, but probably fairly accurate.  At least the general
idea is on track I think, although I have probably made errors in details
about file I/O etc.  The way around this is  of course to clear up sufficient
disk space.  The temp files for large JPEG's (1200x900 and bigger) can be
very large (3 Meg + 1 Meg ).  On some of the largest I have needed in excess
of 6 Meg free disk space.


CView has a much more serious bug: if you are trying to display a file from
a floppy, and you change floppies while CView has some temp file open on the
floppy, then CView in certain circumstances will write the directory (and FAT
table? I can't remember) for the removed floppy onto the newly inserted
floppy, thus corruptimg the new floppy in a very serious, possibly
unrevcoverable way.  SO BE CAREFUL!  It is incredibly poor programming for a
program to do this.  On the other hand, when choosing files in the Open Files
menu, CView insists on doing a few disk reads every time one moves the
hi-lighter square.  Incredibly annoying when it could do them all at once
when it gets the directory info.  And really, how much effort does it take to
sort a directory listing?
