Date: Sat, 07 Apr 2007 15:56:09 -0500 From: Harrison Grundy <astrodog@gmail.com> To: Nate Lawson <nate@root.org> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, current@freebsd.org Subject: Re: libfetch ftp patch for less latency Message-ID: <46180569.4060402@gmail.com> In-Reply-To: <4617F563.40502@root.org> References: <460AE39B.4070706@root.org> <86odmcqylx.fsf@dwp.des.no> <200703291905.00192.pieter@degoeje.nl> <86k5wzq4vx.fsf@dwp.des.no> <86fy7nq4q1.fsf@dwp.des.no> <4617D2CE.1050502@root.org> <86ps6g5759.fsf@dwp.des.no> <4617F563.40502@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote: > Dag-Erling Smørgrav wrote: > >> Nate Lawson <nate@root.org> writes: >> >>> Obviously, it's easier to do nothing than something. So here are some >>> options: >>> >>> 1. Add my patch -- if a server returns an error, I see no way it would >>> have changed the PWD. If you say "CD GARBAGE", what reasonable system >>> would return an error and change to some random dir? >>> >>> 2. Add an env variable (similar to FTP_PASSIVE_MODE, say >>> "FTP_SINGLE_CWD") which forces the current behavior. If not set, fetch >>> tries the multi-method first, falls back to the single-method on error. >>> >> No. >> >> Thanks, >> >> DES >> > > I forgot: > > 3. #ifdef (on or off by default) > > Also, can I hear from anyone else besides Mr. No? > > Thanks, > I'd be fine with this... it should be fairly easy to make sure this won't break the oddball servers. Worst case, you could start from scratch on a failure. (Re-initialize the connection and all...) This certainly makes a difference on high latency links, or slow servers. Thanks! --- Harrison
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46180569.4060402>