[OpenAFS-devel] Re: on sockets and devices in AFS

[Rune]

Hi Chas,

On Sat, Sep 18, 2010 at 07:09:58PM -0400, Chas Williams (CONTRACTOR) wrote:
> In message <4C93A15E.4070708@secure-endpoints.com>,Jeffrey Altman writes:
> >I believe that the proper behavior for today's
> >clients is to maintain the object locally and mask it from the file
> >server.

> like i said before i am not sure this is a good idea.  for instance,
> google chrome creates a named socket in your home directory in
> .config/google-chrome.   if you run chrome again on another machine so
> google chrome might think that no one else is using that .config directory
> since named sockets are only maintained locally.  but the other files in
> .config/google-chrome would appear to be global.  this is inconsistent
> and possibly confusing to an application.

The problem is not the file system but the applications. They are not
expecting home directories being shared, even less expecting them
to be global (i.e. not obeying the local *nix uig/gid space, possibly not
being exactly in sync on different hosts).

Naturally application-specific local sockets should be created in a
local user-specific directory (not /tmp as it is open for attacks) -
but the *nix tradition unfortunately does not offer such a directory.

Some distros may use pam_tmpdir or alike which set up TMPDIR in the right way
(isolated between users) but this is not standard.

(Of course the presence of the sockets should never be used for "locking"
either...)

Unfortunately a lot of design of "desktop"-applications is modelled after
Windows, which translates to "a single host", and then after single-host Unix
which implied "local home directories".

No such application I know of (an application maintaning its state like
the list of visited files or the preferences) is capable of gracefully
handling multiple instances of itself running on different hosts sharing
the users's home directory with delayed replication (like disconnected
mode).

So, they will lose no matter what, unless a nice
"persistent-state-with-lock-free-asynchronous-updates"-library would
be written and used by the applications, implementing transaction-like
updates with automated merges - taking into account the semantics of
the data to be merged. Alas, such a library does not yet exist (or at
least apparently is not being used :)

[as a side note, Coda file system provides hooks to support
application-specific conflict resolution and automated merges, which
may be a right idea of where to put the corresponding intelligence -
or may be not?..]

As a result:

according to my experience, letting applications to be unaware of their
multiple instances may certainly lead to corruptions but most of the
time it makes them work better than otherwise.

Regards,
Rune