From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1b6fb567a0c2dae27065d1be1ac861c5@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] hget
From: rog@vitanuova.com
In-Reply-To: <40688A19.3000602@swtch.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-dryottrpafnlkjnkstfputyqoa"
Date: Mon, 29 Mar 2004 22:12:03 +0100
Topicbox-Message-UUID: 463d2b8a-eacd-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-dryottrpafnlkjnkstfputyqoa
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

> whereas hget -o file will not replace the file if the server
> or some broken intermediate cache thinks things are up-to-date

that's why i thought it might be reasonable to divorce the "look at
modification time of file" semantics of -o from the "can seek on
output" semantics of same.

i've never used -o as it currently is because i don't trust
computers to keep or record time properly, either here or out there
(i've the same problem with my thinkpad time speeding up as everyone
else).

i'd expect

	hget | wc

to produce the same results as

	hget > file
	wc < file

>  then how about hget -1 meaning "one shot at writing data"

i think the option should the other way around,
e.g. hget -m meaning "multiple shots at writing data.

then the above correspondence still holds.
(and -o still does the same thing)

--upas-dryottrpafnlkjnkstfputyqoa
Content-Type: message/rfc822
Content-Disposition: inline

Received: from mail.cse.psu.edu ([130.203.4.6]) by doppio; Mon Mar 29 21:48:51 BST 2004
Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001)
	id A81B219A21; Mon, 29 Mar 2004 15:43:31 -0500 (EST)
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 3C16F19A53; Mon, 29 Mar 2004 15:43:27 -0500 (EST)
X-Original-To: 9fans@cse.psu.edu
Delivered-To: 9fans@cse.psu.edu
Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001)
	id 72E1819A21; Mon, 29 Mar 2004 15:42:36 -0500 (EST)
Received: from holo.morphisms.net (holo.morphisms.net [66.93.84.55])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 7E9CA19AFD
	for <9fans@cse.psu.edu>; Mon, 29 Mar 2004 15:42:35 -0500 (EST)
Received: from swtch.com (lusitania.lcs.mit.edu [18.26.4.154])
	by holo.morphisms.net (Postfix) with ESMTP id 2E2B724FD0
	for <9fans@cse.psu.edu>; Mon, 29 Mar 2004 15:42:35 -0500 (EST)
Message-ID: <40688A19.3000602@swtch.com>
From: Russ Cox <rsc@swtch.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: 9fans@cse.psu.edu
Subject: Re: [9fans] hget
References: <359104229c4622713a37f906e086ec14@vitanuova.com>
In-Reply-To: <359104229c4622713a37f906e086ec14@vitanuova.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Mon, 29 Mar 2004 15:42:01 -0500
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
X-Spam-Level: 


>however we're already admitting a qualititive difference in types of
>file by using the -o option as it is.  (oh no, danger!  danger!  file
>seek thread trying to re-establish; apologies!)
>
>at least when you're creating a file, you're reasonably sure you can
>seek on it ok (although of course that's not the case for >{}).
>
>i think the default case should be not to seek, because that
>will produce less surprises.
>  
>

right enough.   then how about hget -1 meaning "one shot at writing data"
(or if that doesn't describe it, "what rog thinks it should do"  ;-) )
my point is mainly that i'd rather see an option than some magic
guessing that will confuse people once they see the difference.
i do hget >file all the time, when i want to make sure i get a new
copy (whereas hget -o file will not replace the file if the server
or some broken intermediate cache thinks things are up-to-date).

--upas-dryottrpafnlkjnkstfputyqoa--