On Mon, 9 Dec 2002, Jan Harkes wrote:

> > It *could* be possible to rewrite the server (and probably have to
> > implement a local file system suitable for putting the files on it), so

> Not really possible. The current semantics is that a modification on the
> server is an atomic change from the old version to the new. When someone
> is 'editing' a file from some magical exported tree on the local
> machine, when should we break the callback?
>
> - When the file is opened for writing? Clients will refetching the file
>   before any of the changes are saved, and get an bad copy.
>
> - When the file is closed? Client that 'accidentally' fetch the file
>   between the open and the close will get a bad copy.

Well, it depends on what we are looking for.

There are several diferent possible targets:

 - to be able to "export" existing data without a copy operation.
Then we could postulate that the files must *not* be written through local
fs _anymore_, but via a Coda client instead.
Well, it might be even useful to be able to export "local fs data"
readonly, freezing them and pretending they are a readonly volume with a
"per-volume" acl?
Then there might be an "export" operation, recreating the volume or in
some other way invalidating old cached objects, for restoring consistency
after (offline) updates through the local filesystem...

 - to be able to go past Coda acls
Then it *may* be OK to sacrifice consistency.

 - to be able to go past network layer for massive operations (?)
Then a client built into the server may offer the functionality (and the
"ignore acls" one too)

Not that I suggest such projects, just thinking aloud.

Regards!
--
Ivan