From mi@rtfm.ziplink.net  Sat Jul 26 08:34:26 1997
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 <FreeBSD-gnats-submit@freebsd.org>; 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 <FreeBSD-gnats-submit@freebsd.org>; 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 <mi@aldan.ziplink.net>
Reply-To: mi@aldan.algebra.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: fetch(1): behavior upon timeout/disconnection 
X-Send-Pr-Version: 3.2

>Number:         4172
>Category:       bin
>Synopsis:       [request] suggest reconnection option added to fetch(1)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    des
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul 26 08:40:02 PDT 1997
>Closed-Date:    Fri May 13 07:47:41 UTC 2011
>Last-Modified:  Fri May 13 07:47:41 UTC 2011
>Originator:     Mikhail Teterin
>Release:        FreeBSD 3.0-970618-SNAP i386
>Organization:
>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.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->suspended 
State-Changed-By: phk 
State-Changed-When: Wed Apr 15 11:37:11 PDT 1998 
State-Changed-Why:  
-> suspended 
State-Changed-From-To: suspended->feedback 
State-Changed-By: nbm 
State-Changed-When: Fri Dec 17 01:47:59 PST 1999 
State-Changed-Why:  
Isn't this the behaviour of 'fetch -a'? 
State-Changed-From-To: feedback->open 
State-Changed-By: des 
State-Changed-When: Thu Jun 29 02:37:09 PDT 2000 
State-Changed-Why:  
Still an issue. 


Responsible-Changed-From-To: freebsd-bugs->des 
Responsible-Changed-By: des 
Responsible-Changed-When: Thu Jun 29 02:37:09 PDT 2000 
Responsible-Changed-Why:  
fetch(1) is mine. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4172 
State-Changed-From-To: open->suspended 
State-Changed-By: des 
State-Changed-When: Tue Nov 27 05:39:41 PST 2001 
State-Changed-Why:  
Still an issue, but I don't have time to work on it right now. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=4172 
State-Changed-From-To: suspended->closed 
State-Changed-By: des 
State-Changed-When: Fri May 13 07:47:39 UTC 2011 
State-Changed-Why:  
Won't fix.  The ports tree uses -r now. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4172 
>Unformatted:
