Date: Sat, 26 Jul 1997 11:33:03 -0400 (EDT) From: Mikhail Teterin <mi@aldan.ziplink.net> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: bin/4172: fetch(1): behavior upon timeout/disconnection Message-ID: <199707261533.LAA01455@rtfm.ziplink.net> Resent-Message-ID: <199707261540.IAA04451@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 4172 >Category: bin >Synopsis: link goes down for too long -- transfer fails >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Jul 26 08:40:02 PDT 1997 >Last-Modified: >Originator: Mikhail Teterin >Organization: >Release: FreeBSD 3.0-970618-SNAP i386 >Environment: >Description: When fetch(1) manages to notice, that remote server has closed connection, it should be capable of restoring it right a way (without user restarting the fetch itself) and start REgetting the file. This may not always be the desired behavior, so there must be an option to turn this off. However, I'm sure it will be very usefull for unattended fetching, such as during port- -builds. >How-To-Repeat: Go build some huge port. Watch it start fetching 4Mb tar-ball. Go jogging. When you come back in an hour, find that the link went down for 7 minutes, 2 minutes before the end of the transfer. fetch failed, so make started another one with another URL... >Fix: It will be unreliable to teach bsd.port.mk to restart fetch with `-r' if the file is partially here (too many assumptions), but the fetch itself can be made smarter. >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707261533.LAA01455>