Jeff Abrahamson on 11 Sep 2004 20:43:02 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] corrupt jpeg

On Sat, Sep 11, 2004 at 04:20:17PM -0400, Alexander Birch wrote:
>   [16 lines, 88 words, 711 characters]  Top characters: _niesalo
> On Sat, 11 Sep 2004 14:33:38 -0400, John Sladek <> wrote:
> > I've had this happen when ftp'ing graphic files with out changing to binary
> > mode first.
> > Not sure if that helps..
> This happens when ftping between a windows box and a linux box. The
> windows box uses a carriage return and a new line, i.e., \r\n Where
> Linux just used \n.

If by "this" you mean ftp'ing in text mode instead of binary and
having problems, this is true.  Also when moving between either of
these and MacOS.

But part of the context you trimmed showed that the byte change was
from 0xF5 to 0x95.  (I didn't verify but took the original poster's
word for it.)  That means a high bit was lost, but other high bits
were not lost.  The file was long enough that a single bit error is
not so easily explained.  (Recall that only *one* bit in the whole
file changed.)

Here's that diff output from the original message:

> 0063060 ea55 29fd f004 83c0 3fb2 f93a 899e f529
> 0063060 ea55 29fd f004 83c0 3fb2 f93a 899e 9529

I wonder if that bit error checksums the same.  It would be
interesting to check the checksumming routines in whatever file
transfer program was used to see if the two files look identical to
it.  Such things are possible with very (very) low probability.

You then said:
> This is yet another reason not to use windows.

...or another reason not to use linux.  Or just to avoid anything
that's different. ;-)


 Jeff Abrahamson  <>    +1 215/837-2287
 GPG fingerprint: 1A1A BA95 D082 A558 A276  63C6 16BF 8C4C 0D1D AE4B

 A cool book of games, highly worth checking out:

Attachment: signature.asc
Description: Digital signature