Searching \ for 'BS4 - corrupt file?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=bs4+corrupt+file
Search entire site for: 'BS4 - corrupt file?'.

Truncated match.
PICList Thread
'BS4 - corrupt file?'
1998\09\17@181641 by Dave Mullenix

flavicon
face
Has anybody else had trouble unzipping the BS4.ZIP file?  WinZip keeps
telling me it's not a complete file.  I've downloaded it several times
and get the same result each time.

Dave Mullenix

1998\09\18@061812 by Don McKenzie

flavicon
face
Dave Mullenix wrote:
>
> Has anybody else had trouble unzipping the BS4.ZIP file?  WinZip keeps
> telling me it's not a complete file.  I've downloaded it several times
> and get the same result each time.
>
> Dave Mullenix

Don't know about winzip Dave, but people are cetainly unzipping it with
pkunzip 2.04g
If there is a problem, I would like to know so I can overcome it.

Don McKenzie  spam_OUTdonTakeThisOuTspamdontronics.com   http://www.dontronics.com

Don's Download Dungeon: http://www.dontronics.com/download.html
For more details, send a blank message to .....infoKILLspamspam@spam@dontronics.com
or simstickspamKILLspamdontronics.com or .....basicsKILLspamspam.....dontronics.com

1998\09\18@093605 by Philip Restuccia

flavicon
face
Don McKenzie wrote:
>
> Dave Mullenix wrote:
> >
> > Has anybody else had trouble unzipping the BS4.ZIP file?  WinZip keeps
> > telling me it's not a complete file.  I've downloaded it several times
> > and get the same result each time.
> >
> > Dave Mullenix
>
> Don't know about winzip Dave, but people are cetainly unzipping it with
> pkunzip 2.04g
> If there is a problem, I would like to know so I can overcome it.
>
> Don McKenzie  EraseMEdonspam_OUTspamTakeThisOuTdontronics.com   http://www.dontronics.com
>

Two more data points ... the zip-file integrity test in Powerdesk
(latest
version ... I'm a registered owner) also fails on bs4.zip, stating that
the calculated checksum doesn't match the stored checksum. However, Unix
zip, running on my SPARC Ultra 5, has no problems with it, either
unzipping
or testing the integrity.

Seems to be something about Powerdesk and, apparently, WinZip.

       Philip Restuccia
       philip.restucciaspamspam_OUTperi.com

1998\09\18@153540 by Don McKenzie

flavicon
face
www.dontronics.com/bs4.html

Re: BS4 - corrupt file? 22-Sep-98
This file is 82,041 bytes in length.
In the first 3 days there has been 552 downloads and only two people
have reported problems. I downloaded and tested the file as being OK.
Please try again. Perhaps too many users have been trying to access it
at the same time and the connection times out. One user reported it as
being 81,920 bytes.

Don McKenzie  @spam@donKILLspamspamdontronics.com   http://www.dontronics.com

Don's Download Dungeon: http://www.dontronics.com/download.html
For more details, send a blank message to KILLspaminfoKILLspamspamdontronics.com
or RemoveMEsimstickTakeThisOuTspamdontronics.com or spamBeGonebasicsspamBeGonespamdontronics.com

1998\09\19@010621 by paulb

flavicon
face
Don McKenzie wrote:

> This file is 82,041 bytes in length.
> One user reported it as being 81,920 bytes.

 Dead right Don.  Many programs aren't sufficiently smart to
distinguish "Bad checksum" and "Checksum truncated from file".

 Reads right here.  Pity no source!
--
 Cheers,
       Paul B.

1998\09\19@022841 by Nigel Goodwin

flavicon
picon face
In message <TakeThisOuT360232B0.312A4FAEEraseMEspamspam_OUTdontronics.com>, Don McKenzie
<RemoveMEdonspamTakeThisOuTDONTRONICS.COM> writes
>Dave Mullenix wrote:
>>
>> Has anybody else had trouble unzipping the BS4.ZIP file?  WinZip keeps
>> telling me it's not a complete file.  I've downloaded it several times
>> and get the same result each time.
>>
>> Dave Mullenix
>
>Don't know about winzip Dave, but people are cetainly unzipping it with
>pkunzip 2.04g
>If there is a problem, I would like to know so I can overcome it.

I can unzip it with WinZip OK.
--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : nigelgEraseMEspam.....lpilsley.demon.co.uk     |
       | Lower Pilsley   | Web Page : http://www.lpilsley.demon.co.uk |
       | Chesterfield    | Official site for Shin Ki Ju Jitsu         |
       | England         |                                            |
       \--------------------------------------------------------------/

1998\09\19@150233 by Mark Willis

flavicon
face
Paul B. Webster VK2BZC wrote:
>
> Don McKenzie wrote:
>
> > This file is 82,041 bytes in length.
> > One user reported it as being 81,920 bytes.
>
>   Dead right Don.  Many programs aren't sufficiently smart to
> distinguish "Bad checksum" and "Checksum truncated from file".
>
>   Reads right here.  Pity no source!
> --
>   Cheers,
>         Paul B.

 I get corrupt files on downloading all the time, I just re-download
it.  The 'net isn't perfect, things get truncated off on occasion <G>  I
just "pkunzip -t zipfilename" & put it back on the list if that fails
<G>

 Mark

1998\09\19@152947 by Peter L. Peres

picon face
On Sat, 19 Sep 1998, Mark Willis wrote:

>   I get corrupt files on downloading all the time, I just re-download
> it.  The 'net isn't perfect, things get truncated off on occasion <G>  I

Sorry to disagree, the net uses TCP/IP for most data transfers, and that
(TCP)  is an error checking / retransmitting protocol. Chack out your
operating system and browser software for something that can loose data
without telling anyone (it would be embarassing to make it public ;).

Peter

1998\09\19@160341 by Mark Willis

flavicon
face
Peter L. Peres wrote:
>
> On Sat, 19 Sep 1998, Mark Willis wrote:
>
> >   I get corrupt files on downloading all the time, I just re-download
> > it.  The 'net isn't perfect, things get truncated off on occasion <G>  I
>
> Sorry to disagree, the net uses TCP/IP for most data transfers, and that
> (TCP)  is an error checking / retransmitting protocol. Chack out your
> operating system and browser software for something that can loose data
> without telling anyone (it would be embarassing to make it public ;).
>
> Peter

 Not disagreeing that it shouldn't happen, just saying that such things
as timeouts from horribly over-loaded ftp servers definitely happen,
corruption on upload or download via noisy phone lines happens, they
shouldn't but they do.  Trying to be out of denial here, Peter <G>  When
I download a 4 Meg file & only get 37kb, something's wrong there...

 Mark

1998\09\19@191040 by paulb

flavicon
face
Mark Willis wrote:

>  Not disagreeing that it shouldn't happen, just saying that such
> things as timeouts from horribly over-loaded ftp servers definitely
> happen,

 Yes.  We know what TCP/IP does, but the one form of corruption it
*doesn't* cover - is truncation!
--
 Cheers,
       Paul B.

1998\09\20@023531 by Mitchell D. Miller

flavicon
face
part 0 1478 bytes
-- Mitch

P.S.  There can also be situations where routers between you and the device you're downloading from unintentionally keep network traffic from getting through ... servers aren't the only ones overloaded!! <VBG>

------------------------------------
Mitch Miller, Roseville, CA
EraseMEmitchmspamns.net
------------------------------------

{Original Message removed}

1998\09\20@091624 by Peter L. Peres

picon face
On Sat, 19 Sep 1998, Mitchell D. Miller wrote:

> Can I say you're both right?  Although TCP is a session layer protocol
- snip -
> provide, timeouts can occur if the tolerances are set too tightly.
> Unfortunately, many (most??) TCP/IP stacks don't allow you to adjust
> those tolerances.

Timeouts, even unadjusted ones, are not to be swept under the carpet by
the protocol implementation and/or the client, int the hope that no-one
will notice (ha, ha, ha - no-one notices 1-2 packets missing, they are a
low percentage of the total traffic, right ?  Now, where would someone be
who thinks that way, let's see...).

BTW, the last fragment has a flag to say that it is the last fragment. So
a timeout is NOT an excuse to consider the transfer valid EVEN if it is
ignored.

Peter

1998\09\20@100727 by Peter L. Peres

picon face
On Sun, 20 Sep 1998, Paul B. Webster VK2BZC wrote:

> Mark Willis wrote:
>
> >  Not disagreeing that it shouldn't happen, just saying that such
> > things as timeouts from horribly over-loaded ftp servers definitely
> > happen,
>
>   Yes.  We know what TCP/IP does, but the one form of corruption it
> *doesn't* cover - is truncation!

That is news to me. I just happen to be tinkering quite deep in the
innards of a linux kernel source tree withe the TCP/IP reference
implementation and other piles of books at hand and truncation is
definitely, definitely covered by a TCP connection, which cannot be
'terminated' by one end going away, without the other end having at least
a time-out. Of course, certain OSes which expect a lot of errors anyway
can try to pretend that nothing happened by ignoring a timeout on
select/read and then ignore the fact that an open socket was not closed,
and even save the resulting file without notifying anyone, and even close
their end of the socket, still without as much as a whisper. BUT this is
not TCP/IP. It is someone's poor implementation of a protocol stack.

Peter

1998\09\20@180211 by paulb

flavicon
face
Peter L. Peres wrote, quoting me:

>>   Yes.  We know what TCP/IP does, but the one form of corruption it
>> *doesn't* cover - is truncation!

> That is news to me.

 It's simple pragmatism, with a bit of my sardonic humour.  If the
"link", whatever protocol or protocols may be involved, dies, it dies
and that's that.  The client (Netscape in my case) has been shoving data
into a file, and now finds no more data to put into it.

 It might choose to delete the file, or it might choose to close it in
case some data is recoverable/ useful, as indeed a partial HTML file is.
Remember that these are in fact web browser applications.

 These are the *only* choices.  Operator opinion could be called for,
but that locks up the user interface (and in Windoze, that's exactly
what it does!).  Netscape chooses to quietly close the file.

 If you understand this, you understand that you will from time to time
end up with truncated files, and will do what you do accordingly.

 Discussions of link layer protocols and stacks just *don't* come into
the matter, I'm afraid!
--
 Cheers,
       Paul B.

1998\09\20@192355 by Mark Willis

flavicon
face
Paul B. Webster VK2BZC wrote:
{Quote hidden}

 The other fun one I experienced recently was when a 600kb file, when
downloaded, somehow "grew" to over 850+kb during download.  Fun!  Maybe
it re-started transmitting the same file or ???

 pkunzip -t spake about it being an untruthful file that wouldn't work
<G>  I can't tell you WHY that occured;  I deleted the file &
re-downloaded.  Twas weird, though!

 Yep, I'm running NetScrape, for now at least.  Need to keep learning
Linux...

 I'm about to automate the ftp download stuff soon though (There's a
neat Nuts & Volts article by Karl Lunt that pointed my attention to a
nice tool.)  Then I'll get some other different failure modes <G>

 Mark, RemoveMEmwillisEraseMEspamEraseMEnwlink.com

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...