Mailinglist Archive: opensuse (3242 mails)

[Anders Johansson <andjoh@xxxxxxxxxxxxxxxxxxxxx>]

On Monday 03 September 2001 19.40, Ben Rosenberg wrote:
> * Seán Ó Ceallaigh (sean0cea11aigh_@xxxxxxxxxxx) [010903 09:34]:
> ->
> ->I have a work around to this problem:
> ->
> ->   If you update your system with a patch using RPM -U ...,
> ->   you need to fool YaST2 into thinking it was installed.
> ->
> ->   Problem:
> ->
> ->    Performing YaST2 Online Update, Internet connection times
> ->    out before all patches downloaded.  You want to install the
> ->    the rpms that you got before you lost the internet connection
> ->    but YaST2 Online Update thinks it needs to re-download all those
> ->    patches again.
> ->
>
> If you are using ftp.suse.com I think this is also a problem with the
> amount of time that's set before the connection times out and your
> disconnected. When I use gFTP and I am tagging the files for downloaded
> it make take a few minutes to go through what I want and what I don't
> want (ie..KDE2's apps directory) and the connection can time out before
> I'm 1/2 way through deciding what I need and don't. This is a problem.
> My solution..although a stupid solution is to just use ncftp in 3 xterms
> connected at the same time and instead of going through the directories
> for just what I want. I download all the RPM's .. I just set and forget.
> That way I don't have to keep reconnecting. I know SuSE doesn't want
> people hanging out on the ftp site and taking up one of the max
> connections..but the short timeout on the ftp server is just wrong and a
> pain in the ass.
>
> If your on a modem I bet this is why it dies before you get the whole
> list.
>
> Regards,

There is another problem with downloading large files. The control connection 
times out while a large file downloads. Apparently, the ftp implementations 
don't send keep_alive:s or ping:s or whatever ftp uses to tell the server 
that the client is still there. I've had this happen with Yast, but also with 
command line ftp. So when then file is done, there is no control connection 
to send back a new request for the next file. mget fails almost always with 
this. The only 'solution' I've found is to use wget, which is smart enough to 
open a new control connection if the first one dies.

Anders