dvfs api and toolkits

[Sean Middleditch]

On Sat, 2005-04-09 at 19:21 +0000, Nate Nielsen wrote:
> Sean Middleditch wrote:
> > On Sat, 2005-04-09 at 18:05 +0000, Nate Nielsen wrote:
> >>Sean Middleditch wrote:
> >>>Would there be a problem with the
> >>>file possibly changing under us?  Could we potentially detect that?
> >>
> >>Yes, in HTTP you use ETag, Modified-Date and perhaps other lesser known
> >>methods.
> > 
> > OK.  And once we detect it, what are we supposed to do about it?  Return
> > an error?  Just ignore it and let the developer get what is essentially
> > going to be corrupted data?
> 
> This isn't a particularly new problem. Your OS doesn't give you an error
>  in this case. It's up to the application to be aware of multiple users,
> and use some sort of locking. [1]

Just because POSIX makes it evil doesn't mean D-VFS has to.  ;-)
Furthermore, with POSIX, you can *replace* a file without messing up
current users, as the replacement creates a new inode and open file
descriptors reference the old inode.  That's how you do atomic writes;
replace a file instead of modifying the file.  Using HTTP, a download is
also safe so long as the server is replacing files during your download
and not modifying them.

Atomic whole-file writes are thus possible on pretty much every file
system and protocol I know of in major use without needing any form of
locking.  If we try to emulate seeking in HTTP by re-requesting files,
we make that impossible without adding locking.  If we just tell apps to
download the files and seek on the local cache then we will still retain
the atomic write capability. 
-- 
Sean Middleditch <elanthis at awesomeplay.com>