| Jeff Abrahamson on 11 Sep 2004 20:43:02 -0000 |
|
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 <jsladek@comcast.net> 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 Jeff Abrahamson <http://www.purple.com/jeff/> +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: http://www.amazon.com/exec/obidos/ASIN/1931686963/purple-20 Attachment:
signature.asc
|
|