58647 - Use same preferences, bookmarks, cache, mail folders on dual boot system

Status: RESOLVED WONTFIX

(Core Graveyard :: Profile: BackEnd, enhancement, P3)

Description

[Aaron Leventhal]

It would be nice for users of dual boot systems such as Windows/Linux to be able
to easily set things up to use the same profile whichever OS they boot into.
That would be a great feature taking advantage of Mozilla's cross platform nature.

I tried to do this by setting up links to my Windows partition. It sort of
worked, but there were a few problems, especially with folders on mailnews.
Perhaps this is due to the differences in line breaks between the systems.
Also prefs.js doesn't have a way of specifying file names in a way generic to
both, so it had to be edited by hand.

It would be great to have an option in the Profile Manager in Linux to find the
Windows partition and use a profile seamlessly from there.

Comment 1

[sairuh (rarely reading bugmail)]

methinks this would go over to the backend prof mgr folx... punt back if
otherwise!

Comment 2

[Aaron Leventhal]

methinks it should go the the backend pref folks too.
I already filed it under "Component:Profile Manager BackEnd".
Isn't that where it went?

Comment 3

[racham]

Taking this bug before I do a mass reassign.

Comment 4

[racham]

Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.

Comment 5

[Conrad Carlen (not reading bugmail)]

This could also be solved by using XP, relative file specs. See bug 12911

Comment 6

[Niels Aufbau]

I find it amusing that this bug's OS field was set to Linux.

Comment 7

[Conrad Carlen (not reading bugmail)]

*** Bug 127151 has been marked as a duplicate of this bug. ***

Comment 8

[Michael Wardle]

Adding myself to CC after filing a similar bug 127771.

At first glance I'm not sure that this bug depends on bug 83147.  Are we sure
bug 83147 is blocking this one?

Comment 9

[Michael Wardle]

Can I suggest we slightly broaden the scope of this bug to
"allow sharing of profile between multiple operating systems"?

The bug I filed (bug 127771) is essentially the same, except I'm accessing my
shared profile directory from two different machines.  Whether I'm accessing my
Mozilla profile from the same machine or different machines makes little
difference as far as I can see, since I'm still trying to access the same profile.

Comment 10

[Conrad Carlen (not reading bugmail)]

*** Bug 92303 has been marked as a duplicate of this bug. ***

Comment 11

[Arne Falk]

What is the real problem about this ? Why does not a symlink to the windows
profile directory [whatever it is named] from the Linux dito work ?


Then when this work, the profile setting could just have a browser for the
profile directory to use.

Comment 12

[Theodore Reed]

Because, if I'm not mistaken, moz needs to be able to write to the profile dir,
as well. Not all of us have Windows installed on FAT32. The linux NTFS drivers
are still not good enough to trust for anything beyond read-only.

Comment 13

[Arne Falk]

I dont think that is an issue. The user must of cource make sure that the OS can
read and write the filesystem on which the selected mozilla folder is placed.

If the filesystem is read-only (for instance the mozilla folder is placed on a
CD for backup or transport, the mail and adresses should still be readable
AND/OR importable (mergeable) with mozilla).

Comment 14

[R.K.Aa.]

*** Bug 155842 has been marked as a duplicate of this bug. ***

Comment 15

[Stuart Summerville]

added self to cc list.

Comment 16

[Arne Falk]

Now that bug 12911 is solved, what is the status for this bug. Can You now have
a symplink somewhere in the Linux installation pointing to somewhere in the
windows installation, and thus get bookmarks, preferences and mail to be shared
between the systems in a dual boot enviroment ?

Comment 17

[Conrad Carlen (not reading bugmail)]

As far as bug 12911, see http://bugzilla.mozilla.org/show_bug.cgi?id=12911#c136.

Comment 18

[Anthony L Borchers]

Added self to cc list

Comment 19

[webograph]

what about different extensions installed on different operating systems? it
would be fine if there was a mechanism to catch problems resulting of a
missing/spare extension ("In this profile, there are settings for the
'...'-extension. They will be kept, but you won't be able to use them.")

Comment 20

[Oliver Klee]

*** Bug 192687 has been marked as a duplicate of this bug. ***

Comment 21

[mnagyspam]

Symlinks aren't enough to solve the problem:

(1) A symlink to a profile subdirectory [whatever].slt doesn't work because the
Linux version treats entire Windows-format paths as single unqualified directory
names (assumed to be in the user's Linux home directory).  It might save a lot
of trouble if the different versions could be made to recognize a common path
format, or take conversion parameters for the interpretation of a Windows path
under Linux, or some such thing.

(2) A symlink to a Mail directory is semi-useful in that the messages in the
folders can be in a shared location, but sort order and sometimes read/unread
markings are lost every time a switch is made between OS's (between Windows 98
SE and Linux at least).

(3) A symlink to a file (at least if it's a bookmark file) doesn't work because
the symlink (rather than its target) is overwritten with a separate file when
the contents are updated by the Linux version.

Comment 22

[Luiz Angelo Daros de Luca]

How about create a conf.<SO> for the specific fields where it depends on the SO.
It doesn't look difficult to do so. 

1) Read the original conf.
2) Update with the So specif one.

This keep the compatibily and also offers an option if the user don't want this.

The problem is to save new confs. It could do the reverse way.

if the field changed is in conf.<SO>
    change it
else
    change in the original conf.
end

Comment 23

[Vaclav Dvorak]

Isn't this a dupe of bug 7067? I don't see the difference...

Comment 24

[mnagyspam]

The summary in bug 7067 refers to something more sweeping and general than this,
although the descriptions overlap considerably.  Certain key capabilities like
mail and bookmarks that are subject to continual update could be a higher
priority for cross-platform sharing than something like automatically having the
same toolbar styles, which would be relatively trivial and easy to duplicate
manually.

Comment 25

[Vaclav Dvorak]

I've now started sharing my Win98 Mozilla profile with a Linux installation on
the same computer. (I symlinked the Linux .slt directory to the .slt directory
on the Win98 partition.) The good news is that it mostly works!

So far, I have encountered only three minor problems:

1) bug 229596 - but the only problem seems to be that the cache gets cleared
after switching OS's (or possibly whenever I start the Linux version, because
the profiles contains the Windows path; not sure about this), otherwise it
doesn't really matter. Since I have a caching proxy server one Ethernet hop
away, I don't care. :-)

2) I can't search from the URL bar, because my prefs.js contains:
user_pref("browser.search.defaultengine",
"engine://C%3A%5CPROGRAM%20FILES%5CMOZILLA.ORG%5CMOZILLA%5Csearchplugins%5Cgoogle.src");
That's obviously annoying, and there doesn't seem to be a bug filed for this
problem so far, which I will do. Still, it's not a show-stopper.

3) When I change a preference in Linux to a value that is the default on
Windows, the next start of Mozilla in Windows deletes that preference from
prefs.js because it's the default - and vice versa. For example, I set
browser.urlbar.clickSelectsAll=true and
layout.word_select.stop_at_punctuation=true in Linux, but Mozilla in Windows
deleted those prefs because both are the default in Windows but not in Linux.
Again, there doesn't seem to be a bug for this. A workaround would obviously be
to change the default in the Moz installation directory, assuming the user has
the required privileges to do that.

Comment 26

[Dan]

I'd like to add my "YES PLEASE" to this bug. There are two problems I see here,
the first is that Moz uses aboslute paths in the prefs.js file (for Windows at
least) e.g. "E:\\Data\\Mozilla\\Dan\\8f8mnp7a.slt\\Mail\\mail.someserver.com".
Obviously Linux doesnt know what E: is (in fact, it tries to find/create an
"E:\\Data\\Mozilla...." file under $HOME). It would be great if it supported
something like "Relative to the prefs.js" path entries (if it doesn't start with
a drive letter or "/").
The second problem is the escaping of path names. I.e. on Windows all the "\\"
are needed since windows needs the back-slash for folders. Again, make the
backend-prefs parse understand that either "/" is a directory on Windows, or
"\\" is a directory on Linux.

Comment 27

[Rob Thomson]

I would love this feature as well. I've currently managed to get it working with
a bit of a hack, (WinXP + 2 versions of Mandrake Linux) however, this is far
from ideal:
-Create a FAT32 partition large enough for the Profile.
-Install the Windows profile on the FAT32 drive, eg G:\Mozilla\default\www.slt\
(don't think you can choose the .slt bit)
-Install under Linux, and create a profile, eg in ~/.mozilla/default/xxx.slt
-Delete xxx.slt and create a symlink "ln -s /mnt/shared/mozilla/default/www.slt
xxx.slt"

Edit prefs.js, and remove things that look platform specific (this is the worst
bit). Create windows.js, linux.js that include preferences in the platform
specific format. These need to be copied to user.js on startup with a script. So
windows copies windows.js to user.js. Linux copies linux.js to user.js. This is
the worst bit of the hack. Entries in my <os>.js files include:

user_pref("browser.download.dir"
user_pref("mail.server.server1.directory"
user_pref("browser.cache.disk.parent_directory"
user_pref("mail.server.server4.newsrc.file"
user_pref("messenger.save.dir"
user_pref("browser.bookmarks.file"
(i think addressbook is just a filename, no directory, so not platform specific)

Basically all path specific stuff. Path to cache might be
G:\mozilla\cache on windows
and /mnt/shared/mozilla/cache on linux.

I've also found that i need to remove the entire chrome directory between
platforms. Probably due to pathnames too, although i'm not certain. If i don't,
mozilla gets confused.
Thus i have windows.chrome and linux.chrome, and have to move the directories
about at startup in the same script. I need to install adblock twice, once on
each platform. Luckily, the adblock preferences are not platform specific, and
so sit happily in prefs.js. Any rules i add on one platform are visible on the
other.

Now I can use Mozilla on two platforms, browsing, cache, mail etc, even adblock
shares preferences. Copying files around at startup is a bit of a hack.



How about making the prefs.js platform independent? There are only a few places
that require changes. Say
WINDOWS user_pref("browser.bookmarks.file", "G:\mozilla\bookmarks.html")
LINUX user_pref("browser.bookmarks.file", "/mnt/shared/bookmarks.html")

Or even
user_pref("browser.bookmarks.file.windows", "G:\...")
or use #ifdef statements, a case 'uname -s' statement, or something else.

Comment 28

[Michał Fryska]

Attachment: Bash script for profile sharing between Windows and Linux

It's not perfect, but works for me for more than a year. Hope it will help you.

Comment 29

[Eyal Rozenberg]

I wonder why the chrome gets busted when switching platform. I mean, there aren't any relative pathnames or anything in that directory...

Comment 30

[Leonardo Morelli]

what about this?
#360187

Comment 33

[Willy_ Foo_Foo]

One of the beauty of Mozilla is its platform independent
MAC_OS/WINDOWS/*NIX same profile will work everywhere(just copy the profile folder if you dual boot or have many devices, please keep it that way)


But implementation of web apps seems to be breaking this
So i would request to have an options to disable this because i prefer cross platform profile usability over a web app, i don't want to sync profiles(using internet) to test stuff under same profile on various platforms(as a developer you might feel my pain)


My advise would be to install all files in the profile directory called Web Apps/appname
so it is cross platform(can be launched from inside firefox if profile is shared cross platform[similar to addons]) & uninstalled like extensions

need for menus etc should be asked & if user declines no entry in menus should be made & the app should be launched from inside firefox

Comment 34

[Benjamin Smedberg]

This is not important enough to accept the QA and code complexity churn that would be involved in fixing it.

Comment 35

[Eyal Rozenberg]

Benjamin, what you're saying is only true with a certain interpretation of what this bug is about. Quoting Comment #9:

> Can I suggest we slightly broaden the scope of this bug to
> "allow sharing of profile between multiple operating systems"?

Don't bother to do QA on this all the time, but I think it can safely be marked fixed if the reasons which prevent sharing profiles go away; and that's a one-time effort I believe. In fact, this is probably simply fixing the depended-on bugs that are still open (7067 and 236742) and some of the WONTFIXes (such as Bug 229596 for which a WONTFIX is a crying shame).

I request this be reopened (and 229596 too...)