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. (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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
