From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <00a2104440670cbbedfa015c194ac561@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] hget
From: rog@vitanuova.com
In-Reply-To: <40687E22.2010506@swtch.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon, 29 Mar 2004 21:12:48 +0100
Topicbox-Message-UUID: 460c0816-eacd-11e9-9e20-41e7f4b1d025

> it won't work if the connection gets halfway done, hangs up,
> and the remote server doesn't support content-range requests.
> but how often are you in this situation?

actually, it seems (from the hget code) that the server can return
error 206 (partial content) which causes a seek on the output, even if
the content-range request is supported.  i've no idea how common this
is though.

i was thinking of changing hget so that if it's writing to stdout, it
would give up with an error rather than trying to seek back and try
again.

the would at least mean you could use it in a pipeline without
worrying about occasionally duplicated portions of output.

an option similar to -o but without the modification time semantics
could yield the current behaviour (ideally, i'd make the modification
time stuff a separate option (-u?)  and use it in addition to -o to
get the current -o semantics; but that would break some things).