From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <f22c91a2af42dfcff1289087f933635b@coraid.com>
From: erik quanstrom <quanstro@coraid.com>
Date: Thu,  9 Aug 2007 21:57:34 -0400
To: 9fans@cse.psu.edu
Subject: Re: [9fans] synthetic filesystems and changing data
In-Reply-To: <46BBC396.9040009@ec.gc.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: a2d2eb78-ead2-11e9-9d60-3106f5b1d025

why not just tie the fid to a "file" version.  then it would be easy
to handle offsets.

- erik

On Thu Aug  9 21:47:02 EDT 2007, John.Marshall@ec.gc.ca wrote:
> Hi,
> 
> I am trying to understand the general practice, under
> Plan 9, for synthetic filesystems for serving up a "file"
> which:
> 1) returns data that changes (quickly), and
> 2) returns data whose size is larger than the message
>     size agreed upon at *version interchange.
> 
> Practically, what I am wondering is:
> 1) what to do when the "file" content changes between
>     multiple *read operations (assuming that the reads
>     are done quickly)? Is it just tough luck for the client?
> 2) whether or not synthetic filesystems generally handle
>     (or not) the offset parameter? I imagine to do this
>     requires relatively static content, is difficult, or
>     there is an assumption that the size of the content
>     _must_ fit in the message.
> 
> Thanks,
> John
>