Open Bug 65410 Opened 24 years ago Updated 2 years ago

mail folders created in Windows are unreadable in Linux

Categories

(MailNews Core :: Backend, defect)

x86
Linux
defect

Tracking

(Not tracked)

People

(Reporter: ryan, Unassigned)

References

(Blocks 1 open bug)

Details

I have a dual boot computer, Linux and Windows, each with a copy of Mozilla 0.7.
I've tried to set the Linux Mozilla up to use the Windows mail folders and
bookmarks file by symlinking the Windows files into my .mozilla directory. The
bookmarks work fine -- Moz loads the right bookmarks and I can change the
entries. However, the mail files do not work: when opening up Mail, an "unknown
error" dialog pops up; after clearing that, clicking on message titles yields
random chunks of messages. The message titles are correct, and the message text
itself is not corrupted, but the index & dividers between messages (if this is
how the mail files are set up) seems to be corrupted.
Incidentally, the mail works fine when viewing it on the Windows boot's Mozilla.
I really don't know - perhaps we're not resolving the sym link when trying to
read the mailbox file. Or perhaps we can't read the mailbox file correctly from
windows when its written out by linux (the line termination chars might be
different). Anyway, this most likely isn't a mail database issue. Reassigning to
Putterman for triage.
Assignee: bienvenu → putterman
Component: Mail Database → Mail Back End
Confirming (Status NEW) based on the comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
reassigning to naving
Assignee: putterman → naving
As far as I have found out, the source of this problem is that the locations of
mail directories are stored as absolute paths in prefs.js which breakes the
sharing of a profile between different operating systems. Possible solutions I
can imagine include moving these settings to the mozilla registry which is a
different file for each os, removing the feature to be able to define local mail
folders outside the profile, and declaring this bug a feature. As I am only a
mozilla user and not a developer, I am not able to decide whether this finding
means that the bug must be reassigned; anybody?

I also have found a workaround for people that want to share a profile between
windows and linux: First create your profile in windows. Then create your
profile in linux. Then, replace the directories Mail/, News/, ImapMail/ and the
files history.dat, history.mab, abook.mab, bookmarks.html, cookies.txt by
symbolic links to the same directories/files in the windows profile. This leads
to two profiles that share history, bookmarks, cookies, address book, mails and
news, and is working for me (mozilla 0.8 on win me and debian), proofing that
there is no line termination character problem. Note that the preferences are
not shared using this workaround!
The problem is merely how the URI is written in prefs.js. For example:

On Windows: 	D:\\Eric\\Mozilla\\ET\\pgeap7uz.slt\\Mail
On Linux:	//D:/Eric/Mozilla/ET/3h3xpy3b.slt/Mail

(Note: Having a D: drive on Linux is as simple as mounting the partition in a D: directory on / or making a symlink to it.)

Both won’t find the files if it is written the other OS' way, but if you edit pref.js and correct it before running Mozilla, it will work (but you currently have to do this every time you change platform :-(  ). An easy fix would be for both to read and write it the "correct" way, i.e.:

		file:///D:/Eric/Mozilla/ET/3h3xpy3b.slt/Mail

This is the only bug preventing Mozilla from having a truly cross-platform profile and should be  very trivial to fix (it is written like this on both windows and Linux for the browser.search.defaultengine pref)! This will be very useful to a large number of people. For using the same profile on both platforms, but it will also be a great argument for getting people to migrate to Linux, since they can have the same program they're used to and keep all their data and settings without having to do anything more than pointing to the directory were the profile is kept in the profile manager.

P.S.: Another way (better, but probably harder so please do it as said above for now if it is) would be to use relative paths, i.e.

profile://Mail/pop.tokyo.com

Note that this path problem appears on 4 prefs (or more if you have multiple POP3s):

mail.root.none
mail.root.pop3
mail.server.server1.directory
mail.server.server2.directory
mail.server.server3.directory
...
mass re-assign.
Assignee: naving → sspitzer
Using Mozilla 1.5 on RH9 and WinXP dual boot.
Windows mail folders show up in Linux with Local Folder settings like this:
/home/jane/D:\mozilla\Default User\abcdefg8.slt\Mail\mail.example.com
In Windows the D: is added and all / changed to \.  Then in Linux it 
adds /home/jane.  In Linux, going to /home/jane and creating a symlink D: 
to /mnt/shareddata partially fixes the problem, because of course now
/mnt/shareddata\mozilla\Default User\abcdefg8.slt\Mail\mail.example.com
and  /home/jane/D:\mozilla\Default User\abcdefg8.slt\Mail\mail.example.com
are the same place, but you still have to manually change \ back to / before 
it works.  Once you boot back to Windows, it won't see the /home/jane part and 
will work great, but it will still change / to \ and you'll have to reverse 
that manually back in Linux.  Bookmarks, address book, and all other prefs 
share beautifully and with no hitches.

Something so simple as forcing / in prefs.js would make such a difference, at 
least to people who know how to make symlinks, because in Windows it doesn't 
seem to have any trouble reading it this way.  However, I think making Mozilla 
fully cross-platform would be a big step in persuading Windows people to try 
Linux and see that they don't have to give up all their programs and start 
over or go through a bunch of complicated steps to move their data over -- and 
they can keep using Windows as a backup OS without losing access to their 
data.  Hope this helps!
Product: MailNews → Core
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → backend
Product: Core → MailNews Core
Blocks: 653389
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.