From owner-freebsd-ports Wed Jul 12 18:46:30 2000 Delivered-To: freebsd-ports@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id EA36137B50D; Wed, 12 Jul 2000 18:46:25 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca14-12.ix.netcom.com [205.186.215.12]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA17464; Wed, 12 Jul 2000 21:46:18 -0400 (EDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id SAA74209; Wed, 12 Jul 2000 18:46:16 -0700 (PDT) To: Ben Smithurst Cc: Dag-Erling Smorgrav , Will Andrews , ports@FreeBSD.org Subject: Re: fetch(1) timeout References: <20000712061459.D1690@argon.gryphonsoft.com> <20000712064405.E1690@argon.gryphonsoft.com> <20000712065724.F1690@argon.gryphonsoft.com> <20000712131725.A23242@mithrandr.moria.org> <20000712072043.H1690@argon.gryphonsoft.com> <20000712153329.I11000@strontium.scientia.demon.co.uk> <20000713004229.Z11000@strontium.scientia.demon.co.uk> From: asami@FreeBSD.org (Satoshi - Ports Wraith - Asami) Date: 12 Jul 2000 18:46:14 -0700 In-Reply-To: Ben Smithurst's message of "Thu, 13 Jul 2000 00:42:29 +0100" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * From: Ben Smithurst * Hmm, I assume fetch(1) exits non-zero for an aborted transfer? If so, * can't bsd.port.mk detect that and rename the file to whatever.ABORTED, * and check for that next time you fetch, and if it exists, try resuming? * It seems like a bit of an ugly hack though, and I haven't thought it * through in detail. :-( Although by your "this is a feature" I assume you * wouldn't want something like this, as you've thought about it before? No, the issue is larger than that. If someone ^C's a running make, bsd.port.mk will immediately exit too. When the user restarts it, bsd.port.mk has no idea whether the file was interrupted or not. Of course, we can trap signals in a shell script we call from bsd.port.mk or something, but now it gets real ugly. * > Even if it somehow tried, you might get connected to a different * > master site the second time around. What will happen if -r is * > specified? * * It shouldn't matter, unless the distfiles are different on the different * master sites, which shouldn't happen, should it? If it does, one of It can and does happen, and all of them can be correct. (files/md5 allows multiple entries for the same file just for this purpose.) Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message