Date: 12 Jul 2000 12:34:24 +0200 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: Will Andrews <andrews@technologist.com> Cc: Adam <bsdx@looksharp.net>, Satoshi - Ports Wraith - Asami <asami@FreeBSD.ORG>, ports@FreeBSD.ORG Subject: Re: fetch(1) timeout Message-ID: <xzpitub63in.fsf@flood.ping.uio.no> In-Reply-To: Will Andrews's message of "Wed, 12 Jul 2000 06:14:59 -0400" References: <Pine.BSF.4.21.0007120534530.427-100000@turtle.looksharp.net> <xzpvgyb65g1.fsf@flood.ping.uio.no> <20000712055707.C1690@argon.gryphonsoft.com> <xzpn1jn64r2.fsf@flood.ping.uio.no> <20000712061459.D1690@argon.gryphonsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Will Andrews <andrews@technologist.com> writes: > On Wed, Jul 12, 2000 at 12:07:45PM +0200, Dag-Erling Smorgrav wrote: > > That's not very helpful, you know. Do you have something constructive > > to add, such as a detailed description of your problem with -r? > Sorry, I intended that to be a wakeup call. Of course I have something > more helpful: > [...] The first time around, you killed fetch(1), so it never had a chance of setting the modification time on the file. The second time around, it noticed that the local file had a modification time different from that of the remote file, and decided not to resume the transfer. This is expected and documented behaviour; to force fetch(1) to disregard the modification time when considering whether or not to resume a transfer, use the -F option. It is possible to modify fetch(1) so it will set the modification time even if interrupted; I will consider doing so if the changes required are not too intrusive. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpitub63in.fsf>