From owner-cvs-lib Tue Sep 10 12:46:23 1996 Return-Path: owner-cvs-lib Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08806 for cvs-lib-outgoing; Tue, 10 Sep 1996 12:46:23 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA08795; Tue, 10 Sep 1996 12:46:02 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.7.5/8.7.3) id TAA12231; Tue, 10 Sep 1996 19:42:43 GMT From: Adam David Message-Id: <199609101942.TAA12231@veda.is> Subject: Re: cvs commit: src/lib/libftpio ftpio.c To: adam@veda.is (Adam David) Date: Tue, 10 Sep 1996 19:42:41 +0000 (GMT) Cc: jkh@time.cdrom.com, jkh@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-lib@freefall.freebsd.org, freebsd-ports@freebsd.org In-Reply-To: <199609101904.TAA12202@veda.is> from Adam David at "Sep 10, 96 07:04:34 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-lib@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Two sites have different timestamps on the files, so when fetch(1) compares > them it thinks "different file" and starts over. It's worse, the time on the partly downloaded file is never updated to match the remote file. > > Not much I can do about that - if you want to save what you've > > transfered already, you have to save the file. I don't see as how > > ports could know a good one from a bad one. I guess the other > > alternative would be to go to a temporary file all the time with > > fetch, only moving the file over it's been fully fetched. > A quick Makefile hack would be to flag the file in some way if the transfer > does not complete normally, for instance by setting its mode or timestamp On second look, it seems very reasonable in this context for fetch(1) to set the timestamp to 0 if an error occurs during download. Adam