On Sep 20, 2010, at 10:04 AM, Rune <[email protected]> wrote:
> Hi Chas,
>
> On Sat, Sep 18, 2010 at 07:09:58PM -0400, Chas Williams (CONTRACTOR) wrote:
>> In message <[email protected]>,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.
>
and things also hardcore and don't use TMPDIR in many cases
> (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?..]
>
I wrote one in perl (4!) many years ago. no one seemed overly interested in the
concept. There is room in OpenAFS several places for this sort of 'decision
engine'
> 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.
>
Coming around a bit, this proposal was seasoned by Wolfgang Gehrke's talk on
booting from AFS at the European AFS Conference which has just passed, rather
than the 'how can I corrupt my browser cache'
idea_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
