From owner-freebsd-bugs Sat Jul 26 08:40:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA04473 for bugs-outgoing; Sat, 26 Jul 1997 08:40:07 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA04451; Sat, 26 Jul 1997 08:40:04 -0700 (PDT) Resent-Date: Sat, 26 Jul 1997 08:40:04 -0700 (PDT) Resent-Message-Id: <199707261540.IAA04451@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, mi@aldan.ziplink.net Received: from aldan.ziplink.net (aldan.ziplink.net [199.232.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA04157 for ; Sat, 26 Jul 1997 08:33:39 -0700 (PDT) Received: from rtfm.ziplink.net (rtfm [199.232.255.52]) by aldan.ziplink.net (8.8.5/8.8.5) with ESMTP id LAA15848 for ; Sat, 26 Jul 1997 11:31:30 -0400 (EDT) Received: (from mi@localhost) by rtfm.ziplink.net (8.8.5/8.8.5) id LAA01455; Sat, 26 Jul 1997 11:33:03 -0400 (EDT) Message-Id: <199707261533.LAA01455@rtfm.ziplink.net> Date: Sat, 26 Jul 1997 11:33:03 -0400 (EDT) From: Mikhail Teterin Reply-To: mi@aldan.ziplink.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4172: fetch(1): behavior upon timeout/disconnection Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >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: