Comment 125 for bug 93546

i agree that the detection of the file system type is a hack, but breaking the problem in two would help local instances, full features with multi-instances in little time. reducing all to the network FS way will take more work and so longer and with reduced funcionality.

If later the network soluction is good enough, we could remote the "local FS" hack... of course, this is just a opinion, even more as i'm not a developer, my programming skills are very basic :)

for Comment #90, of course there is a need for some sort of extra layer for the read-only mode, my idea is not block all writes, but not update the "Real" profile (and so any change is lost in the end).

my idea is, when the the profile is locked, to copy the needed files (or use a copy-on-write) to a new dir (say a folder named ip-data-time) and work over there, write and read... In the end, we could drop that folder and lose any changes.

i got another 2 ideas that might be used or not with the above idea

-sockets!! why not create a socket in the first instance and new instances would ask the first one to do the updates in their name... if needed, fork a small daemon to keep the process that do the writes simple and reliable way.
This could be the extra layer talked about.
Of course windows could be a problem, but cygwin had solved someway...

-there are several software that do the sync of several parts of the profile to a web location... why not take that idea and apply it locally?

we know the original state, the know what changed in each instance, so do a "diff" (or list actions done, no need to do a real diff) and place it in some "queue" dir with some kind of serial number.

when the normal (non-locked) instance start, would read that queue dir and try to apply the diffs/actions to the profile...
...as it was said before, bookmarks and maybe passwords and cookies are the most important things to try to keep from locked instances, all remaining probably arent worth the trouble