405258 - Proposal for eliminating simple blocking profile lock in favor of different profile locking scheme

Status: RESOLVED DUPLICATE of bug 135137

(Toolkit :: Startup and Profile System, enhancement)

Description

[Garrett Cooper]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

===================
Summary:
===================
It appears that although the use model for the single use profile is ok, it's not very effective when using a Mozilla product (Firefox, Thunderbird, etc) profile that's located on a DFS. By using file monitoring and/or a profile shared locking scheme this issue can be circumvented.

===================
Problem statement:
===================
I've been aware of this single-use profile 'caveat' for quite some time, but because of a recent change in the IT dept's Linux configuration i.e. switching from XFCE4->Gnome, which allows multiple people to be logged into the same machine interactively via gdm and thus prevents [uneducated] people from being able to login and terminate their Firefox sessions, students are now discovering that they can't use Firefox is 2+ machines at once.

The same applies for Windows clients.

So, given the fact that distributed filesystems, and multiple display (local vs remote desktop methods like NT's rdesktop and X11 displays) configurations are becoming the norm in the computing world, I propose the following (abstract) change in behavior to how profile management is done:

Case A.1 (readable / writable profile -- profile on DFS); shared lock, realtime commit case:
1. Open profile for read-write on n-machines, but also make changes detectable in real-time, similar to what FAM does. So any changes to bookmarks, etc will be made available to everyone. This would be handy but may bloat in-use resources and would require more compute time, such that it might not be a likely good candidate for solving this problem.

Case A.2 (readable / writable profile -- profile on DFS); shared lock case, with committing:
1. Open profile for read-write on n-machines, but try to merge changes as best possible (similar to CVS, SVN, etc). This would allow the most flexibility with the least resource requirements, but would put the burden on the user to review all changes made to the profile at exit.

Case B (shared read-only profile -- use model would be like a kiosk PC); multiple readers, single writer case:
1. Unless user has access to change profile (maybe using a password via the Profile Manager would be required, etc), make all changes to profile available only via [virtual,physical] memory.
2. Only allow one copy of the profile open for writing at one time and make changes to temporary profile flush only at exit.

I realize that changing the behavior for the profile manager would be difficult, but the fact is that this not only is something that would increase mobility with Mozilla products, it's also a handy feature which, if done correctly, can be a good selling point against MSIE, because MSIE hasn't fully implemented this 'feature' outside of the Favorites, because the Favorites are real files on a disk instead of entries in an HTML file like Mozilla's bookmarks.

Reproducible: Always